Preparing to Migrate from XP to Windows 7 in a Domain Environment

Microsoft and many "expert" web sites have plenty of valuable information related to planning, preparing and executing an XP-to-Windows7 migration.  I am not trying to step on anyone's toes.  This is just a few quick notes that I have found useful as a "cheat-sheet" of sorts:

• Clean Up Active Directory!  Compact unnecessary OU's.  Delete unused accounts.  Fix missing attribute data (descriptions, locations, etc.).  Unlink and delete unused GPO's.
• Draw up a detailed network diagram - know the characteristics of each WAN link.  Identify hardware, subnets, firewall port settings, and so on.
• Itemize your Servers - identify each server and what applications or services it hosts.  Identify inter-server relationships (ie. identify servers which other servers rely upon, such as SQL, IIS, DFS and so on).
• Identify special purpose user accounts: services, proxies, etc.
• Read this: link
• Download WAIK for Windows 7 and get familiar with it, especially USMT 4.0 - link
• Download MAP - link - set it up to gather information to assess your "readiness" to do an upgrade.  This will help identify applications, and configurations that may be problematic or unsupported on Windows 7.
• Download Microsoft ACT 5 (Application Compatability Toolkit) - link : Setup ACT to collect application data to determine specific issues with running them on Windows 7.  ACT can also be used to build a "shim" to allow many non-Win7-compatible applications to run fine on Windows 7.
• Contact vendors for identified problematic applications.  Find out if updates or upgrades are (or will be) available to address Windows 7 compatibility.  Identify the costs, if any.
• Install at least one Windows Server 2008 R2 domain controller in your root domain.
• Verify and synchronize the upgrade plan schedule with the users' production schedule.  Don't disrupt business!!!!!
• Have a fall-back plan in case something doesn't go right during the middle of the upgrade process.  Make sure you have plenty of back-ups.
• Eliminate roaming profiles wherever possible.

Final note: If your AD topology is a ****ing mess, and has a complicated entanglement of OU's and GPO links and accounts in scattered locations, you may want to start fresh.  That's right: a new AD Forest and a new domain.  Why drag roach-infested luggage to the new house?

Remember that your internal domain does not have to use the same FQDN as your external-facing domain (and it really should not be the same anyway!).  So if you're external domain is "funwithfisting.com" or "drinkthebongwater.com" your internal name can be "fubar.local" or "whocares.dunno" or whatever, but it should probably be something at least marginally similar to the business/organization name to avoid confusing your users.