(2014-06-21) Installing PES v3.2 On W2K12(R2)

To download PES see this blog post.

If in addition to migration objects (users, groups, computers, etc.) you also need to migrate passwords, then you also need to install the Password Export Service (PES) on a(ny) writable DC in the source AD domain. PES cannot be installed on a read-only domain controller (RODC). The default behavior of ADMT, when migrating passwords, is to configure every target user account with "change password at next logon", unless "password never expires" (most likely service accounts) or "smartcard is required for interactive logon" on the source user account. After the password migration, it is also possible to revert the setting of "change password at next logon" by using PowerShell, ADMOD or any other LDAP modification tool.

Assuming the OU "OU=Migrated-Users,DC=ADCORP,DC=LAB" contains all migrated user accounts…

• PowerShell –> Get-ADUser -SearchBase "OU=Migrated-Users,DC=ADCORP,DC=LAB" -Filter * | %{Set-ADUser $_.SamAccountName -ChangePasswordAtLogon $false}
• ADFIND/ADMOD –> ADFIND -b "OU=Migrated-Users,DC=ADCORP,DC=LAB" -f "(&(objectCategory=person)(objectClass=user))" -adcsv | ADMOD pwdLastSet::-1

–

PES has a very tight relation with ADMT. Because of that you must first create a so called encryption key on the server where ADMT is installed before even starting the installation of PES!

–

To create the encryption key on the server with ADMT:

• Open a command prompt window and navigate to the folder "C:\Windows\ADMT"
• ADMT key /option:create /sourcedomain:ADCORP.LAB /keyfile:C:\Windows\ADMT\ADMTPESEncryptionKeyFile.pes /keypassword:*

Figure 1: Creating The Encryption File For PES On The Server With ADMT

–

Securely transfer the encryption file to the RWDC that will host the PES service. You can now start the installation of PES.

Figure 1: Selecting The Encryption File For PES

–

Figure 2: Specifying The Password Securing The Encryption File

–

The "Password Export Server (PES)" can be configured to run with a service account. This enhancement removes the dependency on the "pre-Windows 2000 compatible access" group that PREVIOUS should contain the well-known security principals "Everyone" and "Anonymous Logon" (in W2K only "Everyone" as that by default already contained "Anonymous Logon"). THEREFORE, preferably use a service account instead of the Local System account.

Figure 3: Specifying The Service Account That Will Be Used By The Password Export Service

–

The PES service account will be granted the "logon as a service" user right. After the installing you must reboot the RWDC.

–

For additional info see the ADMT Migration Guide.

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2014-06-20) Installing ADMT v3.2 On W2K12(R2)

To download ADMT see this blog post.

To be able to install the latest version of ADMT, it must be either a GUI based member server (preferred!) or a writable DC (RWDC). Server Core installations are not supported, nor is it possible to install on a read-only domain controller (RODC).

Remember that you require either SQL Express or SQL Server to be able to use ADMT. While using W2K12R2 I was not able to use the Windows Internal Database feature. For the free version of SQL I had to download and install SQL Express. The latest available version (at the time of writing) of SQL Express (Microsoft SQL Server 2012 Service Pack 1 (SP1) Express) can be downloaded through this link. During the installation of SQL Express will may be invited to download and install additional updates. After installing SQL (Express), you can start the ADMT install. It is not possible to upgrade current ADMT installations. You must uninstall old ADMT versions before installing the latest version. Assuming you chose to use SQL Express, the default instance name is .\SQLEXPRESS as you can see below in the picture.

Figure 1: The Default Connection String For SQL Express

–

Figure 2: ADMT Being Installed

–

Figure 3: The Possibility To Import Old ADMT Databases

–

Figure 4: The Installation Of ADMT Finishing Successfully

–

On W2K12(R2), after clicking the Start button, do not search "ADMT", but rather search for "Active Directory Migration Tool" or just "Migration".

–

Figure 5: The ADMT GUI

–

For additional info see the ADMT Migration Guide

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2014-06-19) Microsoft Released An ADMT Version To ALSO Support W2K12(R2)

As mentioned about 6 months ago in this blog post, Microsoft was going to release an update for ADMT to support W2K12(R2). Well, the time has come and Microsoft has made available an update to provide for that support.

–

You can download the new ADMT version from CONNECT and you need to sign in with your Windows Live ID. All previous versions of ADMT are now deprecated! This version of ADMT supports Windows/AD versions up to the latest and greatest Windows Server 2012 R2.

–

Navigate to https://connect.microsoft.com/directory/non-feedback, and somewhere at the top (at the time of writing) find in the "product" column "Azure Active Directory Customer Connection" with in the "program" column "Windows Server Active Directory Migration Tool (ADMT)". Then in the "actions" column click on "join" to join the program. If you do not see "join" but rather you see "quit", then you are already able to download ADMT. You will now be able to download the ADMT update. To download the ADMT update click on "Windows Server Active Directory Migration Tool (ADMT)". On the arriving page you will see a link for both ADMT and PES.

Click on "Active Directory Migration Tool (ADMT) QFE – x86" to go to the download section for ADMT

Click on "Password Export Server (PES) – x64" to go to the download section for PES.

–

Page 54 of the ADMT Migration Guide (see below) for link explains how to install ADMT.

The latest ADMT Migration Guide in WORD format can be downloaded through this link. The web-based version of the ADMT Migration Guide can be downloaded through this link. For additional migration related information you may also want to check this link.

–

Regarding the installation of ADMT, check this link.

Regarding the installation of PES, check this link.

–

UPDATE 2015-01-17:

• Assuming you already joined the correct program, new link: https://connect.microsoft.com/site1164/program8540
• You require a Microsoft account.
• If you have not joined the program yet:
• Go to https://connect.microsoft.com/directory/
• Join the program called "Windows Server Active Directory Migration Tool (ADMT)"
• Then click on either https://connect.microsoft.com/site1164 or https://connect.microsoft.com/site1164/program8540
• The rest you’ll be able to figure out

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2013-12-14) ADMT Update To Be Released For New Operating Systems

The last version of ADMT that was released was v3.2 (somewhere in 2010) and the last version of PES that was released was v3.1 (somewhere in 2008). After numerous requests, both ADMT and PES have never been updated. The latest available versions are able to support DCs and AD domain up to W2K8R2. Unfortunately no support (yet) for W2K12/W2K12R2 DCs and AD domains. However, a few days ago the product group made the following announcement through the ASKDS blog:

–

In short, the update will allow ADMT to install on our newer OSs (both the ADMT and PES components). This should help alleviate some of the problems that customers have been reporting with the tool. We know that there are many of you who would like to see improvements or additional features in the tool beyond this, but we made the decision to focus this update on the OS compatibility issues, since that’s the thing that is impacting migrations the most right now.

The changes we have made require a fair bit of testing before we can release them – among other things, we have to test full-scale migrations against each combination of OS versions to make sure that nothing unexpected occurs.  Once that testing is complete, we’ll publish the new version for public download, probably as an update to the existing 3.2 version.  We don’t have an exact date right now, since it’s likely to take us a few months to finish our testing, but we’re hoping to have it out and available in the first quarter of 2014.

–

You can download ADMT v3.2 through this link.

You can download PES v3.1 (x86) through this link and PES 3.1 (x64) through this link.

Info about installing ADMT can be found through this link.

You can download the latest ADMT migration guide through this link.

More info about performing migrations with ADMT can be found through this link.

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2010-06-20) ADMT v3.2 Has Been Released

"The Active Directory Migration Tool version 3.2 (ADMT v3.2) simplifies the process of migrating objects and restructuring tasks in an Active Directory® Domain Service (AD DS) environment. You can use ADMT v3.2 to migrate users, groups, service accounts, and computers between AD DS domains in different forests (inter-forest migration) or between AD DS domains in the same forest (intra-forest migration). ADMT can also perform security translation (to migrate local user profiles) when performing inter-forest migrations."

Download it from here.

Additional info about ADMT can be found here and here.

Latest ADMT Migration Guide can be downloaded from here.

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2010-05-19) Information About Upgrading To Windows Server 2008 R2 AD

If you are interested in reading information about upgrading to Windows Sever 2008 R2 AD, then make sure to check the following links/docs:

• Upgrading Active Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains (DOC)
• Upgrading Active Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains (WEB)
• Upgrading Domain Controllers: Microsoft Support Quick Start for Adding Windows Server 2008 or Windows Server 2008 R2 Domain Controllers to Existing Domains
• Running ADPREP To Upgrade the AD Forest/Domain

 

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2009-11-09) Migrating Your Local Users, Local Groups And Memberships From The SAM Into AD

You may have a Windows Server somewhere that’s not joined to a joined that contains lots of local user accounts, local groups and of course memberships of local accounts in those local groups. On that server you have permissioned all NTFS permissions with those local groups. Another scenario is a member server with exact same information. Now you have decided you want to "migrate" all of that into AD. How would that be possible easily without loss of information?

REMARK: Before you do this, as a fallback plan, make sure to have a FULL backup of the server you want to perform this operation on!

The starting point would be something similar to the pictures below.

All Users

All Groups

All Group Memberships

In these pictures you see local users and local groups and those users are member of those local groups. The way to keep that all is to promote the server to a DC in a NEW AD domain. Because of that the information is kept and "migrated" into AD (into the ‘Users’ container). If you promoted the server into an existing AD domain, the information in the SAM would be lost.

In this example I’m promoting a member server in an AD domain into a new AD domain in the same AD forest. After promotion of the member server into a new AD domain in the existing AD forest, the end result is shown below.

Migrated Users and Groups

Migrated Group Memberships

Migrated User Properties

By doing it this way, you migrate the info into AD and when that has occurred you can use ADMT to migrate the objects into some other AD domain. The fun part is that in the second migration into another AD domain, you will not have issues regarding the membership rules when migration between AD domains in the same AD forest!

More specific information about the upgrade process can be found here.

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2009-10-04) Upgrading ILM 2007 To FIM 2010 – What To Do?

SOURCE: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/b47c5545-b066-45bd-9e21-9601f5a7fa86

In the ILM 2 Forum the following question was asked:

What’s the upgrade path to go from MIIS/ILM 2007 to FIM 2010? Will FIM 2010 just use your current configuration? Also, how’s the timing of the FIM release? If you were implementing Identity Management now – is it best to implement it on ILM or FIM?

Bob Tucker from Oxford Computer Group answered:

1. The upgrade path from ILM 2007 to FIM 2010 involves several steps, but generally will not be terribly difficult. You would need to accomplish the following:
   
2. Stand up a test environment that represents your production environment
   
3. Upgrade your SQL database to 2008 if not already there
   
4. Recompile all code using .Net 3.5 (Visual Studio 08)
   
5. Perform complete end to end testing
   
6. Verify you have x64 versions for any third party apps required on the ILM server (Oracle client, Notes client, etc)
   
7. Build Windows 2008 x64 and install FIM 2010 sync engine – pointing to the SQL 2008 version of the ILM database
   
8. Perform complete end to end testing
   
9. Consider installing FIM 2010 portal
   
10. Consider migrating some of the codeless capabilities and group management to FIM 2010
    
11. Perform complete end to end testing
    

As you can see from above – FIM 2010 can make use of your existing design, but it is not a point and click upgrade (one is 32 bit only, the other 64 bit only).

Timing of the release of FIM 2010 can best be answered by some of the MS guys – they have the latest information.

As for which one to use – if you are just now getting into the process of implementing an identity management solution, you should start with determining systems involved, gathering requirements, developing a design, etc. If you absolutely require the use of a portal to allow user participation, then you may want to wait on FIM 2010 (or look at designing your own); if you are looking to deploy in the immediate future, you will have to decide whether or not you can use release candidate software in a production environment. With the release of RC1 of FIM 2010, you may be able to participate in TAP/RDP programs if desired.

As you can see from the migration path; if you decide to start with ILM 2007, you can still migrate the capabilities to FIM 2010 without too much work, though it may involve some rework to move some of the design into the portal.

David Lundell from Ensynch answered additionally:

In step 3 You will need to change some of your references to use 64-bit editions of the new Microsoft.metadirectoryservicesex.dll that was introduced with the hotfix referenced below: http://support.microsoft.com/default.aspx/kb/946797.

I can’t understate the importance of following Bob’s advice in Step 5. 64 bit editions of the items needed is critical. For example the Host Access Management Agents are not yet available for 64-bit use since they depend on Host Integration Server 2006 which won’t install on Windows Server 2008 x64. So if connect to mainframes you will need to consider how to do that:

1. using ILM 2007 as a bridge
   OR
   
2. using a 3rd party MA
   OR
   
3. writing your own MA
   

My personal comments:

With regards to "timing release", the known official release date/period is Q1 2010.

Should you use ILM 2007 or FIM 2010? Basically what ILM 2007 is able to do, FIM 2010 is also able to do. Big thing you need to take into account is the architecture. ILM 2007 is 32 bit only and FIM 2010 is 64 bit only. Any dependency on THAT needs to be investigated. As already mentioned, if you need additional client software for an MA (Oracle, Notes, SAP, etc.) to work and you want to use FIM 2010, make sure 64 bit client software is available!

If you need portal functionality, such as users need to interact with ILM/FIM for whatever reason (e.g. self-service password reset, other self-service stuff, group management, etc.) you are better in using FIM 2010. It does not mean it is not possible to do it with ILM 2007. What it does mean is that ILM 2007 itself cannot do it, but you need s solution external to ILM for those features.

The sync engine in FIM 2010 differs from ILM 2007 in the following ways:

• Supports both scripted provisioning and codeless provisioning
  
• Supports both inbound/outbound attributes flows and inbound/outbound sync rules
  
• Automatic hierarchical provisioning (creating directory structures if they do not exist) (ILM 2007 support this also, but rather in code)
  
• Equal precedence (meaning "last sync wins" and allowing the merger of multi-valued attributes such as the member attribute in group objects)
  

With regards to licensing, for the Sync Engine you just need a server CAL, but if you want to use the features of the Portal you need user CALs in addition.

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2008-07-15) Migration Support In ADMTv3.1 For Windows Server 2008

In this post I explain what you can do with ADMTv3 and what you cannot do. Additionally I also define common migration steps and provide links to other information sources. ADMTv3.1 has been released a few days ago and it now supports Windows Server 2008 based servers. If you need to use ADMT on W2K3 use ADMTv3 and look at this post.

Like ADMTv3 could only be installed on a W2K3 server, ADMTv3.1 can only be installed on a W2K8 server. Additionally the "Password Export Server" is available as a separate download for both 32 bit and 64 bit computers. Microsoft also updated the migration guide.

System Requirements

• Supported Operating Systems: Windows Server 2008
  
• ADMT can be installed on any computer capable of running the Windows Server 2008 operating system, unless they are Read-Only domain controllers or in a Server Core configuration.
  
• Target domain: The target domain must be running either Windows 2000 Server or Windows Server 2003 or Windows Server 2008
  
• Source domain: The source domain must be running Windows 2000 Server, Windows Server 2003, or Windows Server 2008
  
• The ADMT agent, installed by ADMT on computers in the source domains, can operate on computers running Windows 2000 Professional, Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008
  

The following is available:

• ADMT v3.1 (only supports W2K8 servers, but supports all AD versions)
  
• Password Export Server version 3.1 (x86) (supports W2K, W2K3 and W2K8 servers)
  
• Password Export Server version 3.1 (x64) (supports W2K, W2K3 and W2K8 servers)
  
• Guide for Migrating and Restructuring Active Directory Domains Using ADMT v3.1

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2006-12-27) Migrating Stuff With ADMTv3

ADMTv3 has been out for a while and is the free Microsoft Migration Tool available for use (besides other small tools that can help you during your migration like NETDOM, SUBINACL, ROBOCOPY, etc.). It can be downloaded here

Besides the tool you can also view and download documents with loads of info about migrations and how to use ADMT. The following information is available:

• ADMT v3 Migration Guide
• How to use Active Directory Migration Tool version 2 to migrate from Windows 2000 to Windows Server 2003
• Windows 2000 Server Domain Migration Cookbook

 

ADMTv3 is a migration tool that can help you with:

• Migrating user and group objects (with or without sIDHistory) from one domain to another
• Migrating computer objects and the actual computers from one domain to another
• Translate stuff (from source domain –> target domain):
  • Security on file based data ACLs
  • Security on printers ACLs
  • Security on shares ACLs
  • Security on registry ACLs
  • Security on profiles ACLs (and registry information)
  • Service Accounts used by services
    • REMARK: make sure you identify the custom service accounts FIRST on each server to be migrated. This also prevents the option "change password at next logon" being set as the user account is migrated. All accounts NOT identified as service accounts will have the option set. If needed you can revert this afterwards with ADMOD/ADModify
  • It CANNOT help you with:
    • Translate security on services ACLs. For that you can use SUBINACL
    • Translate information within IIS and COM+. For that you need to use a third party tool
    • Translate information within SQL. For that you need to use a third party tool
    • ….other apps…. –> For that you might need to use a third party tool

 

Interesting enhancements within ADMTv3 when compared to ADMTv2:

• When migrating between AD forests, it is aware of possible schema differences between the AD forests
  • It allows to define attributes for exclusion during migration
  • Schema differences (attributes that are not migrated) are shown within the migration logs
• SQL or (W)MSDE database support
  • Enables and supports the use of multiple consoles
• The possibility to select source and target DCs for migrating objects
• It supports INPUT files for objects to be migrated
• It allows the rename of objects during migration (through the use of an input file)
• Performing pre-migration tests to ensure availability of computers to be migrated
• Additional options when migrating passwords like:
  • "Do not update passwords for existing users"
  • Migration of changed passwords from source domain
• The "Password Export Server (PES)" can be configured to run with a service account. This enhancement removes the dependency on the "pre-Windows 2000 compatible access" group that PREVIOUS should contain the well-known security principals "Everyone" and "Anonymous Logon" (in W2K only "Everyone" as that by default already contained "Anonymous Logon") (in W2K3 you can revert to the same behavior but that IS NOT recommended!)

 

NOT that of an enhancement:

• It can only be installed on Windows Server 2003

 

When migrating from one domain (source) to another domain (target) the following are high-level steps to consider:

• Make sure the target AD has been configured (sites, subnets, replication, OUs, GPOs, delegations, DNS, WINS, DHCP, etc.)
• Setup name resolution (WINS or DNS) between source and target domain/forest
  • REMARK: When either endpoint of a trust is NT4, you must use NetBIOS name resolution which is made possible by WINS or LMHOSTS. When either endpoint of a trust is W2K or higher, you can either use NetBIOS name resolution, which is made possible by WINS or LMHOSTS, or use DNS name resolution (I prefer the last!)
• Setup trusts between source and target domain
  • REMARK: When either endpoint of a trust is NOT W2K3, you must use an external trust. When either endpoint of a trust is W2K3 or higher, you can either use an external trust or a forest trust. For the latter, which one you use depends on the environment and your requirements.
    Be aware that sIDFiltering is by default enabled on the outgoing part of an external trust (which therefore impacts the use of sIDHistory AND/OR the use of external domain group membership within the same target forest)
    sIDFiltering is by default NOT enabled on the outgoing part of a forest trust (which therefore does NOT impact the use of sIDHistory AND/OR the use of external domain group membership within the same target forest). Some documents might mention sIDFiltering is enabled by default on the outgoing part of a forest trust. This is not true!
    When sIDFiltering is enabled on the outgoing part of a trust and sIDHistory is used AND/OR domain external domain group membership within the same target forest, you need to disable it using the following command:
    • Netdom TRUST <TrustingDomain> /domain:<TrustedDomain> /quarantine:No /userD:<domainadminAcct> /passwordD:<domainadminpwd>
      (to ENABLE sIDFiltering again specify Yes)

 

SOURCE DOMAIN —————–(trust)—————–> TARGET DOMAIN
                              ^                                             ^
                               |                                              |
                               |                                              |
                               |                &nbsp
;                             |
                    outgoing part                           incoming part
(sIDFiltering is ALWAYS configured on the outgoing part of a trust – not saying if it is configured or not! Just saying WHERE)

Also see:

• When to create an external trust
• When to create a forest trust

• Setup migration accounts to be use with the migration tooling
  • REMARK: this really depends if you have a one-way or two way trust, what you want to migrate and if the source and or target domain are AD… see the migration guide for this!
• Install and configure migration tooling and if needed for password migration, also designate a source DC as the Password Export Server (PES) and install the required software
• Identify service accounts across servers in the source environment
• Migrate groups, user accounts with passwords and group memberships (with sidhistory)
  • REMARK: When resource access is provided by a sID, sIDHistory can help you. However if resource access is provided in another way (e.g. <domain><user or group>, or something else), you MUST add the target ACEs first before the users switch over to their new account. When not taken care of, resource access might be lost. Examples of applications where this can occur is SQL server.
  • REMARK: To use sIDHistory your target domain MUST be in at least "Windows 2000 Native" mode or domain functional level. Well, this is the supported configuration! There exists migration tooling that is able to migrate sIDHistory without the AD domain being in at least "Windows 2000 Native" mode or domain functional level, or in other words, still being in "Windows 2000 Mixed" mode or domain functional level. Remember, the latter is NOT supported by Microsoft! I also do not know that the impact is of this and what requirements might exist emposed by the migration tool.
• Migrate clients from the source domain to the target domain, translate security on the client, and translate profiles (at this moment users start logging on with their new AD account on the migrated clients that have been migrated previously to the w2k3 domain)
• Migrate mailboxes if needed
  • REMARK: This is another story and it depends if you are migrating from Exchange 5.5 or Exchange 2000/2003
• Migrate servers to the new domain or migrate data to new servers
• Translate security (Re-ACL) and other stuff of the data/resources from source security principals to target security principals (replace the security descriptors from the old domain with the security descriptors from the new domain) (see list above)
  • REMARK: Although you might have not yet translated security it might look like the ACLs already show security principals from the target domain. This DOES NOT mean security has been translated. This occurs when using sIDHistory as the target system recognizes the sID (because it is stored in the sIDHistory field) and shows the target security principal instead of the source security principal. If you would cleanup sIDHistory suddendly the source security principal is shown and if you additionally remove the trust an "unknown sID" is shown
• Cleanup temporary configurations
• Cleanup sidhistory (recommended!).
  • REMARK: sIDHistory is a temporary configuration and is used to access resources while those resources still have security descriptors from the source domain. As soon as all data (file, folders, mailboxes, etc.) have been re-ACL-ed sIDHistory can be cleaned. sIDHistory should only be used temporary for migration purposes! To clean sIDHistory you can use ADFIND and ADMOD. The command line looks like:
    • For the complete target domain:
      • adfind -default -f "(sidhistory=*)" sidhistory -adcsv | admod -csh -unsafe
    • For just some OU within the target domain:
      • adfind -b "<DN of some OU>" -f "(sidhistory=*)" sidhistory -adcsv | admod -csh -unsafe
• Remove trusts
• Decommission old domain(s)

 

For more information about ADMTv3 and possible steps needed for migration see the ADMT v3 Migration Guide.

 

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————