inter-domain object move

Until yesterday, I was convinced, that inter-domain (in the same forest) is strictly impossible. I did huge migrations, hudreds thousands of objects and I thought that inter-domain migration is impossible. Yesterday I found document or notice regarding movetree.exe but:

• new object in destination domain retains the same object guid, but of course - sid is different - most of migrations requires the same sid and the same guid or to properly process new object and treat as the new as the old one (to mimic)
• new object has the old sid in sidHistory - ok
• the old object is deleted and can't be simply refurbished

In our huge migrations every time we created a new bunch of objects - in the same forest or in different forest, every time we used sidHistory, the old objects remains intact - just to have flexibility in operations. Every user profile with exchange mailbox/outlook profile was also migrated before the final switch, so... if userA in domain1 (domain1\userA) was prepared for switch, so his user profile with outloook profile was prepared for this operation and in M-Day (migration-day) he could just login on userA account in domain2 (domain2\userA) so he could still work with the same environment.

MoveTree scenario is possible only in a small environments, in small migrations.

upn change for M365 migration concerns

In infrastructure with PaloAlto, ActiveDirectory and VPN on Cisco AnyConnect after upn change we have a problem with access to infrascture. As I can remember - our envrionment - PaloAlto and AnyConnect have problem w with recognition of proper source domain (we have few domains) so after change of upn to a new value (equal to email address) workstation moves to different access policy for unknown users - it has access to selected infrastructure servers, but on user level there is no access to any components (for example rdp connections).

change upn for M365 migration

Some company with near 25k identities (above 30k accounts - many persons or identities have few accounts). Now in process of the big jump on clouds - Exchange Online and SharePoint Online.
And Houston, we have a problem.
On premise users using sAMAccountNames (in 3 domains), as You can remember users can have more than one account so only one account should be synchronized to Azure. So we had to use emails as upn (in ADFS) and during synchronization (email is synced as upn to Azure - by AADC/Entra Connect). To complicate the whole picture users can be switched between their accounts and between domains and... last, but not least, account names (sAMAccountNames) could be changed (some old app requirement). So, if emails are uniqe, we could plan to use emails as upn (one of possible scenarios described in Technet/Microsoft). Only one account per user is synchronised (filtering) and it was almost work with Teams, but now we are making the big leap to clouds.
What's wrong? After first steps toward hybrid we have the problem with employees who have access to more than one mailbox. Still, without migrated mailboxes, they start receiving logon request (form based login in Outlook) - expecting to provide valid email address. But, as You can remember - we have separated upn on premise (one of three possible, because we have three domains), but it's different than email addresses and upn on Azure, because upn on Azure is our email, but user is receiveing proposal with on premise upn which is different than email.
To the whole picture You should know, that we had blocked some traffic to outlook.com or outlook.net domains, but we should enable it to proper work of sharepoint online. We had to also set - enforce - in registry to avoid using M365 autodiscover... i think this is the whole picture...
So we can synchronize upn with emails, but:

• at first look we can recognize few apps with invalid access due to upn change
• if a user provide valid email outlook will work properly
• we don't know what will be affected by this change - we have 300-400 apps so impact is unknown

32bit printer driver on 64bit system - migration from Windows 2008 to Windows 2012R2

If you want to add 32 bit drivers to 64 bit Print Server You must use pnputil to upload drivers to the system (like for 64 bit drivers) and finally You must use 32bit Powershell Add-PrinterDriver – from this level enabling 32bit drivers is possible on 64bit system.

How to start 32bit version of Powershell? MSDN link:
Starting the 32-Bit Version of Windows PowerShell

When you install Windows PowerShell on a 64-bit computer, Windows PowerShell (x86), a 32-bit version of Windows PowerShell is installed in addition to the 64-bit version. When you run Windows PowerShell, the 64-bit version runs by default.

However, you might occasionally need to run Windows PowerShell (x86), such as when you are using a module that requires the 32-bit version or when you are connecting remotely to a 32-bit computer.

To start a 32-bit version of Windows PowerShell, use any of the following procedures.
In Windows Server® 2012 R2

On the Start screen, type Windows PowerShell (x86). Click the Windows PowerShell x86 tile.
In Server Manager, from the Tools menu, select Windows PowerShell (x86).
On the desktop, move the cursor to the upper right corner, click Search, type PowerShell x86 and then click Windows PowerShell (x86).
Via command line, enter: %SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

In Windows Server® 2012

On the Start screen, type PowerShell and then click Windows PowerShell (x86).
In Server Manager, from the Tools menu, select Windows PowerShell (x86).
On the desktop, move the cursor to the upper right corner, click Search, type PowerShell and then click Windows PowerShell (x86).
Via command line, enter: %SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

In Windows® 8.1

On the Start screen, type Windows PowerShell (x86). Click the Windows PowerShell x86 tile.
If you are running Remote Server Administration Tools for Windows 8.1, you can also open Windows PowerShell x86 from the Server ManagerTools menu. Select Windows PowerShell (x86).
On the desktop, move the cursor to the upper right corner, click Search, type PowerShell x86 and then click Windows PowerShell (x86).
Via command line, enter: %SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

In Windows® 8

On the Start screen, move the cursor to the upper right corner, click Settings, click Tiles, and then move the Show Administrative Tools slider to Yes. Then, type PowerShell and click Windows PowerShell (x86).
If you are running Remote Server Administration Tools for Windows 8, you can also open Windows PowerShell x86 from the Server ManagerTools menu. Select Windows PowerShell (x86).
On the Start screen or the desktop, type PowerShell (x86) and then click Windows PowerShell (x86).
Via command line, enter: %SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

I testted this procedure with about 300 drivers (150 64bit and 150 32bit) and it works perfectly. It was a migration from 2008R2 Print Server to 2012R2 PrintServer.

Available tools (Print Migration Wizzard) can't manage huge print drivers library (above 2GB), we had 4,5GB so only manual process was possible. We migrated manually all drivers (copy all *inf* folders with printer drivers), register them using pnputil, add ports using PowerShell, add printers (connect them 64bit drivers with Ports) and later using 32bit version of Powershell:

- add printer drivers for 32bit.