Tag: Migration

Exchange Migration: Outlook kept prompting for password after migration

Hi guys and girls, hope you are doing well, as the pandemic is still on-going, hope that you guys are keeping cleanliness and safety first.

Today’s topic is about exchange migration of mailboxes from on-premises to Office 365. This issue is where the legacy windows client or legacy office apps has issue with their outlook applications keeps prompting for credentials and showing disconnection. The issue also do happen to Windows 10 machines but not as aggressive as the Windows 7 machines.

This environment has the following items,

  1. Exchange server: 1 unit, version 2013, CU23 (latest)
  2. Windows client: Combination of Windows 7 and Windows 10
  3. Office applications: Combination of 2013, 2016, 2019 and Microsoft 365 apps for business in both windows 7 and windows 10 categories
  4. Migration method: Remote move migration
  5. Hybrid establishment: Yes
  6. Microsoft 365 license: Business standard/basic

As we all know that the major pre-requisites must met before starting the hybrid and perform migration.

We notice intermittent connections while running the Wireshark on Windows 7 with M365 business apps, while trying to login using the migrated account credential on an Outlook app. We ran a re-creation of the outlook profile and the prompt for credential has stops. This is definitely not the right solution. Solutions is dependent with what caused the issue.

At first we suspected something got to do whitelisting on the network layer but we had confirmed that the whitelisting are correctly configured. Next, we suspected something go to do with compatibility on windows with/or office apps version. This is not a very good idea. After quick research, I came about modern authentication could be the caused, and there where I had an idea on suggesting to turn off the security default in Azure portal and then turn off the modern authentication in Office 3655 tenant. After 10 to 15 mins, the intermittent connections no longer shows up on the Wireshark.

Modern authentication is enabled by default for every new Office 365 tenants, so please be aware if your environment has legacy windows client running or legacy office applications, do consider to turn them off first before proceeding to deploy Microsoft 365 apps.

Azure portal > Azure AD > Properties > Manage security defaults
Office 365 admin center > Settings > Org Settings > modern authentication

Modern authentication was the one the interfered with the machines and it kept challenging the users to key in credentials due to the compatibility was not met. Once the modern authentication is turn off, the environment now is running basic authentication.

References:

How to Migrate or Import VM from Windows Server 2008 R2 to Windows Server 2012 R2?

This is my first time doing VM migration or import/export of VM from server 2008 R2 to server 2012 R2. At first, I used the export function from the Hyper-V in server 2008 R2 and I notice the export result was different from the server 2012 R2. Thus, when I try to import the VM from server 2008 R2 to server 2012 R2, it was unable to recognize.

Always make a backup copy! Don’t modify the original!

This is because 2008 or 2008 R2 are legacy servers, and choosing the export feature to export the VM will result of export EXP file instead of XML file. In server 2012 R2, VM that is exported has XML file.

The best way to import VM from legacy server is to copy the entire VM folder to server 2012 R2. When I mean entire VM folder, means its VHD and etc..

This VM that I am importing does not have any checkpoints or snapshot, so I am unsure that do you required to delete the copied snapshots before you import.

So what I did was,

  1. At server 2008 R2, shut down the VM
  2. Locate the entire Data folder of the VM in File Explorer
  3. Right click the folder > Properties > Share > Advanced Sharing > Add the specific user account (server 2012 R2) and the computer (server 2012 R2) > Full Control
    • Is up to your choice on how you want your destination server to retrieve the source information (VM), it could be via a Network Share, a USB, or an external Hard Disk
  4. At server 2012 R2, open file explorer
  5. At the top bar, type “\\<2008 R2 server name/IP address>\<vm folder name>\”
  6. Copy the entire folder and paste it into server 2012 R2 (your comfortably location/driver/directory)
  7. Remember to remove the share permission of the folder in server 2008 R2, after you finish copying the folder  from server 2008 R2 to server 2012 R2
  8. Create a new folder in server 2012 R2 and rename it as your actual/original VM’s folder naming in server 2008 R2, this folder will be the new location of your VM
  9. Go to Hyper-V in server 2012 R2 > select the Import Virtual Machine at the right side bar
  10. Browse and locate the VM folder that you just copied
  11. Select the import type “Copy the virtual machine“, this allows you to create a new unique ID of the virtual machine and also allows you to choose your new location to store this VM in sever 2012 R2
    • Capture
  12. Make sure the new location are browse to the new folder that you just created in server 2012 R2
  13. Then you click next > finish and wait for the importing to complete
  14. Make sure the VM in server 2008 R2 is Shut down
  15. Start or Boot up the VM in server 2012 R2 (If required to change IP address of the VM then change)
  16. Everything is fine and monitor for 48 hours, then only decide to remove the VM in server 2008 R2

 

After import the VM, Hyper-V do not start the VM automatically. You have to start the VM manually, after import completed.

Office 365: Synchronized/Migrated user showing wrong UPN in Office 365

Oh no! I forgot to change/set the user’s UPN correctly before migration! Even a simple job we could get it wrongly. Thus, this will lead you to panic. Well, if you are panic, just take a deep breath.

Usually, such problem we resolve it by breaking/disable the DirSync so that the user’s status change from “Sync from on prem” to “cloud”. So that if we could make the changes at the Office 365, without interrupting the on-prem. However, this kind of solution is troublesome because it takes hours for the DirSync to complete disable and waiting for the user’s status to change. When I mean by hours, depends of the amount of users you have at Office 365. The larger the amount the longer it takes for the time taken for the DirSync to complete disable and for the user’s status to change.

Here are the problems we faced:

  1. Forgot to set the email policy
  2. Forgot how to set email policy
  3. Set the wrong email policy
  4. Highly confident and doesn’t double check
  5. Doesn’t do enough research about preparation of migration

Lucky for me that I have found a way to solve this kind of clumsiness, please refer to the reference given below.

Note: This solution is only for clumsy situation. Don’t put it into your planing of migration, because this will make you feel like a total blockhead in front of your customers. Please do not take it in as a habit.

Reference:

  1. http://www.codenutz.com/office365-changing-the-main-login-name-for-upn-for-a-user-via-powershell/