07-26-2016 01:14 AM
07-26-2016 01:14 AM
Good morning. We have a client that implemented ADConnect using Alternate Login ID because he was unwilling to change. Now after he recognized the drawbacks he changed the UPN. Now my question is can I easily change ADConnect and ADFS back to use the standard UPN mapping or do I have to completely remove the existing connection. If so, what will this do to the 120 migrated mailboxes, etc.?
07-26-2016 06:20 AM
If I understand correctly then the required settings for UPN are set as well (@contoso.com) and you should be able to disable the alternate ID by running the following command:
Set-AdfsClaimsProviderTrust -Target Identifier "AD AUTHORITY" -AlternateLoginID $NULL -LookupForests $NULL
No additional settings are needed for ADConnect when disabling the Alternate ID.
11-28-2016 08:41 AM
sorry to bring this threat up again. I am not only talking about the ADFS part but mainly the Azure AD Connect setting which can only be specified during initial installation as it seems. Any idea?
11-28-2016 11:06 PM
AD Connect uses a couple of ways to mactch users from AD with AAD, even when reinstalling the product it tries to match users again with users that already have been synced previously. This is usually done with the immutable ID from AD which is by default the ObjectGUID as SourceAnchor from AD. If you need to change the setup then I would recommend to uninstall AD Connect competely and then reinstall it using the needed settings. Be sure to first check the current configuration first and verify that the ObjectGUID is indeed the SourceAnchor.
If that is the case then you can proceed and uninstall AD Connect, then reinstall it again and select the needed Login ID settings.
11-28-2016 11:10 PM
Good morning, thanks for the reply, I have just received same information from MS, no way tro change afterwards, plainly need to reinstall or use a second AD Connect machine and use staging to change. Will keep u posted ones completed, will need to evaluate first as we are in production already :(
11-28-2016 11:16 PM
If you are in production and want to make sure that you are not running into issues then I suggest that you first check the current source anchor as I mentioned in my earlier post. If that is ObjectGUID and you don't want to have any downtime then you could spin up a VM either on Azure or locally and install AD Connect on it. Run the installer (make sure to also use the ObjectgUID as a source anchor) and be sure not to run a sync at the end. When users are not connected (for example tonight) then run a sync from the newly installed machine. Check the results. If all is fine then you can either choose to keep using this installation or rerun the same process on the production AD Connect machine. If all is not fine then stop the newly installed machine and run a full sync from your production AD Connect machine to restore the current setup.
11-28-2016 11:18 PM
source anchor will not change and will still be the objectguid - I condier using a staging adconnect server to test those changes and then switch over to this one if synchronisation is fine