This FAQ covers commonly asked questions about DeploymentPro issues such as caching, autodiscover, cutover, resetting passwords in Microsoft 365, migrating users in batches, and configuring or resetting configuration. It is intended to be used in conjunction with the DeploymentPro Guide.

A Few Quick Answers

• The DeploymentPro Agent does not require Outlook to be running.
• If Outlook is running, the user will be prompted to close Outlook so the profile reconfiguration can be completed.
• Using the workstation through the configuration process will not cause any issues.
• DeploymentPro can configure Outlook for users on terminal servers.
• DeploymentPro does not set email signatures.
• DeploymentPro is a lightweight agent that quickly configures Microsoft Outlook to send and receive e-mail from Microsoft 365, as well as copies over the users' current Outlook settings.
• DeploymentPro is not supported by GCC High Microsoft 365 tenants.

Scheduling

The time zone in your MSPComplete portal will reflect the local time zone of the machine from which the user is logging on. Any scheduled times will then be converted to UTC, which will be used to determine the correct local time for profile cutover for each end user.

For example, if you are logged in to your MSPComplete portal from a computer that is in the Pacific Standard Time (PST) zone, the profile cutover time will be shown in PST. Therefore, if you set the time to be 11 pm, that will be 11 pm PST. If your end users are in the Eastern Standard Time (EST) time zone, their profiles will be switched over at 2 am EST.

Change Scheduled Launch

Simply schedule it as you did before with the UI or PowerShell, and change it to the desired time and date. It will update that information on the back-end servers, and then download the update to the client within 15 minutes. 

Multiple Domains & Machines

Configuring in Multiple Domains

1. Create a customer in MSPComplete. 
2. Create the Source and Destination endpoints in MigrationWiz
3. Deploy Device Management Agent (DMA) to users.
   

   Important

   A customer can have multiple domains, so DMA can be deployed to users in each domain.
4. Launch DeploymentPro, and configure the customer DeploymentPro module.
   

   Important

   If multiple domains are in the customer environment and DMA was deployed to them, these will appear under the user list within your DeploymentPro module dashboard.
5. If this is the first time setting up DeploymentPro, click All Products and select DeploymentPro.
6. Click on the Customer you are configuring the deployment for. This will automatically open the Module Configuration page. If you have previously configured the DMA, then in your MSPComplete DeploymentPro module dashboard, click Settings in the top right.
7. In the Module Configuration/Domain Name field, enter the domain name, after the "@" sign.
8. Click Auto-populate.
9. Set Client Interface Configurations for the domain. You can set different logos and instructional text for each domain.
10. Click Save and Continue to return to the DeploymentPro module dashboard.
11. In the Search field, enter the new domain name. The dashboard will update to display only the names containing the selected domain name.
12. To activate the DeploymentPro module for users, refer to the DeploymentPro Guide.
13. To schedule the profile cutover date, refer to the DeploymentPro Guide.

Alternatively, you can use PowerShell to run these steps. For instructions, see the Use PowerShell to run the DeploymentPro module.

1. To return to the previous list of users, in the Search field, enter the domain name.
2. If the user list that returns from Search is empty, click the back button to return to the previous list of users.

Multiple Machines

 If the BitTitan Device Management Agent (DMA) has been deployed to every computer via a Group Policy Object, your MSPComplete customer portal will report each user. If you click on an individual user, you can see which devices have DMA installed on them.

If the DeploymentPro Schedule Cutover has been scheduled to run for a user and that user logs in to each device (after the Schedule Cutover date), they will be prompted to reconfigure their Outlook profile. The user will then decide whether or not to reconfigure their Outlook profile on each device.

Limiting Caching after Cutover

If you want to manipulate the amount of data that is downloaded to users' OST files, this can be set via Group Policy. 

You can use the Group Policy templates, which are available from the Microsoft Web site (see https://technet.microsoft.com/en-us/library/Cc178992.aspx for more information). The Group Policy template files are Outlk15.admx and Outlk15.adml. If you use Group Policy to manage this setting, the following registry data is utilized by Outlook.

Registry Key: HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\Outlook\Cached Mode

DWORD: SyncWindowSetting

Value: an integer value (Decimal) specifying the number of months (use only the following values)

0  = All (entire mailbox)
1  = one month of email items
3  = three months of email items
6  = six months of email items
12 = twelve months of email items
24 = twenty-four months of email items

If you are concerned with bandwidth when DeploymentPro is being used to configure Outlook profiles at cutover (which in turn will also download the OST file to each user's local drive), you could set this to either 1 or 3 months before your MX record cutover, and then increase this number in the subsequent weeks, post-migration, so that users will then have a larger portion of their mailbox downloaded and synched with the local OST file.

For Outlook 2016+ clients, there is a newer ADMX for Office 2016. This ADMX has newer settings, which means you can limit the cache to days, not just weeks/months. https://www.microsoft.com/en-us/download/details.aspx?id=49030

GPO Location: Microsoft Outlook 2016\Account Settings\Exchange\Cached Exchange Mode
Reg Value HKCU\software\policies\microsoft\office\16.0\outlook\cached mode!syncwindowsetting
Description: Select Cached Exchange Mode sync settings for profiles
Default: One year
Possible Values: [0, Three days] [0, One week] [0, Two weeks] [1, One month] [3, Three months] [6, Six months] [12, One year] [24, Two years] [36, Three years] [60, Five years] [0, All]

DeploymentPro User Interactions

When a user logs on to their machine, after the DeploymentPro Schedule Cutover Scheduled Date/Time has occurred, they will see a Desktop pop-up appear, like the screenshot below. The BitTitan logo and supporting text can be replaced with your own company logo and branded text. This can be set when configuring your customer DeploymentPro module, as detailed in the DeploymentPro Guide.

Once the user clicks on Next, the subsequent page will prompt them to enter their credentials.

Users need to add their Destination email password in the Password field and click on the Next button.

If the user is in a Tenant to Tenant with Coexistence migration, they will get this Create Password screen instead of the Provide Outlook Credentials screen.

Once the credentials have been validated, users will see the following page:

Users can now begin their Outlook profile reconfiguration by clicking on the Next button.

• If users do not have Outlook, Skype for Business, or Lync open the profile configuration will proceed.
• If users currently do have Outlook, Skype for Business, or Lync open, they will see the following page:
   

They should then click on the Close the Application(s) button.

Outlook will be closed for them, and the profile configuration will proceed.

The configuration could take several minutes. During this time, a new profile is being created based on the previous default profile.

The following actions are occurring during this timeframe:

• Non-password-protected PST files that were attached to the previous default profile will be reattached to the new profile.
• Autocompletes (cached addresses) will be imported over to the new profile.

Once the new profile has been created, the following page pop-up will be displayed:

The user can now click on the Finish button and begin using Outlook again.

The user's new profile will be configured to access the new Destination email system.

Changing Username

1. Log in to MSPComplete, and click All Customers.
2. Select a customer.
3. Click Users.
4. Hover over a User and you will see an ellipsis (...) on the far right. Click on it.
5. Select Edit and make your change. The change will now be reflected on your DeploymentPro page.

DeploymentPro Profiles

When DeploymentPro creates a new profile, it will follow this format:

BT-xxxxxxxxxxusername@domainname.com

For example, if the SMTP email address for a user equals BonnieK@MOD52453.onmicrosoft.com, then the new profile will be created with the following name:

BT-xxxxxxxxxxBonnieK@MOD52453.onmicrosoft.com

• xxxxxxxxxx will be replaced by a randomly generated unique 10-digit number.

This profile will be set to be the default Outlook profile. From a Windows client, these profile settings can be reviewed by accessing Control Panel/Mail. The previous profile will remain with the same name, and not be deleted. However, it will no longer be the default profile.

If creating a profile from an existing user, the new profile will import the signature from the previous profile, reattach any PST files that were attached to the previous profile, and import cached addresses.

The .OST file will be created and downloaded upon first use. 

Migrating Users in Batches

If you want to migrate users in batches, and then run DeploymentPro against those batches, you can select the individual users within the DeploymentPro module, after the customer DeploymentPro module has been initially configured.

Once users have been selected, you can set the scheduled time/date for the profile reconfiguration to match the time/date that these users will be using their new Destination email system.

Testing DeploymentPro with a small batch of users

The steps to deploy DMA via Group Policy Object (GPO) can be found in our DMA Installation guide. If you want to deploy DMA via GPO to only a subset of users, you can set a security filter group and add only that subset of users to the group. You can then apply the GPO to that security group.

Alternatively, you can deploy DMA via email and only send the email to the test users. 

You do not have to migrate the mailboxes in MigrationWiz in order for DeploymentPro to work, or to start a DeploymentPro project. To migrate these mailboxes through MigrationWiz, it is necessary to purchase User Migration Bundle licenses or mailbox migration licenses. If these mailboxes have already been migrated to Microsoft 365 in another MigrationWiz project, this could cause duplicates at the Destination because the Destination has already been populated with mail items from the other migration project.

Once DMA is deployed, only the users in that group are populated in your DeploymentPro customer portal. You can then select all users, or individual users, for the Proof Of Concept. If running a full Proof of Concept, which includes migrating the mailboxes through MigrationWiz and reconfiguring the Outlook profiles through DeploymentPro, be sure to reset everything before beginning your actual Full Migration project. To reset:

1. Delete all items in the Destination mailbox and reset items in MigrationWiz:
   1. Sign in to MigrationWiz.
   2. Click Go to My Projects.
   3. Click the name of the project in the list.
   4. Select the items you want to reset statistics for.
   5. Click the Reset Items button in the top navigation bar.
   6. Do NOT select "Reset errors only for the selected items." if you need to reset the migration statistics completely. If BitTitan support recommends resetting the item statistics, do not check this box unless support specifically recommends it. 
   7. Click Reset Items.​
   8. You will know the reset was successful when all migration data for the selected users will be blank or returned to '0'.
2. Set the Outlook profile to use the previous Outlook profile. Refer to https://technet.microsoft.com/en-us/magazine/ff963534.aspx for more information.

For any subsequent tests, repeat the steps.

Once your tests are complete, you can connect Outlook back to your Source environment with the following steps:

1. Open the following JSON file with Notepad and change "IsCompleted" from true to false: %localappdata%\BitTitan\DeviceManagementAgent\module\OutlookConfigurator\config.json
2. Open the Registry HKEY_CURRENT_USER\SOFTWARE\BitTitan\DeploymentProIsComplete and change the key to "0".
3. Open the Registry HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\XX\Outlook\AutoDiscover (where XX equals 14.0, 15.0, or 16.0) and remove all but "(Default)".  
4. Close Outlook and go to Control Panel>Mail>ShowProfiles. Then, remove the Btprofile and set the original profile as the default.
5. Opening Outlook now will connect back to your source environment.

When you are ready to run DeploymentPro for all users, deploy DMA via GPO to the users, and then follow the steps in the DeploymentPro guide.

ADFS

Typically, ADFS and AADConnect (or DirSync) are set up to support a hybrid environment. In such cases, you could perform a mailbox move using Mailbox Replication Services (MRS). As part of this process, the existing profile would be reconfigured automatically to point to the new Destination location, so DeploymentPro would not be required anyway.

Reverting DeploymentPro Configuration in Outlook

These steps enable you to revert an Outlook mail profile to the state it was in before the DeploymentPro configuration. This can be useful if you tested DeploymentPro to see the User experience and you need to connect Outlook back to the Source server so the test subject can continue receiving mail.

Follow these steps to revert a User’s Outlook mail profile to the state it was in before the DeploymentPro configuration:

1. Sign in to Windows as the User for which DeploymentPro configured the Outlook mail profile.
2. Close Outlook if it’s running.
3. Using Notepad, open the JSON file located in this directory:
   
   %localappdata%\BitTitan\DeviceManagementAgent\module\OutlookConfigurator\config.json
4. Change the value IsCompleted:true to IsCompleted:false.
5. Save and close the JSON file.
6. Open Registry Editor and navigate to this registry branch:
   
   HKEY_CURRENT_USER\Software\BitTitan\
7. Open the DeploymentProIsComplete registry key, change its value to 0 (zero), and then click OK.
8. Depending on the version of Microsoft Office installed on the computer, navigate to the appropriate registry branch:
   
   Microsoft Outlook 2010 Microsoft Outlook 2013 Microsoft Outlook 2016

   HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\14\Outlook\AutoDiscover

   HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15\Outlook\AutoDiscover

   HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16\Outlook\AutoDiscover
9. Remove all the registry keys in the directory, except for the (Default) registry key.
10. Close Registry Editor.
11. Open the Control Panel, and click Mail.
12. Click Show Profiles.
13. In the list of mail profiles, select Btprofile, and then click Remove.
    
    
14. Select Always use this profile, and then select the original mail profile, typically labeled as Outlook, in the drop-down menu.
15. Click OK.
16. Open Outlook. The original profile is used, and is connected to the original Source mail server, and not the Destination server.

Using DeploymentPro to Reset Temporary or Expired Passwords in Microsoft 365

When a DeploymentPro project is configured in MSPComplete, you can specify how expired or temporary user passwords for Microsoft 365 are handled when the DeploymentPro Outlook configurator wizard runs on end-user computers.

These options are available when configuring the DeploymentPro project:

• Enable users with temporary or expired passwords to set their own passwords if your customer uses Microsoft 365 to manage user accounts and password policies. With this setting selected, the DeploymentPro wizard running on the customer’s computers will prompt the user to enter a new password when their password is expired or set to temporary. DeploymentPro automatically updates Microsoft 365 with the password that users enter. It is important that users know their current expired or temporary password.
• Do not allow users to set their own passwords if your customer manages their user accounts and password policies using ADFS. With this option selected, all user password resets are managed by the company’s IT department.

Read the DeploymentPro Guide for more information about configuring and running a DeploymentPro project.

Configure DeploymentPro with a Mismatched SMTP & UPN

If users have Active Directory, the UPN is what users log on to their computers with. The SMTP address is their actual email address where they receive mail. Normally these are the same, but not always.

PowerShell output shows they are different. 

Get-Mailbox ipace | fl UserPrincipalName,PrimarySmtpAddress
UserPrincipalName  : ipace@BitTitanLab.info
PrimarySmtpAddress : ipace@BitTitanLab.com

When Irma Pace logs on to a computer with ipace@BitTitanLab.info and runs Outlook for the first time, it detects that her SMTP address is ipace@BitTitanLab.com and configures Outlook for that email address.

ipace@BitTitanLab.com is what all our Discovery processes will return to MSPComplete. If the UPN is BitTitanLab.com in Microsoft 365, no changes are necessary.

If the UPN is BitTitanLab.info and the SMTP address is BitTitanLab.com, then an adjustment will need to be made before you Schedule Cutover on the DeploymentPro page.

1. Click Settings at the top right of the page.
2. Change the Domain Name to the domain that is the UPN domain in Microsoft 365, and click Save and continue in the top right of the page.
3. Put a checkmark in the box to the left of the mailbox you are working on.
4. Click Run Module and verify that the alias and the domain is the UPN of the mailbox.
5. Verify that you have a future date and time, click Apply, then click Run Module.

The correct information is sent to our back end servers and will be pulled down to the client at the next heartbeat. The change you made is not reflected in the UI at this time, however; it is a future design feature.

Get-Mailbox ipace | fl UserPrincipalName,PrimarySmtpAddress
UserPrincipalName  : ipace@BitTitanLab.info
PrimarySmtpAddress : ipace@BitTitanLab.info Set-Mailbox -identity ipace -EmailAddress  SMTP:ipace@BitTitanLab.com,ipace@BitTitanLab.info

Result:

Get-Mailbox ipace | fl UserPrincipalName,PrimarySmtpAddress
UserPrincipalName  : ipace@BitTitanLab.info
PrimarySmtpAddress : ipace@BitTitanLab.com

DeploymentPro will configure your mailbox to the SMTP address found in Office 365.

Autodiscover

DeploymentPro is recommended when migrating from Hosted Exchange providers, rather than using Autodiscover because, in addition to automating the configuration of new Outlook profiles (rather than having users create new profiles themselves), DeploymentPro will do the following:

• Import the signatures from the previous default profile
• Reattach any PST files that are configured in the previous default profile
• Import the auto-complete cached email addresses from the previous default profile

Autodiscover Configuration Settings for Hosted Exchange

DeploymentPro currently can only officially be used with migration projects where Microsoft 365 is the Destination. If using DeploymentPro with Exchange (either On-Premises or Hosted) as a Destination, a proof of concept should be run first.

The key element in the configuration is Autodiscover. Autodiscover needs to be configured correctly, and it must be reachable from the device that DeploymentPro is running on. DeploymentPro will try to detect what the Autodiscover URL and certificate is, based on DNS settings.

• To override these settings, change them to a new setting and, on the Configuration screen, select the checkbox beside Bypass Local Autodiscover.
• If DeploymentPro cannot detect the settings necessary to configure the Outlook profile, you can fill them in yourself. The Autodiscover URL usually looks something like this: https://autodiscover." + domain + "/autodiscover/autodiscover.xml" and can be verified by your Exchange administrator. The certificate needs to be defined in this format:  ​​"msstd:<FQDN the certificate is issued to>"​  and will result in something that looks like this: ​​"msstd:mail.mining88.com"​. 

Autodiscover vs. DeploymentPro

It depends on your migration scenario.

Scenario 1: Migration from On-Premises Exchange to Microsoft 365

AutoDiscover will not work, and the use of DeploymentPro is recommended.

The reason for this is that when you have an On-Premises Exchange, Exchange information is stored in the AD object for each user; this includes the Exchange GUID, database store, and server information. This means that when you create a new profile on a computer that is joined to the domain, Outlook is going to get that data out of the AD object instead of using AutoDiscover. The result of this is that the old connections are being rebuilt into the new profile. That means that one of two things needs to happen:

1) A manual configuration needs to happen. This would require either each end user going through all the settings to set this up themselves (any false or unknown entries will generate a support ticket), or your support team needs to manually set this up for each end user (either by visiting each end user individually, or by remoting into each computer and setting it up for them). Either of these options are time-consuming and cause downtime for the end user.

or

2) DeploymentPro can be used to automate the profile setup, reattach any local PST files found on the local drive, import the signature into the profile, and bring over the auto-completes from the previous profile.

Scenario 2: Migration from Hosted Exchange to Microsoft 365

In this case, Autodiscover will work, and you don't necessarily need to use DeploymentPro, although it does save some time and has some benefits, as outlined below.

The reason that AutoDiscover will work in this case is because there is no Exchange information being stored in the AD object for each user. In this case, AutoDiscover can be set to automate the setup of your end users' Outlook profiles. If you are using AutoDiscover rather than DeploymentPro in this scenario, once Autodiscover has been set and the MX record cutover has been made, inform users to create a new profile. They will be prompted to enter their name, email address, and password so that AutoDiscover can then build their profile.

Benefits of using DeploymentPro, in this scenario:

• If users do not create a new profile and try to continue to use their existing profile instead, they will be connected to their old Hosted Exchange provider and will not see any new mail arriving, nor be able to send any email out. If DeploymentPro is used, the users will be automatically prompted to set up their Outlook profiles. This occurs after the Schedule Cutover button is clicked, which configures the DeploymentPro project.
• If a user has any PST files locally, and they are attached to their current profile, these will need to be reattached to their new profile. DeploymentPro automates this.
• Users will need to set up their signatures in the new profile. DeploymentPro automates this.
• Users would lose their autocompletes. DeploymentPro brings these over from the previous default profile.
• DeploymentPro has the added benefit that, in the portal, you can track which users have had their Outlook profile reconfigured.

DeploymentPro currently can only officially be used with migration projects where Microsoft 365 is the Destination. If using DeploymentPro with Exchange (either On-Premises or Hosted) as a Destination, then a Proof Of Concept should first be run. Exchange environments can have complex AutoDiscover settings, along with UPN and SMTP address mismatches, which can require troubleshooting and reconfiguration, before DeploymentPro can be made to work against such environments. A Proof Of Concept will uncover any complications. For more information on AutoDiscover settings, refer to the relevant related article below.

​If you are migrating from other supported Source environments (e.g., Zimbra, Lotus Notes, G Suite) the same information described in Scenario 2 applies.

For example, AutoDiscover will work and you do not necessarily need to use DeploymentPro. In these cases, often an Outlook client will need to be installed. At that time, the Outlook profile would be set up (normally by using AutoDiscover). Also when migrating from these different Source environments, users would not have signatures and/or local PST files that could be imported (for the signature) and reattached (for the PST file(s). DeploymentPro is less useful in these cases.

If DeploymentPro is used,  we recommend that you set up AutoDiscover. This way, Outlook profiles for new AD users will utilize AutoDiscover for their Outlook profile creation, rather than having to set them up manually.

Enable Autodiscover in EWS

Typically, when migrating to a Hosted Exchange platform, the provider will provide a registry key that needs to be hard set for each user. This will point the Autodiscover record to the specific customer tenant within the Hosted Exchange providers' multi-tenanted environment.

This needs to be deleted from each user's registry, so that:

• Autodiscover can be used by users to create new Outlook profiles, or.
• DeploymentPro can handle the Autodiscover requests and connect these directly to Office 365.

Steps

1. Create a Group Policy Object (GPO) to delete the following registry key:  Computer\HKEY_CURRENT_USERS\Software\Microsoft\Office\(current version)\Outlook\AutoDiscover\RedirectServers
2. In this folder, there will be a registry key that has an IP address. This key needs to be deleted.
3. Once deleted, the Registry folder, under RedirectServers, should look like the screenshot below.

When to run the GPO

The GPO should be run after the MX records have been cut over.

• Once this registry key is removed, ​​Out Of Office (OOF) and Offline Address Book (OAB) will stop working for Outlook. Do not remove the registry key until right before or after MX record cutover.
• It will not affect already set OOF and Outlook will just use the older OAB.

If using DeploymentPro, follow these steps in order:

1. Switch over MX records.
2. Create and run GPO to delete the registry key.
3. Within your MSPComplete portal, activate the DeploymentPro module for your users and set the Schedule Cutover date to a date/time after the GPO has been run.

If migrating to Microsoft 365, ​the Outlook Web Access portal can be used by users until the GPO has been run and DeploymentPro has configured their Outlook profiles. The URL for the Outlook Web Access portal is portal.office365.com

Bypassing Autodiscover

When migrating from one version of Exchange to another, it is not possible to have AutoDiscover in place for two environments at once. There are a couple of scenarios for bypassing the Source AutoDiscover in order to successfully configure a new Outlook profile for Microsoft 365. 

1. On-Premises Exchange to Microsoft 365 Exchange Online cutover migration:
   If migrating from On-Premises Exchange to Microsoft 365, and the computers are joined to the domain, Outlook will try to automatically configure the profile using SCP​ lookup (settings from Active Directory). Then it will query internal DNS, then look to External DNS settings. The new profile will be configured successfully, but it will automatically connect to the Source Exchange environment.
2. If performing a staged/batch migration from On-Premises or Hosted Exchange, it will be necessary to have some Outlook users connected to the Source environment and some users connected to Microsoft 365.  The users who need to connect to Microsoft 365 will need to bypass AutoDiscover.

There are several different ways that Outlook tries to connect to the AutoDiscover service. Their order and priority are as follows:

• SCP lookup
• HTTPS root domain query
• HTTPS Autodiscover domain query
• HTTP redirect method
• SRV record query

DeploymentPro automatically makes the following registry edits to bypass AutoDiscover and hardcode the Microsoft 365 server settings into the Outlook profile to ensure that users can begin using the Microsoft 365 profile right away.