Posts Tagged ‘HKLM’

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 SomeBogusGroup@example.com to SomeBogus@EXAMPLE.onmicrosoft.com . 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 accountonlygroup@example.com. 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 accountonly@EXAMPLE.onmicrosoft.com. 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.

Connect-MsolService
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:

http://support.microsoft.com/kb/2256198#How (MS’s website which shows how Azure does its’ filtering. To me, this isn’t accurate any longer.)

http://community.office365.com/en-us/wikis/sso/filter-support-in-the-microsoft-online-services-directory-synchronization-tool.aspx (Office 365 wiki link which shows how it filters now. Here you can clearly see they’ve changed filtering.)

http://community.office365.com/en-us/wikis/sso/default.aspx (Same Office 365 wiki but the main Directory Integration Services area.)

http://community.office365.com/en-us/wikis/sso/office-365-dirsync-content-map.aspx (Main Dirsync content map page.)

http://support.microsoft.com/kb/2508722 (KB page on “Mail-enabled groups that have an email address aren’t synchronized to Office 365” why couldn’t I have THAT problem!)

http://support.microsoft.com/kb/2709902 (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.)

http://technet.microsoft.com/en-us/library/jj151771.aspx#BKMK_SynchronizeDirectories (Force Dirsync page via PowerShell.)

http://technet.microsoft.com/en-US/library/dn194137.aspx (TechNet page on the Remove-MsolGroup PowerShell command.)

http://www.amdocorp.com/Pages/Removedeletedmailbox.aspx ( Alian’s page which shows using pipes FTW!)

http://technet.microsoft.com/en-us/library/dn194130.aspx (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:

http://support.microsoft.com/kb/244268/en-us

http://support.microsoft.com/kb/220874

http://support.microsoft.com/kb/307287

http://en.wikipedia.org/wiki/APIPA

http://superuser.com/questions/482520/why-am-i-getting-a-169-ip-address-at-startup

http://www.dummies.com/how-to/content/automatic-private-ip-addressing-apipa.html

http://lyngtinh.blogspot.com/2011/12/how-to-disable-autoconfiguration-ipv4.html

 

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:
http://msmvps.com/blogs/clustering/archive/2004/10/06/15096.aspx

Return top
 
Icons made by Freepik from www.flaticon.com is licensed by CC BY 3.0