Showing posts with label Client Health. Show all posts
Showing posts with label Client Health. Show all posts

Monday, May 30, 2011

One other Great tool to fix client actions without Console (Right click tools)

I Just checked the tool and found it would useful for one works on SCCM Client health

image

It has key features as below

 

  • Initiate most common SCCM client schedule actions.
  • Initiate SCCM client health checks and fixes. Allows running checks with and without fixes as well as full health check.
  • Initiate basic administrative actions on workstations.
  • Switch between integrated authentication and alternate credentials. When logged on username has not enough rights it’s possible to specify alternate credentials by clicking on a link in top-right corner. Windows XP requires that cmdkey.exe is available in HTA folder.
  • Use TXT, CSV, XLS or XLSX files as the data source. Files with TXT extension must have computer names on each line. Excel worksheets are read from column A starting from second row. Using exported CSV from SCCM console is also supported – script knows that computer names are in first column.
  • Populate computer list from SCCM collection. Allows loading all collection members into a list.
  • Manually enter computer names into a textbox. Allows manually entering one or more computers in a text box for quick actions.
  • Supports both 32-bit and 64-bit OS on clients.
  • Supports Windows XP SP2 and newer operating systems on clients.
  • Displays real-time progress. Works when running HTA on Windows 7 or Windows Server 2008. Useful when there are thousands of computers and it would be nice to know how much is done. HTA window may not update as smoothly in Windows XP and Windows Server 2003, but it works.
  • Log is created in a text area and in a file. Lastlog.log is written to HTA folder. By default the log is using Trace32 log formatting.
  • Uses configuration file to store default settings.

Client Tasks that can be performed are classified in to 5 categories:

  • 1. Client schedule actions
    • Hardware Inventory Cycle
    • Software Inventory Cycle
    • Discovery Data Collection Cycle (Send DDR)
    • Machine Policy Retrieval & Evaluation Cycle
    • Software Updates Deployment Evaluation Cycle
    • Software Updates Scan Cycle
    • File Collection Cycle
    • Windows Installer Source List Update Cycle
    • Software Metering Usage Report Cycle
    • Branch Distribution Point Maintenance Task
    • Certificate Maintenance Task
  • 2. Client agent actions
    • Restart SMS Agent Host service
    • Repair SCCM client
    • Reset SCCM client policies
    • Reassign site code
    • Generate new SMS GUID
    • Delete trusted root key
    • Delete certificates (re-register client)
    • Change client cache size
    • Uninstall SCCM client
    • Install SCCM client
  • 3. Client health actions
    • Check WMI; Fix WMI
    • Check services; Check & Fix services
    • Check admin$ share; Check & Fix admin$ share
    • Check assigned site; Check & Fix assigned site
    • Check registry; Check & Fix registry
    • Check inventory; Check & Fix inventory
    • Check client version
    • Full health check
    • Full health check with fixes
  • 4. Advertisement actions
    • Query advertisement status
    • Rerun advertisement
    • Rerun user based advertisement
  • 5. Other actions
    • Refresh group policies
    • Ping workstations
    • Execute remotely (as SYSTEM)
    • Get logged-on user
    • Log off current user
    • Reboot workstations
    • Shut down workstations
    • Power off workstations

Download it from here :-- http://sccmcat.codeplex.com/

Monday, May 16, 2011

Good talking about Client Health common issues that we encounter in real world.

Good talking about Client Health common issues that we encounter in real world.

 

Take some time to focus on some common issues with client installation and communication issues, as well as a couple of tools that make troubleshooting infinitely easier.


SCCM Tools available

First up I want to list 3 of the primary tools I use for client side troubleshooting.

  1. Trace32 Log Reader
  2. SCCM Client Center
  3. JSandys CM Startup Script

Now the first item on that list, trace32 is by far the most valuable tool to the SCCM administrator outside of the console itself, perhaps even more so than the console. It allows filtering, highlighting, real time updates, and just generally makes the logs readable.

SCCM Client Center, this tool attaches to the cm WMI Namespace and allows for nearly full control of the client on the target machine. In terms of remediation, or even testing, there is no reason this tool shouldn’t be installed.

Config Manager Startup Script by Jason Sandys. This script is easily configured for implementation and has fairly rich logging power for a vbscript, it’s also lighter weight than some of the other health scripts. I highly recommend using this for maintaining client integrity, as well as offering an installer tool for the CM agent by secondary or third parties.


The Client

First, lets start with identifying the clients existence on the local machine.

Here’s where to look:

  • Control Panel > Configuration Manager (this is one of the quickest methods)
  • Task Manager (ctrl+shift+esc) > Processes > CcmExec.exe
  • Task Manager > Services > CcmExec
  • Control Panel > Admin Tools > Services > SMS Agent Host
  • c:\windows\system32\ccm (32bit)
  • c:\windows\syswow64\ccm (64bit)
  • HKLM\SOFTWARE\Microsoft\SMS\Mobile Client\Product Version (32bit)
  • HKLM\SOFTWARE\Wow6432Node\Microsoft\SMS\Mobile Client\Product Version (64bit)

This is a list of the primary locations to check for the presence of the client, it’s also useful for finding methods to script around identifying them.

The Client’s Jobs

Now lets discuss what the client does. First lets recognize that the client is just a dictator for the most case, it tells multiple windows services what to do to complete specific tasks. Until we need to break down what services do things specifically lets just treat the client as the primary initiator.

  • Policy updates and application
  • Manage downloads
  • System scans
  • Inventory reports

The client and server relationship relies heavily on BITS, Admin shares, RPC (at least for installation), WMI, AD, and WUA.

The client will regularly talk to the server, telling it about any changes it’s had since it’s last conversation, by way of xml. It will also ask the server what it should be doing differently, to which the server sends the client it’s latest policy. The client will review that policy then act, or do nothing depending on if there are any actionable changes.

Actionable changes could be installation of software, OS, OS configuration changes, even changes in the frequency of their conversations. These exchanges of course are called policy updates, and I believe by default they are set to 90 minutes (no real reason to change it either).


Client Installation

There are multiple ways to install the SCCM client, and in a lot of ways, that method will vary depending on your environment. I will stick to the basics and explain the process if done by server initiated push. I will also discuss what is required.

First the server begins by initiating a PUSH, using local admin rights, it will copy down the CCMSETUP.EXE file to either c:\windows\ccmsetup or c:\windows\system32\ccmsetup

A service named CcmSetup is made and it begins transferring the client contents to the local machine and finalizing installation and cleanup of the directory.

A log of the transaction is left in the ccmsetup folder named ccmsetup.log

Once this process is complete, the client will perform it’s first policy update and make it’s active client existence known to it’s respective primary server.

So what if installation fails?

This isn’t a perfect world. If you are pushing into an existing environment, things may have accidentally found there way out of standards and or flat broken.

Lets discuss what is required on a local PC for a successful install:

  • Resolvable hostname (proper DNS entry)
  • Service account with local admin rights
  • RPC access to OS components (such as registry)
  • Admin$ shares
  • WUA (Windows Update Agent)

Instead of explaining exactly why for each of these, lets explain how to resolve potential problems with each. I also want to treat this as an all inclusive troubleshooting guide for the client, so I won’t limit things to just install failures. Truthfully, if any of these breaks after installation, the client will most likely not function as intended.

Improper DNS entry:

From the local machine there is little you can do to resolve this problem. Two methods that could resolve the problem are:

ipconfig /registerdns

This will attempt to update the DNS records for all adapters of the local machine.

ipconfig /flushdns

This will dump all resolver cache data on the local machine. (long shot, but I’ve seen this clear up client DNS conflicts from the push)

Any additional resolution would need to be done by the Domain Admin on the DNS server with the improper pointer references.

Service Account with local admin rights:

This is a very simple solution. Add the appropriate service account to the local admins group on the client PC. For Installation and operation, this account needs to be set for the client to perform it’s jobs.

RPC Access:

This one can have you scratching your head at times, but a majority of the times it’s tied to a firewall. Make sure that local firewalls have exceptions built in for the SCCM server. When in doubt, disable the firewall software to verify if it’s the culprit or not.

Also ensure that the RPC (RpcSs) and RPC Endpoint Mapper (RpcEptMapper) services are Started.

Some of these changes may require a restart before taking effect so be aware of that while troubleshooting RPC denials. It’s also worth mentioning there are a multitude of applications that could disrupt this functionality, so be sure to thoroughly investigate the machine for potential culprits.

Admin$ Shares:

First off, the service Workstation (LanManWorkstation) is responsible for these shares, as well as all SMB protocols on the local machine. If it’s disabled, you will not have these shares.

One of the most direct methods for enabling admin shares is in:

HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\AutoShareWks, 1

HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\AutoShareServer, 1

Then restart the PC.

Be aware this setting can be viewed as a security risk, and with that being said, some security software may actively disable them. So treat your evaluation similarly to your RPC troubleshooting.

WUA Disabled:

The Windows Update service being disabled is a fairly simple solution provided there isn’t a GPO forcing it. You can either enable and set the Windows Update service to Automatic (wuauserv). Inside the control panel under Windows Update or Automatic updates set it to automatic.

WUA is responsible for system scans, patching, software delivery, essentially a vast majority of the clients functionality. It is imperative that WUA is enabled.


Logs to Read, and Policy Updates

For the official list of log files, go here.

(http://technet.microsoft.com/en-us/library/bb693897.aspx)

I’m going to touch on the more immediate logs for troubleshooting the following issues.

  • Health
  • Policy
  • Connectivity
  • Licenses
  • Installs

Health:

CcmExec.Log, this log is one of the first stops for suspected bad installs.

ClientLocation.log, this log is a good place to verify that client has a healthy install with a site server.

StatusAgent.log, status messages for client components. Also useful for connectivity issues.

Policy:

PolicyAgent.log, this holds policy request information, very helpful when pulling policy.

PolicyEvaluator.log, this log lets us know know if we are having issues applying policies.

Connectivity:

InternetProxy.log, if you are using unprotected DPs, this is the log to check.

Mpcontrol.log, logs record the state of the management point

LocationServices.log, attempted connectivity to MPs and DPs

Licenses:

Hman.log, if clients aren’t registering this is worth looking into.

Installs:

Ccmsetup.log, client installation happenings are recorded in this log.

Client.msi.log, output from the installer.


That concludes the overview of SCCM client installation and troubleshooting. Happy problem solving. For additional information on the client and troubleshooting check MSDN:

http://technet.microsoft.com/en-us/library/bb693982.aspx

and be sure to get involved with

http://www.myitforum.com/absolutenm/PPLSearch.aspx

Source : -http://www.myitforum.com/absolutenm/templates/Articles.aspx?articleid=23741&zoneid=89

Thursday, September 30, 2010

For finding the 90 days old computers in the AD

 

 

For finding the 90 days old computers in the AD


DSQUERY COMPUTER "DC=MydomainName,DC=COM" -STALEPWD 90 -LIMIT 5000 >> C:\output.csv

for finding the 90 days old computers in the AD & action to delete with the output

DSQUERY COMPUTER "OU=COMPUTERS,DC=LANDESK,DC=COM" -STALEPWD 90 -LIMIT 5000 | DSRM -NOPROMPT >C:\Output.csv

Monday, June 28, 2010

SMS 2003 Client Health : GP Based Script

Source:-http://www.myitforum.com/absolutenm/templates/Articles.aspx?articleid=17217&zoneid=87

 

Overview

Workstation Client Health maintenance is a continuous process that must be maintained. The following document gives an overview on how to fix several common workstation issues.
CliFix GPO startup script :- Can be downloaded from here http://myitforum.com/cs2/blogs/scassells/Public_SMS_CLIFIX_4.19.vbs.txt
In an effort to reduce the amount of common workstation issues I have developed a script to check and change the following common issues. This script is to be run via GPO startup scripts. This requires the script to work as the system account and have intranet connectivity. Both are accomplished by running as a GPO. Script Requirements
  1. Script must be in a location where the computers system account has access. Usually on your domain controller ex. \\FQDNDomain\sysvol\ FQDNDomain\
  2. sc.exe must be present for full successful run.
    1. Either in the run path
    2. system32
    3. system32\DLLCache
    4. Note: there are multiple versions floating around in the average environment
  3. regsvr32.exe needs to be present
  4. %systemroot%\system32 needs to be in system path
Script Settings

All, unless I missed some, sections of the script can be turned on and off in the top of the script. Please review the script as some features will fail without modification.

Please Review the following CONFIG SETTINGS Variables:

  • SMSVersion
  • ConfigMgrVersion
  • WKS_ASSIGNSITECODE
  • WKS_CacheSize
  • WKS_LocalAdminGroup
  • WKS_admACCT
  • RegPath
  • strWebAddress
  • StrCCRServer
  • strCCRSiteCode
  • CCMSetUP
What the Script Does
  1. Checks to make sure the script has not run in X many hours.
    1. Example if X = 12 the script will not run again until at least 12 hours after the last occurrence.
    2. This will prevent a slow down on multiple reboots.
  2. Sets DCOM permissions to be correct for SMS / SCCM configuration
  3. Checks to make sure System Path has the 3 required windows paths enabled. (does NOT use WMI or require a restart to change values)
    1. C:\windows
    2. C:\windows\sysetm32
    3. C:\windows\system32\wbem
    4. Also removes %systemroot% from path replacing it with correct full path value
    5. If one of the 3 paths is missing, it will parse the full path removing duplicates and adding a,b,or c to the beginning of the path statement leaving all else unchanged.
  4. Check to see if sc.exe exists in the run from directory and if not in the system32 directory
  5. Checks to see if this script is run on a workstation or server. If a server kills the script
  6. Checks to make sure the correct local admin group is present (value is set in header of script)
  7. Checks WMI service to see if it is set to auto and running. If not executes sc.exe to start the service.
  8. Attempts to connect to WMI object
  9. If the WMI object connect fails
    1. Attempt to do a repair (if no previous status is present in the registry and approved via script switches)
    2. Attempt to do a rebuild (if ‘repair’ status is present in the registry and approved via script switches)
    3. If both the above have failed then do nothing and report major error
  10. Checks to see if Admin$ is present, if not forces existence via WMI
  11. Checks to see if msxml3.dll is registered, if not forces existence via WSH
  12. Checks to see if Qmgr.dll and qmgrprxy.dll are registered, if not forces existence via WSH
  13. Checks to see if OLEAut32.dll is registered, if not forces existence via WSH
  14. Checks to make sure the following services are set to appropriate Status and Mode
    1. RPC
    2. WMI
    3. Firewall/ICS
    4. Server Service
    5. Remote Registry
    6. BITS
    7. Windows Update Services
    8. Terminal Services
    9. Windows Installer
    10. Note: You may want to review the settings for your environment on each of these services. All of the above services are set to default and either Manual or Automatic.
  15. Check the SMS version
  16. Checks the CCMExec service
  17. If SMS is not correct version can be forced to do an install
    1. Needs Review
  18. If the all of the above test passed without issue you have a healthy workstation. The following two checks are for SMS.
    1. Check log file last update time. If the PolicyEvaluator.log file has not been modified in past 14 days do a repair of the client.
    2. Check client assignment. If no assignment set new site code based on AD boundaries in which the client is present.
      1. Note: Some people may want to disable this as it relies on AD
  19. If any fixes above had to be preformed
    1. Check the advanced client state. Which client policies have enabled.
    2. Check the cache size
    3. Send a Client Configuration Request (CCR) to have client installed
    4. Run CCMSetup from the install share on the server.
Note during this script several forms of reporting, logging, and information submitting have been preformed. The standard methods of reporting are:
  • Event log
  • Log file in the %temp% directory for the account used to run
    • GPO = C:\windows\temp
  • Reporting to a website that submits client status to a SQL table.
    • Future WebPost on how to do this
Other verbose methods include:· Two levels of command line reportingo Log to Command lineo Verbose to command line· network share copy

Future Additions:

Area's that need improvement