Azure AD Connect - Device writeback config problem after swing migration

MaxUK 1 Reputation point

Hi, we have an old Azure AD Connect v. server (upgraded from DirSync) which we are trying to migrate to a new v. server using the swing method. I've been able to export the old config using the wizard and import it onto the new server fine. We've opted to use the same AD DS MSOL_**** and Azure AD Svc accounts, since they already have the necessary permissions in place. The new system is still is staging mode but it passes a full sync without any errors so both re-used connector accounts appear to be authing ok.

The issue Im having is configuring device writeback, something which is enabled on the old server and has not been brought across in the export. To enable on the new server Im using the GUI, Configure device options > Connect to Azure AD > select to Configure device writeback > upon selecting our Device writeback forest Im immediately shown the following error-


Looking in the log it's trying to retrieve the domain list from our forest (single domain) and then terminates.


The log doesnt specify the account its tying to use but Im assuming its the AD DS MSOL_**** account which already has the necessary rights to the 'Device Registration Configuration' and 'RegisteredDevices' containers in AD. However, to make sure its not a permissions issue for that account Ive also tried adding it into domain admins and enterprise admins and re-running the process with the same result. I've checked our AD DS and there is only one MSOL_**** account, so its not a duplicate account issue, plus we only have one domain.

Im toying with either rolling back the server and doing an AD Connect re-install and using new creds for MSOL, or perhaps running the 'Initialize-ADSyncDeviceWriteBack' powershell script against the new server in the hopes it will fix it. Problem is I didnt do the install for our old DirSync/ADConnect environment so Im trying to fix this without breaking anything in the process :-) Any advice welcome.

Many thanks.

Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
17,605 questions
0 comments No comments
{count} votes

3 answers

Sort by: Most helpful
  1. VipulSparsh-MSFT 16,176 Reputation points Microsoft Employee

    @MaxUK We do not recommend applying permission directly on MSol account. This should be taken care by the config wizard automatically as long as you enter a enterprise admin credential correctly. That has the permission to set every permission required for the MSOL account.

    Since you are already on the custom permission path, I would recommend you to verify the permissions as mentioned here :


    Hope this helps.


    Please remember to "Accept Answer" if any answer/reply helped, so that others in the community facing similar issues can easily find the solution.

    0 comments No comments

  2. MaxUK 1 Reputation point

    Hi, from what I understand the permissions were originally applied to the MSOL account using the PowerShell AD prep script 'Initialize-ADSyncDeviceWriteback', its not something we've configured manually. The existing server is using the MSOL account successfully for device writeback so permissions look to be fine. However, I think I'm going to roll back the new server, re-install Azure AD Connect and choose to create a new AD account rather than using the existing MSOL account. As you say, the correct permissions should be taken care of by the wizard.

    One question, can we run AD Connect using two different MSOL accounts over two servers in the same domain without causing any issues, for example-

    (existing prod server) ADConnectSvr1 - contoso\MSOLAccount1
    (new staging server) ADConnectSvr2 - contoso\MSOLAccount2

    Providing only one is live (non-staging) at any one time?


  3. MaxUK 1 Reputation point

    Figured it out. I was opening the Azure AD Connect tool using the local admin account on the server I was logged in with, from here I was assuming the tool was using the pre-existing MSOL account to do the forest/domain lookup which doesn't appear to be the case. Opening the tool instead using run-as and specifying the MSOL account I can configure device writeback without any issues.