Thursday, November 20, 2008
Quest acquires NetPro
Quest pretty much owns the Exchange and Windows migration 3rd-party space. It will be interesting to see how they leverage NetPro's diverse (some are very similar) set of tools and experts to provide us the best solutions out there. Forgive me if you're a fan of NetIQ...
http://www.quest.com/newsroom/news-releases-show.aspx?contentid=8055
Disclaimer: Quest/NetPro is a partner of my employer (Avanade)
Monday, July 21, 2008
ADMT 3.1 Released + Improved Migration Guide
Here it is.
Microsoft has also released an improved ADMT migration guide, titled Migrating and Restructuring Active Directory Domains Using ADMT v3.1. Get it here
Tuesday, July 15, 2008
2008 Printer Migration and Consolidation
Here.
Other helpful links:
KB938923 - How to back up and then restore printers when you upgrade from Windows Server 2003 to Windows Server 2008
Windows 2008 Print Services (TechNet link)
Friday, July 11, 2008
Migrating login scripts...necessary?
By combining GPOs and GPPs, in many cases we're now able to completely eliminate the need for a login script.
Q. What is the main difference between policy settings and preference settings?
A. The main difference between policy settings and preference settings is that preference settings are not enforced. This means the end user can change any preference setting that is applied through Group Policy, but policy settings prevent users from changing them.
A few things to note:
* To manage GPPs you need a Win2008 Server or Vista-SP1 machine on your network
* To utilize GPPs you need your clients to at least be at XP-SP2, Vista, 2003-SP1, or 2008, in addition to having the GPP Client-Side Extensions update installed (available via Windows Update)
For more information:
Group Policy Preferences Overview
Group Policy Preferences FAQ
Wednesday, July 9, 2008
Windows Server 2008 Step-by-Step Guides
Migration suites/tools- the players
Microsoft - FSMT (File Servers, only currently supported up to Server 2003), Print Migrator (Print Queue/Server Migrations, currently supported up to Server 2003)
Quest Software - DMW and Quest Migration Manager for AD
NetIQ - Domain Migration Administrator
WinZero - Server and Domain Migrator 2007
PointDev - PointDev's IdealMigration is a great product to demo. It includes MMC snap-in functionality, and the free reporting features included in the Demo alone make it worth checking out. Ideal for NT/2000/2003 environments.
Free WebCast: Plan Your Windows Server 2008 Migration in Less Time with Fewer Resources
Go here
Presented by: Baldwin Ng, Senior Product Manager, Microsoft Corporation
Microsoft Assessment and Planning Solution Accelerator (MAP)
PStools - Free, essential tools for all admins
The Desktop Files: PStools Primer
Fixing ACLs on Permissioned Resources
In conjunction with Robocopy, you can use the SubInACL free tool to replace/append SIDs to the ACL of each file/folder. SubInACL can be fed a mapping file which maps source to target user names/SIDs. Usually you'll want to start off by appending ACE entries to the ACLs to allow for co-existence (especially if the data migration activities happen to be occuring in parallel with user/group migrations). Once user/group migration activities are complete, and the environment has stabilized, you can re-run SubInACL to remove the unneeded source SIDs.
Remember that when using SIDHistory to access resources, you can only reach back in to the source, and not forward from the source to target. Even when moving data in the above scenario, I would always make it standard practice to be bringing over users with their SIDHistory attribute populated with their source domain SID (attribute name in source: ObjectSID)
As always with SIDHistory, make sure you have it correctly enable on your trust. Different versions of NETDOM (unfortunately you can only do it from a command-line) have different switches to enable SIDHistory. Running a netdom /? will let you know whether you should be using the /EnableSIDHistory:Yes switch, or /Quarantine:No switch. Here are examples:
Netdom Syntax:
Netdom trust TrustingDomainName /domain:TrustedDomainName /quarantine:No
netdom trust trusted_domain /domain:trusting_domain /enablesidhistory:yes
Depending what security context you're running this command in, you may need to specify source and target domain credentials (syntax again can be found with netdom /?)
Robocopy (included as part of the 2003 Resource Kit - free to licensed Windows users)
Robocopy GUI
SubInACL
Solution Accelerator for Consolidating and Migrating File and Print Servers from Windows NT 4.0
"The Solution Accelerator for Consolidating and Migrating File and Print Servers is a set of documentation which provides guidance on consolidating and migrating file and print servers from Windows NT 4.0 to Microsoft Windows Server 2003 and Windows Storage Server 2003"
Get it here
ADMT User Migration command-line syntax (and examples)
Credit to Brent Dorrington for the below examples:
Admt.exe can be used to migrate users from the command-line (if you're sick of the ADMT GUI, or just want to automate/batch/script your migrations):
ADMT USER /N "user_name1" "user_name2" /SD:"source_domain" /TD:"target_domain" /TO:"target_OU" /MSS:YES
for /f "tokens=1,2,3* delims=,/ " %%i in (mycsvfile) do ADMT USER /N "%%i" "%%i" /SD:"source_domain" /TD:"target_domain" /TO:"target_OU" /MSS:YES
Note: if you are running from command line, remove the 2nd % in above syntax. The above syntax is fine if you are running in a batch file.
If the 1st column isn't command-line, then just increment %i (i.e. 2nd column would be %%j and so on. You will need to increase the tokens if the username is in column 3 or greater.
Thanks Brent!
Well-Known Security Identifiers (SIDs)
First off, here's how a SID breaks down:
Example: S-1-5-21-1674060341-653213906-1520766640-1984
The first character is always an S. It identifies it as a SID
The first number is the SID revision level.
The second number identifies the authority (5 is NT authority)
The third of set of numbers is the domain or local computer identifier
(in this case: 21-1674060341-653213906-1520766640)
The final number (after the last hyphen) is the RID (Registered ID). Any RID that is 1000 or higher is part of a SID generated by the domain's RID Master. RIDs less than 1000 are built-in or created by default and reserved (for example, 500 on the end is reserved for the Administrator account). In the above example, 1984 refers to a created user object's SID.
| SID: S-1-5-domain-501 Name: Guest Description: A user account for people who do not have individual accounts. This user account does not require a password. By default, the Guest account is disabled. | ||
| SID: S-1-5-domain-512 Name: Domain Admins Description: A global group whose members are authorized to administer the domain. By default, the Domain Admins group is a member of the Administrators group on all computers that have joined a domain, including the domain controllers. Domain Admins is the default owner of any object that is created by any member of the group. | ||
SID: S-1-5-domain-513 Name: Domain Users Description: A global group that, by default, includes all user accounts in a domain. When you create a user account in a domain, it is added to this group by default. | ||
SID: S-1-5-domain-514 Name: Domain Guests Description: A global group that, by default, has only one member, the domain's built-in Guest account. | ||
SID: S-1-5-domain-515 Name: Domain Computers Description: A global group that includes all clients and servers that have joined the domain. | ||
SID: S-1-5-domain-516 Name: Domain Controllers Description: A global group that includes all domain controllers in the domain. New domain controllers are added to this group by default. | ||
| SID: S-1-5-root domain-518 Name: Schema Admins Description: A universal group in a native-mode domain; a global group in a mixed-mode domain. The group is authorized to make schema changes in Active Directory. By default, the only member of the group is the Administrator account for the forest root domain. | ||
SID: S-1-5-root domain-519 Name: Enterprise Admins Description: A universal group in a native-mode domain; a global group in a mixed-mode domain. The group is authorized to make forest-wide changes in Active Directory, such as adding child domains. By default, the only member of the group is the Administrator account for the forest root domain. | ||
| SID: S-1-5-32-544 Name: Administrators Description: A built-in group. After the initial installation of the operating system, the only member of the group is the Administrator account. When a computer joins a domain, the Domain Admins group is added to the Administrators group. When a server becomes a domain controller, the Enterprise Admins group also is added to the Administrators group. | ||
SID: S-1-5-32-545 Name: Users Description: A built-in group. After the initial installation of the operating system, the only member is the Authenticated Users group. When a computer joins a domain, the Domain Users group is added to the Users group on the computer. | ||
SID: S-1-5-32-546 Name: Guests Description: A built-in group. By default, the only member is the Guest account. The Guests group allows occasional or one-time users to log on with limited privileges to a computer's built-in Guest account. |
Well-known security identifiers in Windows operating systems
ADMT UPN Issue when Merging Objects (zero appended)
This happens in ADMT where target accounts, after merged with a source account, are randomly getting a zero appended to their UPN. If you fix the UPNs (using ADSIEdit, ADExplorer, or ADModify) and re-migrate the same batch of users, it will happen again, but to a different, random set of users. A workaround is using ADModify to query for (userprincipalname=*0@domain.com) …then reset their upns to samaccountname@domain.com. It’s a pain to run ADModify after every batch of users however, not to mention keeping track of any accounts to exclude (i.e., Student10@domain.com might accidentally get changed to Student1@domain.com).
This question was raised to the ADMT PM for Microsoft, and his comments were:
It happens when:
- there is an existing account in the Target domain with same UPN
- an include file is used to specify SourceName and TargetName values and these values are different
To fix it the best practice is to specify SourceName, TargetRDN, TargetSAM and TargetUPN in Include file.
We will be updating existing documentation to cover this better shortly for ADMT v3.1.
Sample SIDMapping file for ADMT
sample sidmapping.txt file (cut and paste into Word, Notepad, etc to see the ends of lines trailing off the page):
S-1-5-21-1674060341-653213906-1520766640-1984,S-1-5-21-219123761-1972038647-3338400271-28241
S-1-5-21-1674060341-653213906-1520766640-5114,S-1-5-21-219123761-1972038647-3338400271-28241
S-1-5-21-602162358-299502267-839522115-2502,S-1-5-21-219123761-1972038647-3338400271-28241
NTDomain\janedoe,NEWCorp\janedoe1
S-1-5-21-1674060341-653213906-1520766640-2202,S-1-5-21-219123761-1972038647-3338400271-22263
S-1-5-21-1674060341-653213906-1520766640-5100,S-1-5-21-219123761-1972038647-3338400271-22263
XYZCorp\johndoe,NEWCorp\johndoe
NTdomain\jdoe,NEWCorp\johndoe
For more information on Security Identifiers (SIDs):