This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

User Provision process runs in error - the Exchange cmdlets (Enable-MailUser, Set-MailUser) will be send to different domain controllers. Could I set a defined domain controller for all Exchange activities?

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?

Parents
  • 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:

    https://support.quest.com/create-service-request

    Please let me know if you have any additional questions or need any additional clarification.

    Thanks,

    Trevor Taegder
    Senior Technical Support Engineer
    Quest | Support

Reply
  • 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:

    https://support.quest.com/create-service-request

    Please let me know if you have any additional questions or need any additional clarification.

    Thanks,

    Trevor Taegder
    Senior Technical Support Engineer
    Quest | Support

Children
No Data