Wednesday, September 24, 2014

SCCM Client breaks after Site Signing Certificate Renewal

The ConfigMgr sites in where I work is running in Native Mode and this means that there will be certificates required for this. Recently, the site signing certificate for one of my sites is expiring and hence renewal is required. The renewal went smooth for the Document Signing. However, after the new site signing certificate was issued  and assigned to the site, all clients stopped getting policies.

We got this error on the clients's PolicyAgent.log:

Everything looked fine, all certificates got issued, all clients trusted the new certificate, but still the ConfigMgr agent would not work. However, uninstalling and re-installing the client solved the problem, but I can't possibly be doing this for over 10000 clients?

Technically speaking, renewing/replacing the site signing certificate issued from the same Certificate Authority should not cause this issue but... Usually the new certificate will be automatically downloaded when renewing the certificate
But for my case, this unfortunately did not happen.
I had to remove the old site signing certificate on the ConfigMgr client agents. This is stored in the registry, and can be worked out with a simple Group Policy Preferences fix.

For me, I used the vbs below with a combination of psexec to do the same

const HKEY_LOCAL_MACHINE = &H80000002

strComputer = "."

Set objRegistry = GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")

strKeyPath = "SOFTWARE\Microsoft\CCM\Security"
strValueName = "AllowedRootCAHashCode"
strValue = ""

objRegistry.SetStringValue HKEY_LOCAL_MACHINE, strKeyPath, strValueName, strValue

Basically what you need to do is to remove the client copy of the site server signing certificate if you change the root certification, locate the value named AllowedRootCAHashCode (type REG_SZ) and delete the associated value data that appears as a string of hexadecimal numbers.”
For x86-systems: HKLM\SOFTWARE\Microsoft\CCM\Security
For x64-systems: HKLM\SOFTWARE\Wow6432Node\Microsoft\CCM\Security

After this is done, you should restart the SMS Agent service and you should continue to monitor the PolicyAgent.log for the cleanup of machine policy and after which all should work. 

Tuesday, September 9, 2014

Managing Distribution Groups with hidden membership (when hideDLMembership is true)

There are situations in messaging environments where we want to manage distribution groups through Outlook client and want to ensure that its membership is visible to none but the distribution group owner. In legacy versions of Exchange it was quite straight forward, but Exchange 2010 presents little complexity that can be easily overcome by following a workaround.

Exchange Server 2010

With Exchange Server 2010, things change a little bit. Two aspects that need to be considered - RBAC & Address Book Service.

Let's go by an example.

We have mailbox-enabled users Jeff Oscar , Kevin Pascal, Laura Qunitero, Mike Ruth and Noel Swan on Exchange Server 2010.

We have a distribution group - Escalation Services, Noel Swan being the distribution group owner.

If the distribution group owner has mailbox on Exchange 2010, then even he can’t see the membership details, if hideDLMembership attribute is set to TRUE.

It’s something like below.

In addition, if the owner attempts to modify the membership of the distribution group through Outlook, following message pops up (even though the check box “Manager can update membership list” is selected).

So, for both issues the reason(s) there are couple of different workaround(s).

In Exchange 2010, with the introduction of RBAC, we have to perform some additional steps to ensure that the owner can modify the membership (even with the check box “Manager can update membership list” selected.).

The steps are documented in KB 982349 “Changes to the distribution list membership cannot be saved" error message when you try to remove members from an Exchange Server 2010 distribution list”

Solution 1: If you just want to enable the owner to modify the distribution group membership (with membership hidden for owner as well), then just run following commands - (i) to create a new role group, (ii) add Noels as member, (iii) and verify the membership.

[PS] C:\>New-RoleGroup DistributionGroupManagement -Roles "Distribution Groups"


[PS] C:\>Add-RoleGroupMember DistributionGroupManagement -Member Noels
[PS] C:\>Get-RoleGroupMember DistributionGroupManagement

Noel Swan

Now, the distribution group membership can be modified by the owner via Outlook client (obviously only additions, as s/he can't see the membership).

Solution 2: If you want to enable the owner (a) to view distribution group membership (b) to modify distribution group membership through Outlook client, then just hard code the Outlook client to talk to closest GC, by following the KB 319206 “How to configure Outlook to a specific global catalog server or to the closest global catalog server”.

HKEY_CURRENT_USER\Software\Microsoft\Exchange\Exchange Provider
On the Edit menu, click Add Value, and then add the following registry value:

Value name: DS Server
Data type: REG_SZ (string)
Value data: FQDN of the global catalog server

And, one more interesting aspect that I would like to mention.

If, following conditions are true..
The check box for "Manager can update membership list" in Active Directory Users and Computers is not selected on the Distribution Group property.
Distribution Group owner has been provided appropriate RoleGroupMembership [ RBAC "DistributionGroups"].

[ These will be the most likely situations when the distribution group and distribution group owner are created via Exchange Management Console in Exchange Server 2010 environments.]

Then, the result as observed by Distribution Group owner via Outlook client will be as follows.

Without "DS Server" registry key --

a. Will not be able to see membership in Outlook client.

b. But will be able to add members to the distribution group via Outlook client

With the "DS Server" registry key --

a. Will be able to see membership in Outlook client.

b. But will not be able to remove/add members to the distribution group via Outlook client.

So, the solution -- ensure that the check box "Manager can update membership list" is selected, if you want the distribution group owner to see & modify the membership.

Thursday, September 4, 2014

Event ID 10 AD MP DC Local Discovery : Active Directory Helper Objects Installation unsuccessful. MSI was not found at the specified location

Encountered a situation where the SCOM agent was installed on a Windows 2008 R2 Domain Controller but was unable to locate it under the DC state in the AD MP folder.
I found this EventID in the OpsMgr event log on all DCs reporting to a SCOM R2 Gateway Server.

As it turned out, the AD Helper Object (OOMADs.msi) was missing on the DC. The SCOM R2 Gateway Server did not have this file in place so it never arrived on the DC to be monitored by SCOM.

To remediate this issue and stop it from re-occuring ever again. 
This is what was dome:

Corrected the SCOM R2 Gateway Server
Copied the file OOMADs.msi from the installation media of SCOM R2 (~\HelperObjects\<ARCHITECTURE>) to the installation folder of the SCOM R2 Gateway Server (~:\Program Files\System Center Operations Manager 2007\HelperObjects).

Corrected the Agent Staging Folder
Copied the file OOMADs.msi from the installation media of SCOM R2 (~\HelperObjects\<ARCHITECTURE>) to the Agent Staging folder of the SCOM R2 Gateway Server (~:\Program Files\System Center Operations Manager 2007\AgentManagement\<ARCHITECTURE>). 

Copied the AD Helper Object to the Agent
Copied the file OOMADs.msi from the installation media of SCOM R2 (~\HelperObjects\<ARCHITECTURE>) to the installation folder of the SCOM R2 Agent (~:\Program Files\System Center Operations Manager 2007\HelperObjects).

Corrected the Agent
Stopped the HealthService, removed the cache file (~:\Program Files\System Center Operations Manager 2007\Health Service State), installed the AD Helper Object manually and restarted the HealthService. Checked the OpsMgr event log for EventID 10. It did not return. Closed the Alerts (based on a Rule) in the SCOM Console per fixed DC and the Alerts did not come back.

Now all is well and the DC are monitored in a proper manner.