Tuesday, August 10, 2010

Re assignment of SCCM client into different Hierarchy

when we reassign SCCM Client from one Hierarchy to another, the client already has a trusted root key from its original hierarchy. Reassigning the client to a new hierarchy means that the client will also be assigned to a new management point. When both the trusted root key and the management point changes, by default, the client will become unmanaged. In this scenario, the Advanced Client component will send the status message ID 10822 to the site, with a description that it encountered a certificate for a management point that it could not verify. Additionally, the client log file Locationservices.log will display the errors like : The trusted key, mp certificate and the mp machine have changed on server. The client cannot validate the authentication information.
--------
If you want to just reassign a client to a new hierarchy without reinstalling it, you have two options:

•Pre-provision the client with the trusted root key for the new hierarchy, using one of the procedures in the topic How to Pre-Provision the Trusted Root Key on Clients. This is the recommend method because it is more secure.
•Remove the trusted root key from client, using the procedure in the topic How to Remove the Trusted Root Key.

Alternatively, when you reassign the client, you can also reinstall it by using a method that includes the trusted root key. For example:

•Client push, which automatically includes the trusted root key without your having to specify it.
•CCMSetup and include the option SMSPublicRootKey or SMSROOTKEYPATH.

Tuesday, August 3, 2010

Force DCM Evaluation Remotely

On Error Resume Next
CompName = Wscript.Arguments(0)
If compname = "" Then
CompName = InputBox("Input a Computer name or IP", "Computer Name",CompName)
End If
err.clear
set DCMInvoke = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_
CompName & "\root\ccm\dcm:SMS_DesiredConfiguration")
if err.number <> 0 then
msgbox "unable to access " & CompName & vbcr &_
"Error: " & err.description,,"SMS DCM Trigger Evaluation"
else
Set objSWbemServices = GetObject("winmgmts:\\" & CompName & "\root\ccm\dcm")
Set colSWbemObjectSet = objSWbemServices.ExecQuery("SELECT * FROM SMS_DesiredConfiguration")
For Each objSWbemObject In colSWbemObjectSet
DCMInvoke.TriggerEvaluation objSWbemObject.Name,objSWbemObject.Version
Next
end if

Monday, August 2, 2010

Waiting to install package on some DP's

Modify the PkgStatus table on the central site server SQL database and then refresh the affected DP's


update pkgstatus set Status = 2 where id = '' and sitecode = '' and type = 1
update pkgstatus set SourceVersion = 0 where id = '' and sitecode = '' and type = 1

Friday, July 30, 2010

SCCM Client to Wait due to Conflicting Records

If you have an SCCM client that's installed correctly, but seems to not be performing any usual SCCM actions, check the the "ClientIDManagerStartup.log" log file (located under %WIN%\SYSTEM32\CCM\LOGS).

Look for the following lines in the "ClientIDManagerStartup.log" log file:

RegTask: Client is not registered. Sending registration request...
RegTask: Client registration is pending.
Client is pending registration. Sending confirmation request...
Server requested reset. Restarting client registration
Already refreshed within the last 10 minutes, Sleeping for the next 9 minutes before reattempt.

This indicates the Hardware ID for the SCCM client has recently changed, and there are multiple records for the client in the SCCM database. The SCCM client will not perform any actions until the "conflicting records" issue is resolved.

To resolve the issue, an SCCM administrator must open the SCCM console and merge the multiple records together into a single record. Once this is completed, the client will update its records and start performing normal tasks.

Client Inventory is not showing in DATABASE

I recently had a problem with client inventory data not being present in the SCCM database. I was making a query to find machines running Windows XP with Service Pack 3, and it only reported back 6 or 7 clients,Knowing that a lot more had the service pack installed.

I checked the logs on some of my clients and they seemed to report both hardware and software inventory just fine, and sent it to my management point. I checked the logs on my SCCM server and every time i recieved the inventory report from clients I got an SQL error saying that the rows in my table could not be updated. This lead me to believe that the client had never been in the table, and as suspected, my OperatingSystem table (the table that contains data about a client operating system, and in this case what service pack is installed) only had a few machines present. Somehow my management point had stopped inserting data into the tables.

I resolved this issue simply by removing and re-installing my management point role on my SCCM server, but it lead to several hours of head-scratching!

WMI Reapir

Steps to rebuild WMI manually
1. Assure your account has administrative privilege
2. Type the command in a command prompt window (or paste below commands on the window).

net stop winmgmt /y



c:
cd %windir%\system32\wbem
if exist %windir%\system32\wbem\repository.old rmdir /s /q repository.old
rename %windir%\system32\wbem\repository repository.old
for /f %i in ('dir /b *.dll') do regsvr32 /s %i
for /f %i in ('dir /b *.mof *.mfl') do mofcomp %i

Monday, July 19, 2010

Pending packages/Task Tequence troubleshooting

To resolve this issue is to modify the PkgStatus table on the central site server SQL database, and then refresh the affected distribution points.Run The SQL query for each affected distribution point.

update pkgstatus set Status = 2 where id = '< package ID >' and sitecode = '< site code >' and type = 1

update pkgstatus set SourceVersion = 0 where id = '< package ID >' and sitecode = '< site code >' and type = 1

Note:
Microsoft stated that this issue can randomly occur in larger SCCM environments with large packages and slow WAN links, and they are unable to exactly pinpoint the problem due to its random nature

Friday, July 16, 2010

SCCM console get hanged in monthly patch cycle

- Run WBEMTest and connect to Root
- Click 'Open Instance', enter __ProviderHostQuotaConfiguration=@ and click OK
- Locate the MemoryPerHost property and double click it to bring up the editor
- Note the current value, replace it with 402653184 and click Save Property
- Locate the HandlesPerHost property, note the current value, set it to 16384 and click Save Property
- Click Save Object and then Exit WBEMTest