Archive | July 2015

Unable to change initial Pilot/Test Group Azure AD Connect

Recently, while installing and configuring the new Azure AD Connect Tool for a customer, we configured group filtering for an initial Pilot Group of users.  After initial testing, the decision was made to expand this to another, more permanent group of users.  While it appeared we could re-run the setup wizard, which gave us the option to change the pilot group, it would never actually update the database to reflect the changes.

21-07-2015 10-29-40 a-m- 21-07-2015 10-30-25 a-m-

Thankfully, with the assistance of a colleague we were able to track down the table/field within the LocalDB and change the entry for the group.

21-07-2015 10-13-28 a-m-

NOTE: Please proceed with this at your own risk – I’m quite certain this wouldn’t be a supported method from Microsoft, however it worked for us until this bug is resolved in the Azure AD Connect tool.

First disable the Schedule Task and Azure AD Sync Service.

21-07-2015 10-14-52 a-m- 21-07-2015 10-15-49 a-m-

Using SQL Management Studio, connect to the LocalDB Instance with a logged on user/run-as user who is a member of the local ADSyncAdmins group.

21-07-2015 10-16-11 a-m-

The database instance information can be found here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server Local DB\Shared Instances\ADSync
21-07-2015 10-18-02 a-m-
From there, right click on the Table “dbo.mms_management_agent” and select “Edit Top 200 Rows”. The data is stored under the second row column “private_configuration_xml”.

21-07-2015 10-18-29 a-m-

Expand out the field to find the parameter <parameter name=”Connector.GroupFilteringGroupDn” type=”string” use=”global” dataType=”String”>CN=MSONLINEUSERS,OU=YOURGROUPOU,DC=YOURDOMAIN,DC=YOURDOMAINEXTENSION</parameter>
21-07-2015 10-25-06 a-m-
From here, I’d recommend taking a copy of that entire field/XML first in case you need to reference it pre-changes.

Simply replace MSONLINEUSERS with your group name and the remaining AD path for your specific group.

Restart the Azure AD Connect Service and re-enable/re-run the sync to have the new group sync.  You may need to run a full sync for all of the changes to appear.  This can be done by running the following command: C:\Program Files\Microsoft Azure AD Sync\Bin\DirectorySyncClientCmd.exe initial

Hope it helps!

ADFS/Office 365 SSO 80041034 Error

Recently after configuring Active Directory Federated Services for a customer for Azure AD Premium/Office 365, we received the following error while testing user login to
Sorry, but we’re having trouble signing you in.
Please try again in a few minutes.  If this doesn’t work, you might want to contact your admin and report the following error: 80041034
15-07-2015 10-56-30 a-m-
The obligatory Google search showed potential fixes relating to cached ADFS entries for users post-UPN changes (which we had done as a prereq. for MS Online Services).  We ran the LsaLookupCacheMaxSize fix here:  This did not resolve the issue.  The other suggestions found online were to convert the MSOL Domain from Federated to Standard and back again.  While I’m sure this would have helped, the easier option was to remove the Relying Party trust from ADFS:
15-07-2015 11-42-41 a-m-
Followed by running the Update-MsolFederatioDomain -DomainName
15-07-2015 11-42-23 a-m-
This then placed an updated/correct copy of the Relying Party trust into our ADFS server which resolved the issues!