Posts Tagged ‘registry editor’

Office 365 and Windows Azure Dirsync part 2: Filtering AD Groups…if you can!

This  is the second part of our Office 365 migration issues in hopes someone will find it helpful. When we were upgraded previously from the 2007 series of software to the 2010 series I had to make some changes to AD groups so they wouldn’t show up in Microsoft’s BPOS admin portal. Back then, they filtered your AD security groups in 3 different ways.

SecurityEnabledGroup objects are filtered if:

  • isCriticalSystemObject = TRUE
  • mail is present AND DisplayName isn’t present
  • Group has more than 15,000 immediate members

So I went about adding bogus email addresses to all of the groups that were showing up (roughly 50 or so.) No biggie, it worked….back then!

Now that I’ve upgraded to Windows Azure Dirsync w/ password sync, all of those groups that I painstakingly modified so they would be filtered out of BPOS now are imported automagically as “MailEnabled Security Groups” YAY! Needless to say, I didn’t want them to appear in the GAL so I had to take some steps to get them out of Office 365.

Now Office 365 filters SecurityEnabledGroups like so…

SecurityEnabledGroup objects are filtered if:

  • isCriticalSystemObject = TRUE

And that’s it!

Like I said previously, my big concern was removing them from the GAL so I went back through my AD Groups and removed all of the bogus email addresses and figured I was done. Not so fast! Upon the next sync, all of those groups were still present in the GAL but their email address’s had changed from to . Because the groups were still considered MailEnabled Security Groups, Office 365 reverts them back to your default domain email address and also changes the first half of the email address, the local part, to match the group name. Example: I gave the AD group “AccountingOnly” an email address of This way I knew I won’t have to worry about duplicate email addresses. When I removed the email address from AD, Office 365 filled it in with Bottom line, it was still showing up in the GAL and I wanted it gone. So, I had to do it via PowerShell like so.

Get-MsolGroup -ALL

This showed me all of the groups I had in Office 365. You can see the AD groups Dirsync uploaded as MailEnabledSecurity groups along with other groups that didn’t have an email address which appeared as just Security groups and also Distribution List groups. After scouring the MailEnabledSecurity groups to make sure they were all the ones I wanted gone, I simply did…

Get-MsolGroup -GroupType MailEnabledSecurity | Remove-MsolGroup -Force

This way I wasn’t being prompted to yes/no/suspend the operation for each one.

Once that was done, I changed the registry HKLM\SOFTWARE\Microsoft\MSOLCoExistence key “FullSyncNeeded” to 1 and issued a PS command of Start-OnlineCoexistenceSync which made it do another Dirsync right then. Surprisingly, the AD groups I just removed weren’t showing back up in Office 365 right away. It took another full Dirsync about 24+ hours later for all of the groups that were removed to show back up and this time they showed up as only Security groups not MailEnabled Security groups.

Also, if you’re like me, you’ll want to watch the Dirsync as it’s happening so open up your miisclient.exe which can be found in C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell directory.


Here’s a bunch of links for more info: (MS’s website which shows how Azure does its’ filtering. To me, this isn’t accurate any longer.) (Office 365 wiki link which shows how it filters now. Here you can clearly see they’ve changed filtering.) (Same Office 365 wiki but the main Directory Integration Services area.) (Main Dirsync content map page.) (KB page on “Mail-enabled groups that have an email address aren’t synchronized to Office 365” why couldn’t I have THAT problem!) (KB page on “Object that’s deleted from the on-premises Active Directory isn’t removed from Windows Azure AD after directory synchronization” talks about using PowerShell to remove them from Office 365 manually.) (Force Dirsync page via PowerShell.) (TechNet page on the Remove-MsolGroup PowerShell command.) ( Alian’s page which shows using pipes FTW!) (TechNet page on Get-MsolGroup PowerShell command. This command didn’t play nice for some reason when I used it.)


Windows APIPA (Automatic Private IP Address) and how to turn it off.

That damn 169.254.x.x IP address has caused me more headaches than I care to count. Here’s how I turn it off:

  1. Open up registry and go to HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.
  2. Add REG_DWORD of IPAutoconfigurationEnabled with a value of 0 (zero.)
  3. REBOOT!


Seriously, you can also apply that command down @ the adapter level too. Typically when I’ve got a problem w/ APIPA I’ve got a bigger issue but can’t see it yet. As an example, once I turned off APIPA on a laptop I could see that the OS just didn’t like the static IP address I was trying to configure it with. Once I changed the IP to something different, it worked just fine. GO FIGURE!


Here’s a couple of links:


Configuring Windows Time Service on a Domain Controller

I’m getting ready to migrate our AD servers to a virtual environment and one of the things that can get messed up is the AD servers’ time. Also, I’m joining some non Windows systems to the Windows domain which might encounter some time sync issues since they aren’t currently configured to use the domain’s NTP server (easy fix I know but I’m saving that for another post!)

Short story long, your AD server typically uses its’ CMOS time versus an external NTP server which is all fine and good so long as A) it’s a real hardware server not a virtualized one and B) No other servers in your infrastructure use other NTP servers (ie. Linux server ‘A’ isn’t using which will have a different time then your main AD server which is going off of it’s CMOS clock!)

So, I did some searching on the interwebs and stumbled upon a couple of useful links on how to modify your registry on your AD server so it:

A) Uses an external time source versus the CMOS time & date.

B) Has a number of servers to attempt time updates from (use spaces to delimit servers! and don’t forget to append “,0x1” at the end if you’re using a FQDN versus an IP Address!)

C)…I forget C!


Anyhow, here’s some links I wrangled up. (this one was most helpful!)




Windows Profile location in registry

We were having some issues at work w/ a profile migration when a user got a new laptop. During my “Googling” I happened to stumble upon how to change the users profile path via the registry which can be useful. The following registry location is still valid for Windows 7 which is good news.

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

One thing to keep in mind, you’ll need to assign ownership of the users profile w/ full permissions so things don’t get messed up upon reboots or when that user tries to login!

Original link:

SharePoint DCOM issue appearing in the System Event logs

At work, we’ve installed SharePoint servers a couple of times. A reoccurring issue, is a permissions issue that appears in the event logs as Event ID: 10016 or 10017 but doesn’t seem to effect SharePoint performance. We just recently installed SharePoint 2010 and I decided to chase these errors down since it’s annoying and fills up the log files. Seems the local domain account you create to run specific SharePoint services during the initial installation don’t have specific permissions for local activation.

The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID
to the user SOMEDOMAIN\SOMEUSERACCOUNT_SVC SID (S-1-5-21-BLAHBLAHBALHBLAH) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

So if you run off to the Component Services, find the offending CLSID object and right click->properties, hit the Security tab to allow this account to run this DCOM object it’s greyed out!

You’ve apparently got to find it in the registry first (should be “Computer\HKEY_CLASSES_ROOT\AppID\YOUR_CLASSID_HERE.”)

Once found, right click the key in the left pane and goto permissions. From there, you’ll want to take ownership of the registry object from the Trusted Installer which will allow you, the admin, to change its’ security permissions w/in the dcomcnfg application.

Now that’s done, open up the “DCOM Config” node of the local computer, find your AppID GUID, right click and select properties. Now select the Security tab and change your Launch & Activation Permissions for your domain account that’s generating your error.

As always, here’s some links to explain:

Return top
Icons made by Freepik from is licensed by CC BY 3.0