These are few things which I have shared for loving helpdesk engineers who help us to achieve healthy sccm environment.
ccmsetup - for checking ccmsetup installation and uninstallation activity logs
ccm - for checking downloaded content cache, client's logs, inventory, metering and other client related information
ccm/smsrap.cpl - for checking available programs listed on client's Run Advertised Programs under Control panel
Cheers!
Showing posts with label SCCM Client. Show all posts
Showing posts with label SCCM Client. Show all posts
March 4, 2011
February 20, 2011
Client installed but showing as 'No' to SCCM console - troubleshooting tips #4
Hi Again,
While SCCM admins plan to upgrade sms client to sccm client and you have a large SCCM infrastructure with multiple sites, make sure that you have configured site code within client push installation method of primary sites or if you have planned to upgrade clients with software distribution methods, don't use auto discovery for all clients, it can cause you a large no of unhealthy clients. You will see number of clients which have client installed but showing as 'No' to sccm console. To eliminate this, you can prepare site wise client upgrade package and can deploy it to respective sites.
One more good option is to prepare a script which will discover client's site boundary (AD site) and assign site code immediately. this script can be deploy to all clients within your sccm infrastructure centrally.
Anyway, if you have such computers in which client is installed but showing 'No' in console, one more option is to set the correct site code and resolve the issue.
Hope it helps.
While SCCM admins plan to upgrade sms client to sccm client and you have a large SCCM infrastructure with multiple sites, make sure that you have configured site code within client push installation method of primary sites or if you have planned to upgrade clients with software distribution methods, don't use auto discovery for all clients, it can cause you a large no of unhealthy clients. You will see number of clients which have client installed but showing as 'No' to sccm console. To eliminate this, you can prepare site wise client upgrade package and can deploy it to respective sites.
One more good option is to prepare a script which will discover client's site boundary (AD site) and assign site code immediately. this script can be deploy to all clients within your sccm infrastructure centrally.
Anyway, if you have such computers in which client is installed but showing 'No' in console, one more option is to set the correct site code and resolve the issue.
Hope it helps.
February 6, 2011
can't reinstall sccm client on machine 'MSI: Could not delete key'
Please find below scenarios with respective troubleshooting steps- MSI: Could not delete key \SOFTWARE\Classes\CLSID\{84ECA343-5158-48BB-87C3-37EF4B919F20}. Verify that you have sufficient access to that key, or contact your support personnel.
MSI: Setup was unable to create the WMI namespace CCM\SoftwareMetering Agent The error code is 80041002
'script here
net stop ccmexec
net stop winmgmt
%SYSTEMDRIVE%
CD %windir%\system32\wbem
rd /S /Q repository
net start winmgmt
net start ccmexec
for /f %%s in ('dir /b /s *.dll') do regsvr32 /s %%s
for /f %%s in ('dir /b *.mof') do mofcomp %%s
wmiprvse /regserver
Hope it helps.
- Open command prompt window with run as account domain\smsclient account (to avoid any access related issue)
- Run ccmclean .exe /Q /All (I know that we can remove sccm client with ccmsetup.exe /uninstall switch but it seems that legacy sms client settings prevent sccm upgrade and thus, it needs to be uninstalled properly)
- Run installsccm.bat file on machine to install sccm client (please verify ccmsetup.log file for successful installation)
- Open command prompt window with run as account tp1\srvsmsclinst (to avoid any access related issue)
- Run ccmclean .exe /Q /All (I know that we can remove sccm client with ccmsetup.exe /uninstall switch but it seems that legacy sms client settings prevent sccm upgrade and thus, it needs to be uninstalled properly)
- Run setWMI.bat to repair WMI (I use below script and have got 100% success @all time)
- Run installsccm.bat file on machine to install sccm client (please verify ccmsetup.log file for successful installation).
'script here
net stop ccmexec
net stop winmgmt
%SYSTEMDRIVE%
CD %windir%\system32\wbem
rd /S /Q repository
net start winmgmt
net start ccmexec
for /f %%s in ('dir /b /s *.dll') do regsvr32 /s %%s
for /f %%s in ('dir /b *.mof') do mofcomp %%s
wmiprvse /regserver
Hope it helps.
January 13, 2011
Important tips for SCCM Client Upgrade/Reinstall
If you are upgrading sms clients to sccm, you can run sccm client setup file directly to machines as it automatically detects any legacy version of sms and removes (uninstalls) it.
but if you have any problem with existing SCCM client and you really want to reinstall client to make it healthy, don't run ccmsetup.exe file directly to machine, first uninstall sccm client using ccmsetup.exe /uninstall from machine and then install it.
Note: Always try to lookup on sccm client logs for better troubleshooting and try repair client if it was working earlier and finally reinstall it.
but if you have any problem with existing SCCM client and you really want to reinstall client to make it healthy, don't run ccmsetup.exe file directly to machine, first uninstall sccm client using ccmsetup.exe /uninstall from machine and then install it.
Note: Always try to lookup on sccm client logs for better troubleshooting and try repair client if it was working earlier and finally reinstall it.
Client installed but showing as 'No' to SCCM console - troubleshooting tips #3
It's better to understand the difference between reinstalling sccm client and repairing sccm client. When you reinstall a client, it creates SMS classes in WBEM repository, initiates policies for notification to SCCM management point and gets new SMS GUID as an identification but it won't delete the exisitng GUID (SMS keeps it until we delete certificate using ccmdelcert.exe from the toolkit.. or uninstall sccm client porperly). SMS identifies it as new record and acts on it as new client. If you have added this machine to somewhere your system based collection, it won't be getting any policies. Machine, having old GUID certificate, would be negligable and policies would be rejected from respective Management point.
While, if you repair a client; it removes old certs, assigns it new certificate and initiates policies as unique record. It works properly and policies are apporved by MP.
Cheers!
While, if you repair a client; it removes old certs, assigns it new certificate and initiates policies as unique record. It works properly and policies are apporved by MP.
Cheers!
January 8, 2011
Client installed but showing as 'No' to SCCM console - troubleshooting tips #2
During troubleshooting this strange behaviour, I got to know that if sms clients are not upgraded as sccm clients, they will show status as Client installed 'Yes' but it won't be approved by site and will not work properly.
In other scenario, it might show client installed status as 'No' if your client is not upgraded or is not assigned to respective site.
You need to query all clients with legacy version and install sccm client on these machines.
In other scenario, it might show client installed status as 'No' if your client is not upgraded or is not assigned to respective site.
You need to query all clients with legacy version and install sccm client on these machines.
November 26, 2010
Troubleshooting Tips: Non SCCM & Unhealthy Client Machines
Troubleshooting Tips: Non SCCM & Unhealthy Client Machines
Sometimes the most challenging part of the Configuration Manager 2007/SMS 2003 deployment phase can be ensuring that the client successfully reports to the site server. We occasionally see these issues here in support, typically either as cases for clients not reporting after the client installation, or maybe where it’s noticed that the client count is decreasing from the collection.
When we look at the SMS/SCCM console collection, there is an entry for the client status that indicates either Yes or No. Assuming everything is installed and configured properly, a client installed on a system should automatically report as Yes, but sometimes that does not turn out to be the case. The reason could be that the client has not yet reported to the SCCM\SMS server, or it was reporting previously but has now stopped. Managing the client in the collection is a continuous task and for a healthy environment the client should be continuously reporting to the SMS\SCCM server.
There are various reasons why a client may not be able to report to even if the SMS\SCCM agent is installed on a machine. A few of these reasons are discussed below:
The first thing to check is whether the client is on the network, and if it’s not on the network, does the system even exist? It’s possible that represents a stale record from AD.
Systems NOT on the network: If the system is not actually on the network, check if it is shutdown, and if so if it’s been shut down for long time. If yes then first restart the system and then initiate the discovery cycle from the control panel agent properties action TAB.
Stale Entries: When you use AD discovery, the DDRs are created for the computers that reside in the AD container that we have requested to be queried by the discovery process. If that container has the stale records for the resources, then client records may be created for systems that don’t actually exist, thus they will never report.
There is a Maintenance task that will clear the inactive records but if the discovery process runs again and the AD container still has these entries then they will simply show up again.
Resolution: For the stale records you need to make sure that the AD container is cleared of these stale records and scavenging is done for the computers container in AD regularly. Once this is done you can either make use of the maintenance task or you can create a collection for the NON SMS CLIENTS and then do a delete special to the collection so that the entries will be removed permanently from the SMS\SCCM database. Then a discovery can be run which will bring back only the active systems in the collection.
Once the agent is available on the network and the client is installed, the client goes through the following actions as part of the reporting process:
1. Client location services identify the site code and the MP it is supposed to connect to.
2. The client connects to the Management Point and downloads the policies.
3. Once the policies are downloaded it sends the heartbeat record to the server.
4. Once the server receives this heartbeat record these are converted in to DDR and processed. This will set the client flag to 1 which will make the client status display as Yes in the console.
5. On a regular basis the agent will send the heartbeat and if no heart beat or inventory shows up for a length of time then the client flag will be marked as 0 by the client flag maintenance task, setting the client status to No.
So only if this process is completed and it continues to happen will the client remain reporting to the server. This is why I said earlier that client management is a continuous task. There can be a variety of reasons why this process might fail, and I’ve outlined a couple of them below:
The Boundaries of the Agent are not specified in the site server
If the client is not assigned in the console or the client is unable to discover the site code, make sure that the AD site or the IP subnet is added in the boundary list. The server will only allow those clients within its boundary to download the policies, so if you have not specified the boundaries the client will not be authorized and the policies will not get downloaded. For boundary issues you can use this as a reference:
In the client if you check the location services.log (log location: C:\Windows\System32\CCM\Logs), you can get the information of the site assigned to it as well as the MP it is reporting to. If it is not able to report properly, you need to make sure that the agent can communicate over the network to the site server successfully.
Unable to get the site code
If the client is not able to get the site code, you need to check first the boundaries as above, and also verify that the site information is published in the AD. You can check the last part of the sitecomp.log after you start the site component manager which will say that the components like the MP, SLP etc successfully published or updated. If you are unable to see that and you get access denied errors, make sure that the computer account has read\write permission to the system container in AD. Make sure the permission is flowing to the objects within and the objects below. If you are not publishing the information in AD then you need to make sure that the SLP is configured and working.
The client itself is not installed in the Agent
To confirm this, try checking ccmexec.log file from client machine or check ccm.log from server end.
Make a list if you find any of these issues-
1. Newly discovered client computers are not assigned to the current site
2. Advanced Client Push Installation is not enabled at the appropriate site
3. The SMS Client Configuration Manager cannot connect to the client Admin$ share or to the Remote Registry Service (IPC$)
4. The SMS Advanced Client Push Installation account is configured incorrectly or is missing or is locked out
5. The SMS Advanced Client cannot access the installation file on the SMS site server
6. The SMS Advanced Client cannot access the management point during an upgrade
7. The SMS Advanced Client displays a site assignment but does not appear as installed
8. The Client computer appears in collections with the following values:
Site Code Client Assigned Client Type
This occurs when one or more of the following conditions are true:
a) The collection information has not been updated. Collection updates usually run on a daily or weekly schedule. In this case, you must make sure that the collection information has been updated. You can manually update the collection membership, and then update the collection view.
b) The client computer shares the same SMSID with another client computer. This issue can occur when you use a disk image to install the SMS Advanced Client. Duplicate SMSIDs are also referred to as duplicate GUIDs. You must determine whether duplicate SMSIDs exist on the client computers. For more information about how to detect duplicate GUIDs and how to use Tranguid.exe to create a New SMS GUID for the affected clients.
c) The SMS Advanced Client is assigned. However, the SMS Advanced Client is not installed. You must verify that the SMS Advanced Client is installed successfully and is assigned to the site that you are viewing.
d) The Network Discovery method is enabled. When you use the Network Discovery method in Systems Management Server (SMS), it populates the IsClient fields in the database by using a Null value. If other discovery methods are enabled, the computer will appear in the collection as Assigned with no client installed even though the client is installed. To resolve this issue, disable the Network Discovery method. Also, verify that the Heartbeat Discovery method that is enabled by default has not been disabled. Then, wait for the specified Heartbeat Discovery polling interval to pass. When the clients send up new discovery data, the database is updated to reflect the correct values.
Note Only the Heartbeat Discovery method will set the client installation status to Yes. The Active Directory System discovery method does not update the IsClient field in the SMS database.
e) Heartbeat Discovery has not reported since the client was installed.
There is a name resolution issue in the Client.
Make sure that the client is able to communicate to the SMS\SCCM server using the FQDN as well as the NetBIOS name. Use Nslookup or ping to check the name resolution. If you can’t ping the server using the FQDN then you will have problems.
The client is behind a firewall
If clients are behind a firewall, it may be restricting it from contacting the SMS site server. Check if the necessary ports are opened.
MP not working as a result of which the policies are not getting downloaded
You first need to check to see whether the MP is working. For that you will need to check the mpcontol .log (Log location: \SMS\logs in SMS and \program files\Microsoft Configuration Manager\logs in SCCM). If it is showing a 200 OK status code then that means the MP is working.
If the MP is working fine and the client is unable to contact and download polices, you will have an error on download in the policyagent.log file on the agent (Log location: C:\Windows\System32\CCM\Logs). Before checking this though, check if the locationservices.log has the correct MP information. If it does have the correct MP information, make sure that the BITS service is started on the client. You can try the following URLs to verify that this is working:
http:///sms_mp/.sms_aut?mplist
and
http:///sms_mp/.sms_aut?mpcert
Client is unable to download policy
You may also have issues downloading policies if the client agent has WMI corruption. If you suspect this to be the cause of your issue, if it is a XP client then follow these steps:
1. Uninstall SCCM client agent. Use the ccmsetup.exe /uninstall
2. Troubleshoot or rebuild WMI.
When to rebuild WMI : SCCM Client is not able to install on machines.
When to repair WMI : SCCM Client is installed on machines but inventory data is not reporting to SCCM database.
3. Restart the system and install the agent.
Server unable to process DDR
Once you find that the client is able to send the heartbeat data to the server, you next need to check on the server to see if these are getting processed successfully.
Clients going to NO after it had reported
1. The first reason for this is that the heartbeat discovery is enabled and that the DDRs are not reaching the server.
2. The second is that Clear Install Flag is running.
Solution: Initiate Discovery data collection cycle manually from client and update collection after few minutes.
Thanks.
Sometimes the most challenging part of the Configuration Manager 2007/SMS 2003 deployment phase can be ensuring that the client successfully reports to the site server. We occasionally see these issues here in support, typically either as cases for clients not reporting after the client installation, or maybe where it’s noticed that the client count is decreasing from the collection.
When we look at the SMS/SCCM console collection, there is an entry for the client status that indicates either Yes or No. Assuming everything is installed and configured properly, a client installed on a system should automatically report as Yes, but sometimes that does not turn out to be the case. The reason could be that the client has not yet reported to the SCCM\SMS server, or it was reporting previously but has now stopped. Managing the client in the collection is a continuous task and for a healthy environment the client should be continuously reporting to the SMS\SCCM server.
There are various reasons why a client may not be able to report to even if the SMS\SCCM agent is installed on a machine. A few of these reasons are discussed below:
The first thing to check is whether the client is on the network, and if it’s not on the network, does the system even exist? It’s possible that represents a stale record from AD.
Systems NOT on the network: If the system is not actually on the network, check if it is shutdown, and if so if it’s been shut down for long time. If yes then first restart the system and then initiate the discovery cycle from the control panel agent properties action TAB.
Stale Entries: When you use AD discovery, the DDRs are created for the computers that reside in the AD container that we have requested to be queried by the discovery process. If that container has the stale records for the resources, then client records may be created for systems that don’t actually exist, thus they will never report.
There is a Maintenance task that will clear the inactive records but if the discovery process runs again and the AD container still has these entries then they will simply show up again.
Resolution: For the stale records you need to make sure that the AD container is cleared of these stale records and scavenging is done for the computers container in AD regularly. Once this is done you can either make use of the maintenance task or you can create a collection for the NON SMS CLIENTS and then do a delete special to the collection so that the entries will be removed permanently from the SMS\SCCM database. Then a discovery can be run which will bring back only the active systems in the collection.
Once the agent is available on the network and the client is installed, the client goes through the following actions as part of the reporting process:
1. Client location services identify the site code and the MP it is supposed to connect to.
2. The client connects to the Management Point and downloads the policies.
3. Once the policies are downloaded it sends the heartbeat record to the server.
4. Once the server receives this heartbeat record these are converted in to DDR and processed. This will set the client flag to 1 which will make the client status display as Yes in the console.
5. On a regular basis the agent will send the heartbeat and if no heart beat or inventory shows up for a length of time then the client flag will be marked as 0 by the client flag maintenance task, setting the client status to No.
So only if this process is completed and it continues to happen will the client remain reporting to the server. This is why I said earlier that client management is a continuous task. There can be a variety of reasons why this process might fail, and I’ve outlined a couple of them below:
The Boundaries of the Agent are not specified in the site server
If the client is not assigned in the console or the client is unable to discover the site code, make sure that the AD site or the IP subnet is added in the boundary list. The server will only allow those clients within its boundary to download the policies, so if you have not specified the boundaries the client will not be authorized and the policies will not get downloaded. For boundary issues you can use this as a reference:
In the client if you check the location services.log (log location: C:\Windows\System32\CCM\Logs), you can get the information of the site assigned to it as well as the MP it is reporting to. If it is not able to report properly, you need to make sure that the agent can communicate over the network to the site server successfully.
Unable to get the site code
If the client is not able to get the site code, you need to check first the boundaries as above, and also verify that the site information is published in the AD. You can check the last part of the sitecomp.log after you start the site component manager which will say that the components like the MP, SLP etc successfully published or updated. If you are unable to see that and you get access denied errors, make sure that the computer account has read\write permission to the system container in AD. Make sure the permission is flowing to the objects within and the objects below. If you are not publishing the information in AD then you need to make sure that the SLP is configured and working.
The client itself is not installed in the Agent
To confirm this, try checking ccmexec.log file from client machine or check ccm.log from server end.
Make a list if you find any of these issues-
1. Newly discovered client computers are not assigned to the current site
2. Advanced Client Push Installation is not enabled at the appropriate site
3. The SMS Client Configuration Manager cannot connect to the client Admin$ share or to the Remote Registry Service (IPC$)
4. The SMS Advanced Client Push Installation account is configured incorrectly or is missing or is locked out
5. The SMS Advanced Client cannot access the installation file on the SMS site server
6. The SMS Advanced Client cannot access the management point during an upgrade
7. The SMS Advanced Client displays a site assignment but does not appear as installed
8. The Client computer appears in collections with the following values:
Site Code Client Assigned Client Type
This occurs when one or more of the following conditions are true:
a) The collection information has not been updated. Collection updates usually run on a daily or weekly schedule. In this case, you must make sure that the collection information has been updated. You can manually update the collection membership, and then update the collection view.
b) The client computer shares the same SMSID with another client computer. This issue can occur when you use a disk image to install the SMS Advanced Client. Duplicate SMSIDs are also referred to as duplicate GUIDs. You must determine whether duplicate SMSIDs exist on the client computers. For more information about how to detect duplicate GUIDs and how to use Tranguid.exe to create a New SMS GUID for the affected clients.
c) The SMS Advanced Client is assigned. However, the SMS Advanced Client is not installed. You must verify that the SMS Advanced Client is installed successfully and is assigned to the site that you are viewing.
d) The Network Discovery method is enabled. When you use the Network Discovery method in Systems Management Server (SMS), it populates the IsClient fields in the database by using a Null value. If other discovery methods are enabled, the computer will appear in the collection as Assigned with no client installed even though the client is installed. To resolve this issue, disable the Network Discovery method. Also, verify that the Heartbeat Discovery method that is enabled by default has not been disabled. Then, wait for the specified Heartbeat Discovery polling interval to pass. When the clients send up new discovery data, the database is updated to reflect the correct values.
Note Only the Heartbeat Discovery method will set the client installation status to Yes. The Active Directory System discovery method does not update the IsClient field in the SMS database.
e) Heartbeat Discovery has not reported since the client was installed.
There is a name resolution issue in the Client.
Make sure that the client is able to communicate to the SMS\SCCM server using the FQDN as well as the NetBIOS name. Use Nslookup or ping to check the name resolution. If you can’t ping the server using the FQDN then you will have problems.
The client is behind a firewall
If clients are behind a firewall, it may be restricting it from contacting the SMS site server. Check if the necessary ports are opened.
MP not working as a result of which the policies are not getting downloaded
You first need to check to see whether the MP is working. For that you will need to check the mpcontol .log (Log location: \SMS\logs in SMS and \program files\Microsoft Configuration Manager\logs in SCCM). If it is showing a 200 OK status code then that means the MP is working.
If the MP is working fine and the client is unable to contact and download polices, you will have an error on download in the policyagent.log file on the agent (Log location: C:\Windows\System32\CCM\Logs). Before checking this though, check if the locationservices.log has the correct MP information. If it does have the correct MP information, make sure that the BITS service is started on the client. You can try the following URLs to verify that this is working:
http://
and
http://
Client is unable to download policy
You may also have issues downloading policies if the client agent has WMI corruption. If you suspect this to be the cause of your issue, if it is a XP client then follow these steps:
1. Uninstall SCCM client agent. Use the ccmsetup.exe /uninstall
2. Troubleshoot or rebuild WMI.
When to rebuild WMI : SCCM Client is not able to install on machines.
When to repair WMI : SCCM Client is installed on machines but inventory data is not reporting to SCCM database.
3. Restart the system and install the agent.
Server unable to process DDR
Once you find that the client is able to send the heartbeat data to the server, you next need to check on the server to see if these are getting processed successfully.
Clients going to NO after it had reported
1. The first reason for this is that the heartbeat discovery is enabled and that the DDRs are not reaching the server.
2. The second is that Clear Install Flag is running.
Solution: Initiate Discovery data collection cycle manually from client and update collection after few minutes.
Thanks.
November 24, 2010
Client installed but showing as 'No' to SCCM console - troubleshooting tips
It generally happens during upgrade or restructuring of SMS/SCCM infrastructure. Anyway, if it happens with you, try below steps-
1. list out all these clients or make collection of these clients
2. run script to trigger discovery data collection cycle on listed machines or use right click tools to initiate discovery data collection cycle on machines listed in collection
3. once you have finished with above two actions, try update collection membership and refersh then.
4. Check status and make yourself happy.
Pls find link to download right click tools.
http://myitforum.com/cs2/blogs/rhouchins/0401ConfigMgrTools.zip
and here's script to initiate discovery data collection cycle on affected clients-
'copy below code to notepad and save it as discovery.vbs
'and run remotely on clients with help of psexec.exe utility
actionNameToRun = "Discovery Data Collection Cycle"
Dim controlPanelAppletManager
Set controlPanelAppletManager = CreateObject("CPApplet.CPAppletMgr")
Dim clientActions
Set clientActions = controlPanelAppletManager.GetClientActions()
Dim clientAction
For Each clientAction In clientActions
If clientAction.Name = actionNameToRun Then
clientAction.PerformAction
End If
Next
wscript.echo "Executed: " & actionNameToRun ' if you want to get message
these are some more actions which can be used in above script as and when required-
'Software Metering Usage Report Cycle
'Request & Evaluate Machine Policy
'Updates Source Scan Cycle
'Request & Evaluate User Policy
'Hardware Inventory Collection Cycle
'Software Inventory Collection Cycle
'Software Updates Assignments Evaluation Cycle
'Peer DP Maintenance Task
'Machine Policy Retrieval & Evaluation Cycle
'MSI Product Source Update Cycle
Happy troubleshooting!
1. list out all these clients or make collection of these clients
2. run script to trigger discovery data collection cycle on listed machines or use right click tools to initiate discovery data collection cycle on machines listed in collection
3. once you have finished with above two actions, try update collection membership and refersh then.
4. Check status and make yourself happy.
Pls find link to download right click tools.
http://myitforum.com/cs2/blogs/rhouchins/0401ConfigMgrTools.zip
and here's script to initiate discovery data collection cycle on affected clients-
'copy below code to notepad and save it as discovery.vbs
'and run remotely on clients with help of psexec.exe utility
actionNameToRun = "Discovery Data Collection Cycle"
Dim controlPanelAppletManager
Set controlPanelAppletManager = CreateObject("CPApplet.CPAppletMgr")
Dim clientActions
Set clientActions = controlPanelAppletManager.GetClientActions()
Dim clientAction
For Each clientAction In clientActions
If clientAction.Name = actionNameToRun Then
clientAction.PerformAction
End If
Next
wscript.echo "Executed: " & actionNameToRun ' if you want to get message
these are some more actions which can be used in above script as and when required-
'Software Metering Usage Report Cycle
'Request & Evaluate Machine Policy
'Updates Source Scan Cycle
'Request & Evaluate User Policy
'Hardware Inventory Collection Cycle
'Software Inventory Collection Cycle
'Software Updates Assignments Evaluation Cycle
'Peer DP Maintenance Task
'Machine Policy Retrieval & Evaluation Cycle
'MSI Product Source Update Cycle
Happy troubleshooting!
January 22, 2010
Reasons to malfunctioning of SMS/SCCM Clients
SMS Client Malfunctioning: Possible reasons
1. Machines are not in network.
2. AD Stale Objects
3. Machines not coming under the specified site boundaries
4. Site Code Not Assigned to the machines properly
5. Name Resolution Issue
6. Firewall restrictions: Relevant Ports used by SMS/SCCM should be opened
7. Machines with duplicate GUIDs
8. Policies are not getting downloaded from MP (Management Point)
9. Management Point not functioning well
10. The SMS Client Configuration Manager cannot connect to the client Admin$ share or to the Remote Registry Service (IPC$)
11. The SMS Advanced Client Push Installation account is configured incorrectly or is missing or is locked out
12. Advanced Client Push Installation is not enabled at the appropriate site
13. Newly discovered client computers are not assigned to the current site
14. The SMS Advanced Client Network Access Account is configured incorrectly or is missing or is locked out in a non-Active Directory environment
15. The SMS Advanced Client cannot access the installation file on the SMS site server
16. Clear Install Flag is running: As a result, sms client will reported as NO.
1. Machines are not in network.
2. AD Stale Objects
3. Machines not coming under the specified site boundaries
4. Site Code Not Assigned to the machines properly
5. Name Resolution Issue
6. Firewall restrictions: Relevant Ports used by SMS/SCCM should be opened
7. Machines with duplicate GUIDs
8. Policies are not getting downloaded from MP (Management Point)
9. Management Point not functioning well
10. The SMS Client Configuration Manager cannot connect to the client Admin$ share or to the Remote Registry Service (IPC$)
11. The SMS Advanced Client Push Installation account is configured incorrectly or is missing or is locked out
12. Advanced Client Push Installation is not enabled at the appropriate site
13. Newly discovered client computers are not assigned to the current site
14. The SMS Advanced Client Network Access Account is configured incorrectly or is missing or is locked out in a non-Active Directory environment
15. The SMS Advanced Client cannot access the installation file on the SMS site server
16. Clear Install Flag is running: As a result, sms client will reported as NO.
January 14, 2010
Client Computer Log Files
CAS.log: Provides information about the process of downloading software updates to the local cache and cache management.
CIAgent.log:Provides information about processing configuration items, including software updates.
LocationServices.log: Provides information about the location of the WSUS server when a scan is initiated on the client.
PatchDownloader.log:Provides information about the process for downloading software updates from the update source to the download destination on the site server. This log is only on the client computer configured as the synchronization host for the Inventory Tool for Microsoft Updates.
PolicyAgent.log: It provides information about the process for downloading, compiling, and deleting policies on client computers.
PolicyEvaluator: It provides information about the process for evaluating policies on client computers, including policies from software updates.
RebootCoordinator.log: It provides information about the process for coordinating system restarts on client computers after software update installations.
ScanAgent.log: It provides information about the scan requests for software updates, what tool is requested for the scan, the WSUS location, and so on.
ScanWrapper.log: It provides information about the prerequisite checks and the scan process initialization for the Inventory Tool for Microsoft Updates on Systems Management Server (SMS) 2003 clients.
CIAgent.log:Provides information about processing configuration items, including software updates.
LocationServices.log: Provides information about the location of the WSUS server when a scan is initiated on the client.
PatchDownloader.log:Provides information about the process for downloading software updates from the update source to the download destination on the site server. This log is only on the client computer configured as the synchronization host for the Inventory Tool for Microsoft Updates.
PolicyAgent.log: It provides information about the process for downloading, compiling, and deleting policies on client computers.
PolicyEvaluator: It provides information about the process for evaluating policies on client computers, including policies from software updates.
RebootCoordinator.log: It provides information about the process for coordinating system restarts on client computers after software update installations.
ScanAgent.log: It provides information about the scan requests for software updates, what tool is requested for the scan, the WSUS location, and so on.
ScanWrapper.log: It provides information about the prerequisite checks and the scan process initialization for the Inventory Tool for Microsoft Updates on Systems Management Server (SMS) 2003 clients.
Subscribe to:
Posts (Atom)