Werun in a problem with the provisioning wizard. The environment is configured for a complete coexistence. For directory sync, mail flow and free busy we use the Quest CMN components. Only groups will be provisioned by MNE. (Our setup is tested in the test environment with one limit - we only use one domain controller.)We defined a small user group for a pilot phase in the productive environment. During the provision process 50% of the users in the collection run in errors. In the MNE log we see the error "the object couldn't be found on" "domain controller 2". In the MNE profile for section Active Directory we defined the "domain controller 1" with the full qualified host name.During our troubleshooting we took a look on the Exchange audit logs. There we saw that the Exchange cmdlet "Enable-MailUser" was processed. But the next cmdlet "Set-MailUser" not. There is only one difference the first command use the option of the domain controller the second not. What we have to set that all Exchange powershell cmdlets will be executed on one domain controller?
Trevor TaegderSenior Technical Support EngineerQuest | Support
In reply to Trevor Taegder:
In reply to jens.kleiner2:
Hello Jens, Thanks for the update and clarification. I now understand that it is the Provision User operation that you are experiencing issues with. In this case, based on the information you have provided, I would recommend setting the following parameter in the MNE Global Default Settings: [Exchange] ViewEntireForest=1
Determines whether the scope of MNE’s Data Migration Wizard will be expanded to the entire forest (valid for Exchange 2010 or later), rather than limited to just the local domain. For example: ViewEntireForest=1 tells the wizard to expand its scope to include the entire forest. The feature is off (0) by default. An expanded scope can be useful, for example, where MNE needs to run the set adserversettings-viewentireforest $true PowerShell cmdlet in a multi-domain forest, to enable other PowerShell commands for the same scope. (Note that the cmdlet must be run by MNE, not run independently.) Note: This setting will not be imported into existing migration configuration templates. Existing templates will need to be manually modified to be updated with this new parameter. You may want to try going through the MNE migration wizard without using a configuration template to test this new parameter.
This new parameter should allow any Global Catalog server to service the request made by MNE. If this new setting resolves the issue, but you are still interested in only targeting certain servers, then this may require a Service Request for further investigation:
Please let me know if you have any additional questions or need any additional clarification. Thanks, Trevor Taegder Senior Technical Support Engineer Quest | Support