Posts Tagged ‘Microsoft’

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.)

 

Office 365 and Windows Azure Dirsync part 1: Filtering AD User Objects

At work we use Microsoft’s Cloud offering called Office 365. We were one of the early adopters and signed on with BPOS back in 2010 ish time frame. Even back then, they had an Active Directory Sync tool and each time we were upgraded from 2007 toolset -> 2010 toolset to now 2013 toolset we had to tweak our AD Sync tool to keep our GAL clean of disabled or service accounts. This wasn’t an easy feat initially but I was pointed in the right direction by MessageOps.com and have since managed to reapply the same filtering technique for Office 365’s new Dirsync tool called Windows Azure Directory Sync. We were pressed into upgrading our dirsync tool because they started blocking as of Oct. 1st 2013 the previous tool due to it being A) 32 bit and B) Microsoft Identity Lifecycle Manager 2007 fp1 at its core. They’ve now got us using Forefront Identity Manager 2010 R2 which has password synchronization! Yay! I managed to hold off implementing ADFS just long enough for Microsoft to find an easier way for our users to start using Same Sign-On.

So, how do you configure the new Dirsync tool so it won’t send every single AD User Object into Office 365? By filtering your Active Directory Connector Management Agent using miisclient.exe.

1) Open up your miisclient.exe and go to the Management Agents option.

2) Next, right-click your Active Directory Connector listed under Management Agents and select properties.

3) Now select Configure Connector Filter and scroll down on the right-hand side until you find User. Here the user filter is declared thankfully so we can tweak it the way we want (unfortunately group is a Rules Extension which has changed and will be addressed in Part 2 of the write up.)

4) While user is selected, and you can see the 15 different filters for users, select “New…” across the bottom and create a filter appropriate for your organization. For ours, we selected attribute = ipPhone, Operator = Does not equal and Value = 1. This way, it will only synchronize AD User Objects that have their ipPhone = 1 on their AD properties page (this way I don’t have to use ADSI Edit for each user w/ in our company.)

All in all, pretty straight forward. Now fixing our groups that got sucked up into Office 365 are another matter!

Here’s a couple of links I found useful regarding setting up this new filter inside Forefront Identity Manager 2010:

http://www.messageops.com/documentation/office-365-documentation/office-365-admin-training (MessageOps website. Scroll to the bottom for Dirsync.)

http://social.technet.microsoft.com/wiki/contents/articles/18096.dirsyncwindows-azure-ad-password-sync-frequently-asked-questions.aspx (Dirsync FAQ.)

http://technet.microsoft.com/en-us/library/jj710171.aspx (MS’s steps for configuring filtering on Dirsync. I chose User Attribute Based filtering since we’re a small company and it was easier.)

http://technet.microsoft.com/en-us/library/hh967629.aspx (Top level of Dirsync. useful info if this is your first time using AD sync w/ Office 365.)

http://technet.microsoft.com/en-us/library/dn246918.aspx (Windows Azure Dirsync’s password sync feature. We definitely love it.)

http://blogs.technet.com/b/educloud/archive/2013/06/03/new-azure-active-directory-sync-tool-with-password-sync-is-now-available.aspx (Announcement that Azure sync now does passwords!)

http://support.microsoft.com/kb/2855271 (Password sync troubleshooting guide.)

http://community.office365.com/en-us/wikis/manage/2567.aspx?WT.mc_id=eml_CXM__Sept+2013+Admin+Newsletter (MS’s justification for making us bump up to 64 bit.)

http://blog.baeke.info/2012/06/24/office-365-identity-management-with-dirsync-without-exchange-server-on-premises/ (general Dirsync blog)

USN Rollback on a Domain Controller

This one bit me in the behind a while back. Essentially, the AD server was restored from a snapshot but had USN numbers that were younger than another servers’ USN numbers which was trying to connect to the AD server. This put the AD server into “disabled” mode so it wasn’t being used for AD stuff. The only way I could permanently fix my USN rollback issue was by keeping the other server off and restoring it to a previous snapshot as well. Long story short, this sucked to fix.

 

Couple of links:

http://exchangeserverpro.com/recovering-a-single-domain-controller-from-a-usn-rollback

http://social.technet.microsoft.com/Forums/zh/winserverDS/thread/8d287ba9-fff8-4a93-998a-86e64e4b85f8

 

Installing SharePoint 2010 ENT and got error on installing Sync Framework 1.0

Just finished installing a fresh server with SharePoint 2010 Enterprise so an employee could look at the business intelligence dashboard stuff. While doing the install, I received an error about the MS Sync Framework 1.0 failing which caused the whole thing to screech to a halt. It would appear that I installed the .NET 4.0 stuff via Windows Updates which caused the .NET 1.0 Sync Framework to puke on me. Thankfully, MS had a hotfix for that which resolved my issue. You can see the Microsoft Sync Framework Runtime v1.0 listed on SharePoint 2010’s HW & SW requirements list.

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

After I manually installed the hotfix, the “Install software prerequisites” continued and I had the SharePoint 2010 site up and running before lunch!

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