Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Thursday, November 13, 2014 2:09 PM
We have over 50,000 clients, 3 Management Points, 1 site and 130 Distribution Points. After using SCCM to install applications and reimage computers for months now, suddenly, we can't do either of those things. No items show up in Software Center. After imaging a new computer (using other methods) there are only 2 items under the Action Tab in the Config Manager Control Panel. Log files do not explain what the problem is. LocationServices log shows it is finding all 3 management points. Not sure where to look to try to figure out why we are having this issue. Restarted all servers. Am able to install Applications from the AppsCatalog.
Any suggestions or pointing to the correct log files? Thank you.
SCCM 2012 R2
All replies (30)
Monday, November 17, 2014 7:41 PM ✅Answered
Found the solution. Once we found that the clients were not receiving the policies it pointed us to the direction of the c:\sms_CCM\logs\MP_Policy.log which then pointed us to these references of same issue...
<o:p>Can't submit links.</o:p>
We followed the examples here running these two queries in SQL
against the SCCM database (the first to see if there were any bad records,
second to delete them):<o:p></o:p>
SELECT * FROM ResPolicyMap WHERE machineid = 0 and PADBID IN
(SELECT PADBID FROM PolicyAssignment WHERE BodyHash IS NULL)<o:p></o:p>
<o:p></o:p>
Delete FROM ResPolicyMap WHERE machineid = 0 and PADBID IN (SELECT
PADBID FROM PolicyAssignment WHERE BodyHash IS NULL)<o:p></o:p>
<o:p></o:p>
I'm not sure what exactly this is removing. It seems to be a
bad record linking policies to a computer. We weren't able to find much
detail on exactly what we were deleting, but it definitely resolved the
issues. Shortly afterwards clients were connecting and receiving policies
as expected.<o:p></o:p>
Any better explanation would be helpful but this solved our problem. Only problem we have now is after being down for 1 week, all of our clients are hitting our servers. CPU is at 100%.
Thank you to all for trying to help.
Thursday, November 13, 2014 2:22 PM
Check that the Management Point is responding to requests
http://cm_server:80/SMS_MP/.SMS_AUT?MPCERT
and
http://cm_server:80/SMS_MP/.SMS_AUT?MPLIST
Gerry Hampson | Blog: www.gerryhampsoncm.blogspot.ie | LinkedIn: Gerry Hampson | Twitter: @gerryhampson
Thursday, November 13, 2014 2:29 PM
Management Points are responding to requests. I received the cert back with the first URL and all 3 management points listed on the 2nd URL. I was thinking of removing the Management Role on all 3 servers and adding it back to see if that helps.
Thursday, November 13, 2014 2:30 PM
I wouldn't do that just for the sake of it. Are there any errors in Component Status or Site Status?
Gerry Hampson | Blog: www.gerryhampsoncm.blogspot.ie | LinkedIn: Gerry Hampson | Twitter: @gerryhampson
Thursday, November 13, 2014 2:42 PM
I did see another forum where someone was having similar issues and removing/adding the management point resolved the issue.
Yes, there are always some errors. The only one that may have something to do with this is SMS_OJBECT_REPLICATION_MANAGER has these Critical errors...
Object Replication Manager failed to process Object changes. These changes will be retried on next processing cycle.
Other errors have more to do with Package Transfers or DPs.
Thursday, November 13, 2014 2:53 PM
While unlikely and only really applicable to new builds, check that the clients appear in Assets and Devices\Devices and are approved - however the usual setting is to auto-approve domain joined clients.
Have you recently deployed a CU? We do see clients switch back to this unconfigured state after a CU install until they retrieve policy again...
The client logs to check would be:
ClientLocation.Log - will show if it's assigned to a site. (check boundaries if they are getting the wrong site or none at all)
LocationServices.Log – will show communication to MP to retrieve policy
And the following three may show up errors in obtaining or processing policies:
PolicyAgent.log
PolicyAgentProvider.log
PolicyEvaluator.log
Thursday, November 13, 2014 3:08 PM
We do have auto-approve set and the client is approved.
We have been at R2 CU1 for about 4 months now.
No errors in policyagent log. End of log shows - Skipping request for user policy assignments due to agent configuration for authority 'SMS:MySiteCode'.
LocationServices do not show any errors
No errors in PolicyAgentProvider Log.
No errors in PolicyEvaluator log - Settings update not required: No changes detected.
Thank you
Thursday, November 13, 2014 5:01 PM
If you use custom client settings, are they deployed to the correct collection - and does that contain the target clients?
Thursday, November 13, 2014 5:05 PM
Hi Bob,
Yes, we do have custom client settings and that policy is deployed to a device collection with 50,000 workstations.
Thank you
Thursday, November 13, 2014 9:23 PM
Just to make sure, is your MP component green? If you restart server or SMS executable service, will MP stay or become green after a while?
Another thing I suggest to check on client side is: ClientIDManagerStartup.log
And this client action missing, does this consern only re-installed machines, right after OSD, right? Existing/living clients are still okay? Will Configuration Manager Task Schedule Evaluation fix clients for you?
Thursday, November 13, 2014 9:40 PM
I take it that you mean SMS_MP_Control_Manager status? Out of the 3 MPs I have one that is green and 2 that are yellow. The Warning message is something like "MP has rejected a message from GUID:630DEB1E-8371-4731-A78C-6CA8158F0CCA because the signature could not be validated. If this is a valid client, it will attempt to re-register automatically so its signature can be correctly validated."
ClientIDManagerStartup.log I find one error message - Failed to open to WMI namespace '\.\root\ccmvdi' (8007045b)
Yes, only reinstalled machines right after OSD. Existing clients do have all "Action items" but when trying to send a task sequence or application to one of those existing machines, Software Center remains empty.
I need to check on the Config Manager Task Schedule Eval? Nothing is working to fix the clients since it began on Tuesday.
Thank you
Thursday, November 13, 2014 10:51 PM
Just to make sure, is it so that now you cannot even deploy any software or apps to existing machines? Nothing happends, right? Any errors when you try to run action for machine policy retrival? I usually monitor timestamps on log files to track down correct logs for actions.
Friday, November 14, 2014 2:45 PM
Correct, I can't deploy software or apps to existing machines. When I run Machine Policy Retrieval & Eval it states the selected cycle will run but no logs are updated in the c:\windows\ccm\logs directory.
I did notice that in ClientIDManagerStartup log it states "Client registration is pending. Sending confirmation request for GUID:The guid number.
Also in same log "Failed to open to WMI namespace '\.\root\ccmvdi' (8007045b)"
In smscliui.log "WARNING - Client is currently unassigned or an error occurred retrieving the assigned site. GetAssignedSite() returned : 0X0"
SMS Site code has not been changed
Current Assigned site: MySiteName
Perform Action: Request & Evaluate Machine Policy - {8EF4D77C-8A23-45c8-BEC3-630827704F51}. Message sent, id={0AA909F1-DE83-483D-A27A-941885BFA138}
Any other thoughts?
Thank you.
Friday, November 14, 2014 2:58 PM
Sounds like the firewall on the client or between the client is blocking communication. Is file and Print sharing enabled? Was a company wide change made on the corporate firewalls blocking the ports required for communication? Happens all the time specially with retard outsourced network companies like at my work.
Friday, November 14, 2014 3:16 PM
I don't think it is a firewall /proxy issue. On our clients the firewall is turned off. This is a large district so proxy and firewalls are setup going outside our network but within we have Access lists setup but not between our SCCM servers and clients. Is there any log files or other way I can rule this out?
Any thoughts on Active Directory problems that would cause this issue? I am wondering if I should look in that direction?
Thank you
Friday, November 14, 2014 3:26 PM
Use telnet, and from a problem client telnet on each port the SCCM server would use to talk to the dp or mp etc -
List of ports here http://technet.microsoft.com/en-us/library/hh427328.aspx
If you can telnet the server on these ports then you can tick this off the list as an issue.
I do also remember a SCCM 2007 secondary site having this issue once with pending registration due to a duplicate GUID, create a collection to search for duplicate ID's and delete them.
Check this out - http://blogs.technet.com/b/csloyan/archive/2010/04/27/system-center-configuration-manager-and-duplicate-guid-s.aspx
Friday, November 14, 2014 4:42 PM
Thank you for the Telnet information. I did telnet to ports 10123, 80 and 443 on all 3 Management Points and received a blinking cursor on each. I take it that means I was able to connect?
I checked out the duplicate guid link. Would imaging a brand new computer and still have the problem mean that is not the issue? It may solve other problems.
Friday, November 14, 2014 7:46 PM
In the SMS_Migration_Manager component status the component stops and starts every 10 minutes. I am not sure if that has anything to do with the current problems.
Friday, November 14, 2014 8:57 PM
"Also in same log "Failed to open to WMI namespace '\.\root\ccmvdi' (8007045b)""
This is meaningless as the system is not a VDI system.
"In smscliui.log "WARNING - Client is currently unassigned or an error occurred retrieving the assigned site. GetAssignedSite() returned : 0X0""
This is a successful client assignment.
How are you determining that no log are updating? By looking at their modified time? if so, that's not valid. You need to actually open the logs and look at them.
Start with policyagent.log, policyevaluator.log, ccmexec.log, clientidstartupmanager.log, locationservices.log, and clientlocation.log. Yes there are a lot of logs.
Also, you can't simply look at a single log line. Log files and messages in them are part of a big picture and taking them out of context is invalid. Also, many error messages are perfectly acceptable, non-fatal, and/or expected so don't just look for errors -- everything must be interpreted in context. Thus, when posting things from logs, post entire, relevant, and unedited snippets.
Jason | http://blog.configmgrftw.com | @jasonsandys
Friday, November 14, 2014 9:18 PM
Okay, I understand what you mean regarding the log files and needing to look at the big picture. I did think that the Modified time is when it was last changed. So, what is the best way of posting log files? Copying and pasting from CMtrace doesn't work well as you can see below.
Thank you
Requesting Machine policy assignments PolicyAgent_RequestAssignments 11/14/2014 3:03:45 PM 4700 (0x125C)
Requesting Machine policy from authority 'SMS:SC1' PolicyAgent_RequestAssignments 11/14/2014 3:03:45 PM 4700 (0x125C)
Raising event:
instance of CCM_PolicyAgent_AssignmentsRequested
{
AuthorityName = "SMS:SC1";
ClientID = "GUID:8C32E9B4-1AD6-431C-9D5D-9E61A67DA1FC";
DateTime = "20141114210345.364000+000";
ProcessID = 3532;
ResourceName = "TSC-211-E6510";
ResourceType = "Machine";
ThreadID = 4700;
};
PolicyAgent_RequestAssignments 11/14/2014 3:03:45 PM 4700 (0x125C)
Processing Machine assignments from 'SMS:SC1'. The new cookie is ''. PolicyAgent_ReplyAssignments 11/14/2014 3:03:45 PM 424 (0x01A8)
Raising event:
instance of CCM_PolicyAgent_AssignmentsReceived
{
AuthorityName = "SMS:SC1";
ClientID = "GUID:8C32E9B4-1AD6-431C-9D5D-9E61A67DA1FC";
DateTime = "20141114210345.520000+000";
ProcessID = 3532;
ReplyType = "Full";
ResourceName = "TSC-211-E6510";
ResourceType = "Machine";
ThreadID = 424;
};
PolicyAgent_ReplyAssignments 11/14/2014 3:03:45 PM 424 (0x01A8)
Already processed Machine assignments from 'SMS:SC1' with the cookie ''. PolicyAgent_ReplyAssignments 11/14/2014 3:03:45 PM 424 (0x01A8)
Friday, November 14, 2014 9:45 PM
[ STARTUP ] ClientIDManagerStartup 11/13/2014 10:48:16 AM 3548 (0x0DDC)
Machine: TSC-211-E6510 ClientIDManagerStartup 11/13/2014 10:48:16 AM 3548 (0x0DDC)
OS Version: 6.1 Service Pack 1 ClientIDManagerStartup 11/13/2014 10:48:16 AM 3548 (0x0DDC)
SCCM Client Version: 5.00.7958.1000 ClientIDManagerStartup 11/13/2014 10:48:16 AM 3548 (0x0DDC)
'RDV' Identity store does not support backup. ClientIDManagerStartup 11/13/2014 10:48:16 AM 3548 (0x0DDC)
CCM Identity is in sync with Identity stores ClientIDManagerStartup 11/13/2014 10:48:16 AM 3548 (0x0DDC)
'RDV' Identity store does not support backup. ClientIDManagerStartup 11/13/2014 10:48:16 AM 3548 (0x0DDC)
Client is set to use HTTPS when available. The current state is 192. ClientIDManagerStartup 11/13/2014 10:48:16 AM 3548 (0x0DDC)
[RegTask] - Executing registration task synchronously. ClientIDManagerStartup 11/13/2014 10:48:28 AM 2444 (0x098C)
[RegTask] - Client is already registered. Exiting. ClientIDManagerStartup 11/13/2014 10:48:28 AM 2444 (0x098C)
Read SMBIOS (encoded): 380058003400350052004D003100 ClientIDManagerStartup 11/13/2014 10:48:30 AM 2392 (0x0958)
Evaluated SMBIOS (encoded): 380058003400350052004D003100 ClientIDManagerStartup 11/13/2014 10:48:30 AM 2392 (0x0958)
No SMBIOS Changed ClientIDManagerStartup 11/13/2014 10:48:30 AM 2392 (0x0958)
SMBIOS unchanged ClientIDManagerStartup 11/13/2014 10:48:30 AM 2392 (0x0958)
SID unchanged ClientIDManagerStartup 11/13/2014 10:48:30 AM 2392 (0x0958)
HWID unchanged ClientIDManagerStartup 11/13/2014 10:48:31 AM 2392 (0x0958)
GetSystemEnclosureChassisInfo: IsFixed=TRUE, IsLaptop=TRUE ClientIDManagerStartup 11/13/2014 10:48:31 AM 2392 (0x0958)
Windows To Go requires a minimum operating system of Windows 8 ClientIDManagerStartup 11/13/2014 10:48:31 AM 2392 (0x0958)
Computed HardwareID=2:8319D0A44C8DA726CD195CABFF5157E87508969F
Win32_SystemEnclosure.SerialNumber=8X45RM1
Win32_SystemEnclosure.SMBIOSAssetTag=<empty>
Win32_BaseBoard.SerialNumber=/8X45RM1/CN1296106D016A/
Win32_BIOS.SerialNumber=8X45RM1
Win32_NetworkAdapterConfiguration.MACAddress=<Not used on laptop> ClientIDManagerStartup 11/13/2014 10:48:31 AM 2392 (0x0958)
Persisted hardware IDs in CCM_ClientIdentificationInformation=@:
HardwareID1=2:8319D0A44C8DA726CD195CABFF5157E87508969F
HardwareID2=7D958C01018600FC ClientIDManagerStartup 11/13/2014 10:48:31 AM 2392 (0x0958)
Friday, November 14, 2014 9:46 PM
Usually, uploading the logs in their entirety somewhere is best. Can't guarantee anyone will explicitly look at them though.
If this is "killing" you, then I'd recommend opening a CSS case as it's often difficult (or impossible) to do extensive troubleshooting in the forums.
Jason | http://blog.configmgrftw.com | @jasonsandys
Saturday, November 15, 2014 1:08 PM
Just an idea, what will happen if you ccmsetup /uninstall client, reboot and install the client manually? Are you then able to install anything?
In Resource Explorer, is hardware and software scan updating?
If you use Application Catalog, what happends if you try to install anything from there? If installation does not "swim" to Software Center from App Catalog, you will see errors behind user profile temp folder, somehere here - AppData\LocalLow\Microsoft\Silverlight\is
Sunday, November 16, 2014 7:07 PM
I can try the uninstall but wouldn't installing the client on a computer that never was on the domain or in SCCM be doing the same thing? I could not install anything in that situation. The computer is now showing up in SCCM but has not updated the heartbeat in 2 days.
Application Catalog is working. I am able to install an application from Application Catalog without a problem.
When I get back into work tomorrow I can check Resource Explorer.
Thank you
Monday, November 17, 2014 3:07 PM
Hardware and software scan are updating.
Monday, November 17, 2014 3:29 PM
The client communicates with the Management Point but does not receive the policy. But there are no errors on the client side in the log files that we can find.
Monday, November 17, 2014 10:03 PM
The SQL commands are deleting corrupt policies.
Why they get corrupted is anyone's guess. If it was know why, they would probably fix it :-) Although, it's most like something anomalous and is certainly not to be expected.
Note however that directly editing the DB without direction from CSS is unsupported. And, I hope you made a backup of your DB before you ran these.
Jason | http://blog.configmgrftw.com | @jasonsandys
Friday, April 17, 2015 5:04 PM
I have the exact same issue, and it has been beating me up for days now. I wanted to run these instructions on the SCCM DB, but unaware of how and where to run these instructions. Could you please give me more incite on where and how to do this?
Sakai T
Friday, April 17, 2015 6:29 PM
Does this help? Working with a SQL Database Admin might be helpful but the steps are not difficult once you get into SQL.
Nancy
On the Management point we saw the errors in:
C:\SMS_CCM\Logs\MP_Policy.log. This was on Management Point. On
Primary site it is located at C:\Program Files\SMS_CCM\Logs .<o:p></o:p>
<o:p></o:p>
This produced errors constantly of the nature "detected at
least one row in the result set from PolicyAssignment table which does not have
a Signature, rejecting all rows."
A Google search lead to many references to this error.
We followed the examples here running these two queries in SQL
against the SCCM database (the first to see if there were any bad records,
second to delete them):<o:p></o:p>
SELECT * FROM ResPolicyMap WHERE machineid = 0 and PADBID IN
(SELECT PADBID FROM PolicyAssignment WHERE BodyHash IS NULL)<o:p></o:p>
<o:p></o:p>
Delete FROM ResPolicyMap WHERE machineid = 0 and PADBID IN (SELECT
PADBID FROM PolicyAssignment WHERE BodyHash IS NULL)<o:p></o:p>
<o:p></o:p>
I'm not sure what exactly this is removing. It seems to be a
bad record linking policies to a computer. We weren't able to find much
detail on exactly what we were deleting, but it definitely resolved the
issues. Shortly afterwards clients were connecting and receiving policies
as expected.<o:p></o:p>
Friday, July 24, 2015 2:12 PM
Just to add my 2 cents: the problem discovery and solution worked for me.
The aforementioned SQL step to interrogate a problem, when run against my Primary Site Server Database revealed the exact same BAD records. What suddenly caused this I still don't know. The solution SQL brought CCM clients back to life after 10-15 mins. But I still seem to have a Software Updates issue.