Migration Case Study 1
Consider each of the following five migration methodologies and identify the advantages and disadvantages of each one for the company.
A pure upgrade
An in-place upgrade would meet the needs for a Windows 2000 environment. There's no pressing need to restructure the domain arrangement in use. If the upgrade succeeds, the users could continue to use the system in the previous way. However, if the upgrade fails, serious disruption could occur to all operations in the company.
An upgrade followed by a restructure
An in-place upgrade followed by a restructure that reduces the number of domains would allow a design that better matches the requirements of the company and could reduce the loading on support staff. The users wouldn't have to change the way they access the system until the restructure. However, the failure of the upgrade would result in the same problems as a pure upgrade, and the restructure would change the users' working environment.
A restructure (or consolidation of NT domains) and then an upgrade
It might not be possible to consolidate the users before the upgrade if the domains are large. Furthermore, attempting to consolidate the domains could result in too much disruption to the user environment because the users would have to change the way that they access the system. The upgrade itself still gives a single point of failure for the migration.
A partial upgrade/partial restructure
A partial upgrade of some domains would remove the risk of an upgrade failure disrupting all operations. Domains could be upgraded in a phased way. However, this approach might not allow you to take advantage of the benefits of a complete native-mode Windows 2000 environment.
A total restructure into a pristine Windows 2000 infrastructure
The creation of a pristine environment into which the users and resources are migrated would meet the requirements of minimal interruption of service. It would also provide a phased migration of the users and resources. However, it would require substantial additional hardware and extra planning to support both the old and the new environments in parallel during the migration.
Migration Case Study 2
Consider each of the following five migration methodologies and identify advantages and disadvantages of each for this company.
A pure upgrade
There's no requirement to retain the existing domain arrangement; in fact, the company is actively seeking to reorganize its infrastructure. Therefore, an in-place upgrade isn't a good idea, except as the first phase of a migration.
An upgrade followed by a restructure
An in-place upgrade of the largest account domain followed by a restructure of the existing domains into this domain might be one solution.
A restructure (or consolidation of NT domains) and then an upgrade
The poor design of the present infrastructure means that consolidation of the existing domains prior to restructure might not be possible. Restructuring might also result in too much network traffic on WAN links between sites. It might be possible to consolidate domains on particular sites, but this might result in too much disruption to the user environment.
A partial upgrade/partial restructure
A partial upgrade of some domains followed by a restructure might be the best solution for this company. The domains at a particular site could be upgraded and consolidated by moving domain members into one of the upgraded domains.
A total restructure into a pristine Windows 2000 infrastructure
The company is creating new corporate headquarters that will require the installation of a new infrastructure. This could be the basis of the pristine environment into which users and resources in the existing domains could be migrated.
Analysis, design, testing, and production.
Depending on the size and complex nature of your migration, any phase could take the most time. For example, analysis could take substantial time because of a lack of automated resources; design, because of liaison and involvement with the many different departments, working through the various iterations of Active Directory design, and planning for as many disaster recovery eventualities as possible; testing, if any significant problems require liaison with vendors and programmers; or production, because of the size of the corporation and the sheer numbers of systems requiring the new Windows 2000 facility.
An upgrade is the replacement of the Windows NT operating system with the Windows 2000 operating system. Upgrading a server doesn't change its role within the environment, as it can still participate in Windows NT domains and security authentication when it's running Windows 2000.
A restructure is a consolidation of the Windows NT domain environment to the Windows 2000 Active Directory–based mechanisms that makes domain management simpler.
A restructure, a restructure followed by an upgrade, an upgrade, an upgrade followed by a restructure, and a partial upgrade/partial restructure.
Upgrade account domains followed by a restructure. An initial restructure into one or two Windows NT account domains wouldn't work because of the 40-MB limitation of the Windows NT Security Account Manager (SAM) database. A restructure into a pristine environment could wreak untold havoc with hundreds of users calling your help desk should anything go wrong. The safest method would be to upgrade the account domains and then restructure into a single Windows 2000 domain if that's required.
The resource domains could be either restructured and then upgraded or restructured into a pristine environment. An initial upgrade of each would take too much time and should be avoided unless there's a very good reason for it (for example, you can't physically access them for consolidation because they are geographically dispersed and lack remote access).
Consider the following list of goals and decide which are business goals, which are migration goals, and which might be mutually conflicting:
Goals 1, 2, and 5 are business goals as they relate to corporate productivity. The remaining goals 3, 4, 6, and 7 are migration goals in that they relate to specific deliverables of the migration project.
Any goal involving a set time frame or budget could conflict with others. For example, the need to improve backup provision during the upgrade might conflict with the need to maintain security of information.
Consider the following statements and decide whether they are concerned with vision or scope:
This statement is a vision of the future deployment, which sets broad aims for the project in hand. Such statements are important because they explain why the effort is being performed.
This statement sets the scope of a part of the migration process. It also mentions specific deliverables and the particular systems that will be affected.
A vision is a broad statement of a goal. A statement such as "provide the best possible service to our customers" is a vision. Scope places limits on the vision by mapping the vision to a particular scenario and creating thereby a specific goal; for example, "process customer transactions in less than 20 seconds."
This is best described as a goal. It states a desired endpoint but doesn't identify a specific deliverable. "Reduce the number of servers in use by 25 percent" is an objective that might contribute to meeting this goal.
The migration project will be undertaken to produce a number of deliverables for the organization. These are business goals. However, the team performing the migration will also set migration goals to meet during the process, for example "upgrade all servers to Windows 2000 in the first six months."
You should consider risk from the very start and monitor it throughout. You should build a risk management procedure into the project, along with other crucial issues such as testing and communication.
Identify potential showstoppers from application, security, integration, network, performance, and capacity perspectives. Other answers should include phrases like these: to test whether domain and OU infrastructures map to the actual business processes; to test group policies, logons, and discretionary access control lists (DACLs) in the new environment; to verify the amount of replication traffic to determine whether increases in bandwidth are required; and to validate hardware compatibility where noncompliant hardware exists on the desktops.
To ensure that all corporate standards for the new Windows 2000 regime also comply with the organization's security standards.
To organize training on Windows 2000 network traffic and infrastructure design; to resolve which problems will go to the help desk and which will go to the network support team.
Exercise 1: Obtaining Information Manually
The Memory tab. When upgrading, all systems need to have the minimum memory required to run the applications within your organization.
Specialized services might be installed on the system that will need to be duplicated in the migrated environment. Some examples of these include security devices, Microsoft BackOffice applications, and antivirus programs.
A .txt file named after the computer; in this case, Migkit1.txt.
Hardware information, running services, running devices, and a network report.
Type Winmsd \\computername /f to create a file called computername.txt. You'll need to have sufficient privileges on the other system to do this.
Automate the previous process by copying the files from their location on the various hard disks to a centralized repository on the network. You could then write a Microsoft Visual Basic application that would collect all the information and write it to a central database.
If your servers are numbered consecutively and you have an account that has administrative privileges to all servers, you can write a batch file using the For In Do loop to collect this information about all systems in your environment. For example, the following command would collect information about server1, server2, server3, and server4:
For %n in (1 2 3 4) do winmsd \\server%n /f
The LuxSonor DVD decoder card (LS242)
McAfee Virus Scheduler
Microsoft Outlook and Microsoft Internet Explorer 5.5
Exercise 1: Using the NET Command to Analyze a Server's Security
A list of all users in your SAM database, information about the administrator and guest accounts, a list of shares on your system, and who can access the Netlogon share.
Information about local groups, global groups, logon scripts, profiles, and home folders is listed.
The Guest account should be one of them.
Such assessment can provide details of hardware or applications that could potentially slow the migration. Without the assessment, you might jeopardize your company's day-to-day running of the business, if you find in the middle of a migration that Windows 2000 suddenly cannot work with proprietary hardware or a strategic line-of-business application.
Taking inventory can be automated using scripts along with utilities such as Windows NT Diagnostics (WinMSD), and by creating a list of all files with the extension .exe, .com, and, in some cases, .dll files. These files can then be matched against an in-house database.
b, f, d, a, e, c, g
Discretionary access control lists
User accounts and groups
Third-party security devices
Delegation of management
Use of certificates within the new environment
Potential security loopholes in the middle of the migration
Mapping current security policy to Windows 2000 group policies
Reliable, skilled personnel
To use the Dhcpcmd command-line utility
dhcpcmd 192.168.0.100 serverconfig dhcpcmd 192.168.0.100 mibcounts
What results did you get?
The serverconfig parameter returns the current DHCP server parameters and the mibcounts parameter returns the current DHCP server statistics.
It numbers each DHCP client and lists its Assigned IP Address, NetBIOS name, and network interface card (NIC) media access control (MAC) address.
The same client information as before in a more textual format, plus the expiration dates for the lease, and which DHCP server (Owner host IP Address) owns the lease.
a. Whether to restructure domains into OUs
b. Whether authentication services will be available during migration (in other words, the ability to obtain an IP address, resolve host names, and run a logon script)
c. Where site boundaries are likely to be implemented
d. Whether extra traffic will be caused during and after the migration, and whether this will impact network performance
d. How to subnet TCP/IP for optimal network performance
e. How to migrate services such as RRAS and directory replication
Logon authentication, logoff for profile uploading, machine registration for WINS and DHCP, and application traffic such as database, line-of-business access, and e-mail.
Windows 2000 Active Directory depends on DNS. You need to ensure that your existing DNS servers can support Windows 2000, or you'll have to migrate them to Windows 2000 DNS.
RRAS servers: Consider the number of connections supported, dial-in protocols used, whether users are able to see the entire network or just the server, which users have dial-in access, user security settings, whether dial-in clients are assigned an IP address dynamically, and, if so, whether the IP address comes from a reserved list or whether it is DHCP-assigned. Consider such security settings as type of authentication, specified callback telephone numbers, third-party security, and multiserial port devices (such as Digiboards) that might require further testing under Windows 2000. Ascertain whether RAS or RRAS services are located on a domain controller.
DHCP servers: Consider IP address ranges, subnet masks, and excluded addresses. Review all DHCP options, including the DHCP Server name, gateway addresses, DNS servers, WINS servers, node types, and whether IP conflict detection is enabled.
DNS servers: Examine BIND files containing all the zone information details, DNS Server IP address details, and the DNS server computer name.
If no updates are occurring to the files in the export folder. For example, if you're only replicating logon scripts that are unlikely to be changed for the foreseeable future.
To do this, you might need to relax the Windows 2000 Active Directory security to allow the Everyone group network access. The Everyone group also includes anonymous users who could potentially try to dial in during a migration.
In general, you should aim to migrate the account domains first followed by either the Exchange or Web Access domain, and finally, the resource domains.
Because the two domains were previously separate, there could be duplicate user and group names when the domains are combined.
The figure below shows some structures you might have thought of—each has its own advantages and disadvantages. However, wherever possible, you should try to reduce the number of domains.
The first domain you upgrade will become the forest root, so you need to carefully consider which one to upgrade first.
All the domain trust relationships will become two-way transitive trusts. This essentially means that anyone can be authenticated anywhere. If you don't want this to happen for security reasons, you'll need to design a security policy that will limit where users can log on as part of your migration plan. The alternative would be to have two separate forests.
|In-Place Upgrade|| || |
|Parallel, pristine restructure|| |
Where are the domains located? This information will tell you whether slow WAN links are involved.
How fast are the links across the LAN and (if one exists) the WAN? This information is important for assessing domain replication traffic—it might be more efficient to have separate domains across a slow WAN link than congesting the link with the domain replication traffic involved in maintaining a single domain.
What sort of OU structure is required? OU information will determine whether you can migrate a domain into an OU.
What sort of security is required? Security requirements are important in determining group policy objects, domain boundaries, enabling of Encrypting File System (EFS), IPSec, certificate services, biometric devices, DHCP integration into Active Directory, etc.—see Chapter 3, Lesson 3, "Security Assessment," for more information.
How many corporate subsidiaries will want to control the contents of the Active Directory schema? This information determines whether you'll need a forest for each subsidiary.
Company One Migration Goals
No. The number of domains in the installation hasn't been reduced, so the number of domain controllers is unlikely to be reduced.
Yes. Assuming that the upgrades proceed satisfactorily, all user names, passwords, and resources will remain intact. Users won't have to change their practices after migration.
Yes. Assuming that the systems in place are able to support Windows 2000, the hardware requirements will be minimal, although as a precaution, it would be advisable to purchase an extra server which will act as a backup domain controller. Once installed and fully synchronized with the PDC, take it offline while the upgrade is proceeding. If anything goes wrong and clients can no longer log on, the BDC will be a useful fallback device. However, once each domain is upgraded successfully, this spare BDC can be rebuilt and reused in other domains being migrated.
Yes. The two-way and transitive nature of Windows 2000 trusts makes it possible for users to be authenticated in any domain.
Yes. Further geographical regions can be added as OUs into the existing domains or as new domains in the tree, below the account domain.
The Accounts domain should be upgraded first because it contains the user accounts and will be required by each of the migrated resource domains. It will also serve as the root of the Company One namespace.
Any of the resource domains can be upgraded next, in any order. It's advisable to start with the smallest one, especially if it's the most geographically convenient, which might be a resource domain whose servers are located physically next to the servers and PDC of the Accounts domain. Once this resource domain upgrades successfully, you can move on to the larger or more distant ones.
If upgrading the PDC in the account domain fails, this will impact the authentication of resource access and also the ability to manage the system. A spare BDC should be synchronized with the PDC and all policies, profiles, and logon scripts copied into the appropriate folders of the spare BDC. Once completed, the BDC should be shut down or disconnected from the network so that it can be brought online quickly and promoted to the PDC if problems arise. You should also follow this practice for any resource domains going through an in-place upgrade.
Yes, potentially. The number of domains has been reduced to one, which should reduce the number of servers required. For example, four PDCs are no longer required and can be replaced with a single domain controller, assuming the appropriate number of domain controllers exist for the number of BDCs that used to exist in the original NT environment.
Yes. Because both the Windows NT and the Windows 2000 infrastructures will be running in parallel, there will be minimal impact on the provision of IT services during the migration.
No. If the migration is performed by the creation of a parallel, pristine environment, extra server and network hardware will be needed to support the migration for as long as both environments are operating in parallel.
Yes. This is even simpler than an upgrade design because no trust relationships are involved.
Yes. New OUs can be created to delegate management of new divisions, and new domains can be created if further security boundaries are required.
Some questions you might come up with include the following:
Can the company afford new hardware? If not, it will be impossible to implement a pristine environment and an upgrade might be the only option.
Will the network connections between sites be working at capacity? If so, you should look at ways to reduce traffic, such as removing WINS, examining the affordability of higher bandwidth cabling, or creating separate domains.
What's the cost and speed of site connections in use? A change in the pattern of replication between sites during and after an upgrade might alter the traffic patterns between them.
Do you want to have both centralized and decentralized control of users? If so, take this into account when designing the OU hierarchy.
Must the users be able to log on 100 percent of the time throughout the migration? If so, you should consider setting up a pristine restructure; at the least, extra BDCs should be ready if an in-place upgrade fails.
Do you want users from different geographical areas to be managed independently? If so, this might rule out the creation of a single-domain forest.
Do you want to use existing DNS names in the final environment? If so, you might not be able to create a pristine environment. You might have to perform an upgrade instead.
Are you on a tight timetable to migrate from Windows NT to Windows 2000? If so, your only recourse might be to upgrade first and then to restructure later when time permits.
Accounts should be copied first.
Operating with a pristine environment reduces the risks to the production environment. The connection of the pristine environment to the production network is a potential source of problems that should be resolved in the pilot program. The user applications must also all be tested to ensure that they work correctly in the pristine environment.
The new management domain will be passing through all authentication requests from the new production domain. Performance can be improved by setting up shortcut trust relationships between the production domain and the resource domains, but this isn't a sensible design. The next stage should be the movement of accounts from the Production domain into the Management domain.
The DNS names reflect each of the positions in the tree. The root domain is msn.com and the subdomains are paris.msn.com, london.msn.com, newyork.msn.com, and production.msn.com. To make life easier, the root domain is normally named after the corporation and the second-level domains, if any, usually reflect a subsidiary or international operating unit.
The separate OUs for management and production would allow different administrators and group policies for each OU.
The three subdomains might have been designed because large numbers of user objects could potentially overload site links if a WAN is in place; cultural or language differences might cause conflicts if every server were a part of the same domain; or the IT administrators of each domain might need complete autonomy of resource assignment that can't be overridden by someone higher up in an OU tree structure.
Any attempt by an account in the production.msn.com domain to access resources in the newyork.msn.com domain will result in a referral to the msn.com domain that will then pass through the request. In this situation, Company Two could consider using shortcut trusts that mirror the trust relationships in the original domains. However, it is not a good idea to create a new design and then add shortcut trusts as a way of making it work.
Advantages of having separate forests include these:
Disadvantages of having separate forests include these:
A one-way trust from a Windows NT domain to a Windows 2000 domain
A two-way transitive trust between two Windows 2000 domains
An explicit trust from a Windows 2000 domain to another Windows 2000 domain. This could be used to speed up resource access by connecting two separate forests or by connecting two domains in different trees of the same forest.
Built-in, Computers, Domain Controllers, Foreign Security Principals, and Users
An in-place upgrade
Which domain should be the root domain?
Is the desired root domain an account domain or a resource domain?
Which domain contains the most accounts (or resources)?
Which domain will cause the least problems if it's migrated first?
Which domains have easy physical access?
If there were dependencies with distributed applications in a previously migrated account domain that a resource domain is dependent on, then the resource domain will need to be migrated before other accounts domains can be migrated. For example, if a critical application running on a resource domain is dependent on an account domain A, which has just been migrated, then the resource domain will need to be migrated prior to migrating account domain B.
Separate global catalogs provide for creating different schemas and replicated attributes, and two forests separate security boundaries and enterprise administrators.
The promotion fails. The Netlogon service will not start on the Windows 2000 server. Once the PDC in a Windows NT domain has been promoted to Windows 2000, it's not possible to promote a BDC to a PDC while the Windows 2000 domain controller is connected.
The logon script will not be replicated. Even when you've waited long enough for a replication to complete, the logon script will not appear on the BDC. Windows NT file replication is stopped when the PDC is upgraded and must be performed manually on Windows NT servers remaining in the Windows NT domain. It's not possible to configure replication on the PDC because the Windows NT Directory Replicator Service is no longer running. The Lbridge.cmd file discussed in the next lesson can be used to perform this replication from a Windows 2000 domain controller to a Windows NT system.
No. The Windows 2000 upgrade preserves Windows NT profiles. (See Chapter 7, Lesson 1, "User Profiles in an Upgrade, " for further details.)
An upgrade is simpler to perform, requires fewer resources, requires fewer changes to the objects in the namespace, and is appropriate when you are fundamentally satisfied with the design of your Windows NT domain.
An upgrade preserves application settings, security permissions on files and folders, shares and permissions on the shares, trust relationships, user names, passwords, and access tokens.
No. Although the down-level clients of Windows NT can use the NetBEUI protocol for authentication, the servers in the Windows 2000 domain, including Windows NT servers in a mixed-mode environment, must use TCP/IP to communicate.
The following are among the problems that could occur: the failure of an upgrade because of motherboard or BIOS incompatibility, the failure of network card driver software that makes it impossible for the system to contact other systems and join a domain, insufficient disk space on a volume to allow Active Directory logs and indexes to be installed, lack of an NTFS volume required for the Active Directory components, or an incorrectly configured or missing TCP/IP protocol.
A clean install of Windows 2000 is placed in a different folder from the existing Windows NT installation and is in no way related to the currently installed Windows NT system. After a clean install of Windows 2000, it's possible to shut the system down and restart it in the previous version of Windows NT. This dual-boot capability might be required for help desk workstations when supporting a mixed environment. It can also be used to prove that the server system is capable of supporting Windows 2000 and that all the drivers are available while retaining the ability to return to the Windows NT environment.
Lbridge.cmd is a script file that's used to copy a set of files (usually logon scripts) from one replication topology to another. It might be needed because after a server has been upgraded to Windows 2000, it no longer provides the Windows NT Directory Replicator Service. Lbridge.cmd employs the Xcopy command (or alternately, the Robocopy command) to copy the requisite files. The script can be scheduled to run on a Windows 2000 server or a Windows NT server. Another alternative is to run the script manually to copy the updated files into the export folder of a Windows NT export server or a Windows 2000 FRS topology. A custom version of the Lbridge.cmd script must be created for each upgrade situation. A better practice might be to suspend all file replication until the entire network has been migrated, if the business environment can endure such a moratorium.
No. The Windows NT system has not been configured for Active Desktop nor does it contain the solar eclipse background.
The Windows NT desktop bitmap is not available on Windows 2000, and the Windows 2000 Solar Eclipse bitmap is not available on Windows NT.
To create a group policy object on MIGKIT1
The Run command and the Background tab are unavailable. The Ntconfig.pol settings have now been tattooed into the user's Ntuser.dat file, even though no Ntconfig.pol file exists on the Windows 2000 system.
There is either a profile or policies problem. The user probably experiences this problem when being validated by a Windows 2000 client, as it might not have the bitmap that's used when she is logging on via a Windows NT system. If it's a policy problem, maybe replication of the Ntconfig.pol file has not been set up between the Windows NT and Windows 2000 domain controllers. You'll need to ask the user for more information or ask her to cope with the situation until the migration has completed. Ask her to get back to you if she finds further problems.
When the client system is authenticated by a Windows 2000 domain controller, the GPOs are used because the Windows 2000 workstation will locate a Windows 2000 domain controller in the mixed environment. When the client is authenticated by a Windows NT domain controller, only the Windows NT system policies are used; therefore the user will not see any of his Windows 2000 settings as no GPOs will be applied. One solution is to migrate the user name from the Windows NT domain to the domain that is in the middle of being migrated.
The problem of leaving Windows NT domain controllers in a mixed-mode environment is a bit of a red herring. In general, Windows NT domain controllers don't validate Windows 2000 clients because in theory, Windows 2000 computers will look for Windows 2000 domain controllers in preference to Windows NT domain controllers. However, in practice, this behavior depends on factors such as the location of the domain controllers (for example, are they placed across slow WAN links? How heavily are the Windows 2000 controllers being used? How much traffic is there at the controllers?).
Mixed Windows NT and Windows 2000 clients validated by Windows NT domain controllers; mixed clients validated by Windows 2000 domain controllers; mixed clients in a Windows NT domain validated by Windows 2000 trusted domain controllers; and mixed clients in a Windows 2000 domain validated by trusted Windows NT domain controllers.
A member server doesn't take part in Active Directory management. It simply provides resources to users. A member server can be promoted to a domain controller by the use of the DCPROMO tool. Unlike Windows NT, domain controllers can also be demoted to member servers, without requiring a reinstallation.
You can't do this conversion. The conversion from mixed to native mode is one way. The only way to return to mixed mode is to restore the mixed-mode domain from backup media.
The closed set would consist of the following users: BenW, RobM, RimaC, and WayneS, together with the following groups: Authors, Consultants, Developers, and Press.
The closed set was worked out as follows:
BenW is a member of the Consultants and Press groups, so check these groups for other members.
The Press group also contains RobM, so check for all other groups to which RobM belongs.
RobM is also contained in the Authors group, so check for all other users in the Authors group.
RimaC is also contained in the Authors group, so check for all other groups to which RimaC belongs.
RimaC also belongs to the Developers group, so check for all other users in the Developers group.
WayneS is a member of the Developers group.
Three. The closed sets are (1) NathanB and the Finance group, (2) JessicaR and MaryM and the Marketing group, and (3) the closed set listed in the answer to Question 1.
NathanB and Finance
The set in Question 1
There would be only one closed set, which would contain every user and group listed in consultancy.trainkit.microsoft.com.
You would restructure when you can't afford to jeopardize your production environment, when your current Windows NT environment is badly designed, and when you want to consolidate domains and groups after an upgrade.
The smallest accounts domain. In an inter-forest restructure, many user accounts will lose their passwords (unless you use a third-party utility), so you might want to validate the effect of this change on your help desk. In an intra-forest restructure, you can move only closed sets. In many cases, the smallest closed set is the entire domain, which might frustrate users if anything goes wrong because the intra-forest restructure also deletes the source objects.
In an upgrade migration, the user's original SIDs are retained because there is no re-creation of the user and group objects during the upgrade.
An inter-forest restructure
Sorry, you can't do this. The only way to migrate local groups on a member server or on a workstation is to make the member server or work-station a member of the new domain. You can do this manually or with one of the migration utilities, such as Netdom or ADMT. Remember that a local group on a member server or workstation can work only within the confines of that server.
All trust relationships maintained by the source domain will need to be duplicated in the destination domain or else any user or global group from a trusted domain contained in the local groups will no longer have access to the resources on those servers.
The smallest number of objects possible for a closed set is one—an empty global group or a user that doesn't belong to any groups. The largest number possible would be the entire set of users and global groups in the domain.
To verify the DNS service
ls trainkit.microsoft.com ls _t SRV trainkit.microsoft.com
Notice the global catalog (gc) alias in the first command's listing.
What is the difference between these two commands?
The first command lists all the hosts in trainkit.microsoft.com whereas the second command lists all the special srv records required for Active Directory support in DNS.
You will need to plan for DNS in your production environment and your pristine environment. If there are any conflicts or missing entries, you will find resource access problems because client systems might not be able to locate the servers and domain controllers.
ClonePrincipal and ADMT.
The DWORD value TcpipClientSupport should be added to Hkey_Local_Machine\System\CurrentControlSet\Control\LSA, and the value should be set to 1.
Back up the objects that are about to be moved because Movetree will delete them permanently from the source domain. If the closed set is the entire domain, you should make an image file backup of the server before using Movetree. You should also back up the destination environment in case you need to roll back the destination environment prior to the move operation; otherwise, the destination will contain all the users from the first Movetree operation and could cause potential problems if another Movetree operation is attempted using the recovered domain.
No, the Mig1 user only has permission to set the passwords of these users.
SID values from the source domain won't have any meaning in the destination domain, and the owner of resources shown on the DACLs might be construed as an unknown user. Management of the resources then becomes difficult because the administrator won't know whether these resources are required. However, it won't affect access to resources because the SID values will appear in SIDhistory entries on security principals in the destination domain.
Once all resources have been migrated over, the SIDhistory property will become redundant. SIDhistory increases the size of the access token produced when a user logs on. In extreme situations, where the number of SID entries on an access token exceeds 1,024, a user might be prevented from logging on to the system.
If a quota is set on a volume, users with no specifically allocated quota will be unable to store more files than the specified quota size. If a user exceeds the disk quota when saving profile information during a logout, he or she will be unable to log on again. This problem might result in damage to the user's profile, which will then need to be replaced or rebuilt.
There's no need for a new domain. Benw can be given the ability to create and manage users by creating an OU and delegating control of the OU to him.
A snap-in is a component tool that can be loaded into Microsoft Management Console. It manages a particular part of the Windows 2000 system. For example, the Active Directory Sites And Services and Active Directory Users And Computers tools are both snap-ins. The name is derived from the way that you can "snap-in" any of the components to an MMC framework. Once a snap-in has been added, you can create a specific view with the tool and then save the MMC configuration as a custom tool. The snap-ins themselves can be protected by policy settings to prevent unauthorized use.
Either the system will fail to log you on (telling you there's a time difference between the client and the server), or it will log you on and show you a message that your password is about to expire (because the date has now been advanced one month).
If you were MIG1, what would you need to do to troubleshoot this problem?
In this case, waiting would be enough because in time, the client would synchronize its clock with the server once more. However, you can also log on as Administrator and use the W32tm command or the Net utility to reset the date and time. If those don't help, the simplest solution is to restart the user's Windows 2000 workstation, which will force an immediate time resynchronization.
The DHCP servers haven't been authorized in Active Directory.
First, determine whether the application is on the list of applications certified by Microsoft to work correctly under Windows 2000. Then test the application thoroughly. If the application doesn't work under Windows 2000, you can try running it on a Windows 9.x machine, NT workstation, or NT member server without stopping the switchover to native mode.
The subnet that the users are on isn't associated with the appropriate site. Investigate using Active Directory Sites And Services.
In switching to native mode, you caused the domain controllers to query global catalog servers for universal group memberships. One or more of the domain controllers is unable to locate a global catalog server, and this prevents users without cached credentials from logging on.
Clients won't be able to log on.
Replication won't occur.
The administrator will have problems using some of the utilities.
To help you focus on the potential areas of failure, speculate on what you think can go wrong. Using the following table as a starting point, list as many potential points of failure in the system as possible and how you might be able to resolve them.
Your answers should have identified a few of the key components listed in the table below.
|Category||Failure Point||Potential Resolution|
|Hardware||Hard disks||Use disk mirroring or disk striping with parity.|
|Hard disk controller||Use disk duplexing (where you have a separate redundant hard disk controller in the computer system).|
|Video controller, network card, RAM chips, and so on||Have spares on hand. At present, you'll need to take the server down to replace any of these parts.|
|Complete system failure||Use clustering with Windows 2000 Advanced Server or use a third-party backup server.|
|Software||Data corruption||Use virus protection and perform regular backups. There will be some downtime while the data is restored.|
|Software corruption||Perform load balancing via Dfs and clustering. If the application software doesn't support clustering, virus protection and regular back-ups will be required. There will be some downtime while the software is restored.|
|Network||Critical network cable damage||Ensure that alternative routes are available to servers by having several routes to a server.|
|Hubs, routers, and bridges||Ensure that you have enough spares and switches to switch a network over to another router or hub in the event of a failure.|
|Too much traffic generated||Some processes can generate too much traffic for your existing net-work, such as backing up servers across the network. A solution might be to have a second network card in all servers and connect the secondary card to a management hub so that all server management traffic is isolated from the production environment.|
|Network services such as DHCP, WINS, and DNS||See Lesson 3 on maintaining network services.|
|Client||Hardware or software failure||Several spare systems should be available if the help desk can't repair these problems in a timely fashion.|
|Miscellaneous||Power supply problems||Use a backup generator or uninterruptible power supply.|
|Missing key personnel because of holidays, business trips, and accidents||Be sure that two or more people in your company understand how to repair systems. If it's not possible, you might require a 24-hour on-call contract with an employee or IT management company.|
Creation of pristine environment
Migration of DNS, DHCP, or WINS services
Upgrade of PDC in a domain
Upgrade of a BDC in a site
Successful migration of users, groups, and machines prior to decommissioning source domains
It's difficult to manage a tape library holding duplicate tapes of all fallback positions of source and destination domains.
You might experience physical tape problems. (Avoid using DAT because it tends to stretch and be unreliable.)
Tapes will not recover an entire system failure. You'll need to rebuild the system, which can involve partitioning, formatting, and reinstalling the operating system prior to being able to use tape for recovery.
Additional network traffic is caused by running Windows NT Backup over the network—it's best to use service networks (in other words, a secondary network card on a different network) for this operation.
Imaging allows a complete rebuild, including partitioning and restoration of the operating system, system state data, and all applications, in much less time than restoring via a tape backup.
Imaging will enable a faster restore of business processes in the event of a failure.
Managing CDs is easier than managing backups on tape.
CD-ROM is a more robust medium than tape and isn't subject to wear and tear such as stretching.
DHCP—for IP address assignment
WINS—for name resolution to attach to resources
RRAS—for dial-in access and authentication
Domain controllers—for user and password authentication
Two possible answers include the following:
Recreate the DHCP service in the existing Windows 2000 environment prior to migrating the Windows NT DHCP service; however, don't activate the service until the DHCP service on the Windows NT system has been deactivated.
Have a secondary DHCP server running that contains a nonduplicated set of the IP addresses for the workstations on the subnet being upgraded.
Perform the migration over a holiday period. Depending on the time needed to migrate servers (you should have determined this in your test labs), consider giving employees time off.
Have a moratorium on all network services and provide for employees to work from their local systems. Employees would need to save their work in a specific folder (for example, a folder called Migration on their local hard disks), and then an automated procedure would be written to copy their data onto a file server once network services are back online.