Migrando a Windows® Server 2003 desde Windows NT® 4.0

Migrando a Windows® Server 2003 desde Windows NT® 4.0
KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Hello and Welcome to this Microsoft TechNet session on Windows Server Migration. My name is {insert name} [Do not use the term FIELDCONTENT] SLIDE TRANSITION: Howard González Technology Solutions Professional Microsoft Region Andina

Lo que Cubriremos Planeando la migración Preparando la migración
Migrando usuarios, computadores, bosques, etc. en Directorio Activo Efectos de la migración KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: SLIDE TRANSITION:

Prerequisitos Conocimiento general de la familia Windows Server Conocimiento básico de Directorio Activo y Políticas de Grupo Conocimiento de fundamentos de SQL Server Entendimiento básico de DNS KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: SLIDE TRANSITION: Nivel 200

Agenda Planeando la migración Preparando la migración
Proceso de migración Actualización (Upgrade) y Re-estructuración Resultados y efectos de la migración KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: SLIDE TRANSITION:

Identificar el dominio actual Windows NT 4.0
Modelo actual de dominios Relaciones de confianza existentes Número y ubicación de los controladores de dominio en la red existente Cuentas de usuario, grupo y computadores existentes Cómo se administran los perfiles de usuario Administración del dominio actual Procedimientos y estándares de seguridad KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Identifying the current Windows NT 4.0–based domain structure helps you to define the starting point for the migration. Identifying the domain structure also allows an organization to evaluate the efficiencies in and effectiveness of the current model in meeting the present business needs. Guidelines Use these guidelines to identify the Windows NT 4.0 domain environment: Identify the current domain model. Preparing a detailed domain diagram of an existing Windows NT 4.0 domain is the first step of the documentation process. This diagram should include the domain name, server names, and the number of domain controllers. It is also important to include the domains that exist in the lab or on separate network segments and document the relationship of each domain to the environment. When migrating existing domains to Windows Server, the existing domain structure will influence the selection of the migration path for Windows Server. It may also pinpoint unnecessary complexities or inefficient domains that were created for an obsolete purpose or function. Identify the existing trust relationships. Identify the existing one-way and two-way trust relationships in the network. Identify domains and trust relationships that you do not want to move to the Windows Server forest. Domains that are upgraded to Windows Server domains and designated as part of the same forest will connect to other Windows Server domains through transitive trust relationships. If you upgrade the domains to Windows Server, you must create explicit trust relationships between Windows Server domains and domains running earlier versions of Windows that are not moved into the new forest as necessary. Identify the number and location of domain controllers on the existing network. Determining the number and location of domain controllers on the network allows you to plan the migration for each domain. Identify primary domain controllers (PDCs) and backup domain controllers (BDCs) on network diagrams. Record their geographic locations and configuration details. Identify the existing user, group, and computer accounts. Identify the domain location of user, group, and computer accounts. The number and distribution of accounts may also affect the migration path that you ultimately choose. Record key account properties, such as group account membership, permissions to shares, and special rights assignments. This information will be used during the pilot migration to validate the migration plan. The information can also be used to determine whether any accounts in the organization are no longer in use so that obsolete and inaccurate data does not get migrated into the new environment. Identify how user profiles are managed. Determine whether the organization uses local user profiles, which are stored on the local workstation, or roaming user profiles, which are stored on a shared folder and available to users throughout the organization. The profiles must be updated to be accessible to the migrated user accounts, and this process depends on the type of profiles in use. Identify the existing domain administration. Gather the membership information for the domain administrators group. This is crucial because you will need to know who will be able to administer the domain during the migration process. It also helps you prevent domain administrators from inheriting (by using delegated administration in Windows Server) more access to the upgraded or target domain than you intend them to have. Some IT organizations strictly control all administrative functions. Others may centralize security assignments but allow for decentralized day-to-day user administration. Examining and documenting the domain administration culture reveals the type of, and reasons for, existing administrative traditions and may expose security gaps, outdated policies, or redundancies. Identify security standards and procedures. Review the security standards and procedures for mobile and desktop users, internal and external networks, and dial-up and remote access accounts. Determine whether a centralized group or several groups perform the administrative tasks, such as creating user accounts, group accounts, and file shares; changing passwords; and configuring device and object attributes. Then, document: The specific rights and membership lists of the group accounts. The types of relationships that currently exist among office locations, business units, and divisions in the organization. Any existing user and organization security policies. Identify what types of information are available to which group accounts and any significant restrictions required for certain types of information, such as accounting data. Any guidelines that exist regarding appropriate network usage. For example, document whether the IT staff has access to the directory data maintained by the Human Resource (HR) department and for what purposes and define what constitutes prohibited or inappropriate access. The relationships that the organization has with outside vendors, customers, and joint-venture or business partners will also affect the security measures in the migration strategy. SLIDE TRANSITION:

Determinando un camino de migración del dominio
Upgrade del dominio Evaluar las decsiones del upgrade Evaluar las decisiones de re-estructura Posibles vías de migración del dominio KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: When designing a migration deployment plan you must select an appropriate migration path to Windows Server and Active Directory for each domain in the organization. When selecting a migration path that meets the organizational or business needs, it is important that you carefully compare the migration goals to the characteristics of each migration path. The path that you choose for each domain affects the remainder of migration planning. How to determine a migration path When determining a migration path to Windows Server and Active Directory, you must: Identify possible migration paths. Identify the ways in which you can accomplish migration to Windows Server and Active Directory and then carefully compare the migration goals to the capabilities of each migration path to select a path that meets the needs of the organization. Evaluate upgrade decision points. Examine the criteria for selecting the upgrade migration path and the reasons for choosing this migration path. Evaluate restructure decision points. Examine the criteria for selecting the restructure migration path and the reasons for choosing this migration path. Evaluate upgrade and restructure decision points. Examine the criteria for selecting to upgrade some domains and restructuring the remaining domains and examine the reasons for choosing this migration path. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER: Re-estructurar el dominio Evaluar las decisiones de upgrade y re-estructura Upgrade y Re-estructura

Criterios para seleccionar una vía de migración
Estructura del dominio Tolerancia de caídas del servicio Tolerancia de riesgos Limites de tiempo Disponibilidad de recursos Compatibilidad de aplicaciones Limites de presupuesto ? Upgrade del dominio ? Re-estructura del dominio KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction Which domain migration path you choose depends on the business and migration goals of the organization, the existing network environment, and the Active Directory design. To determine which migration path is appropriate for a specific domain in an organization, evaluate existing domains against the seven common criteria for selecting a domain migration path. Migration path selection criteria The following criteria are typically used for selecting one of the migration paths: Domain structure. The similarity between the existing Windows NT 4.0 domain model and the proposed Active Directory domain model. Downtime tolerance. The impact of the directory services migration on the production environment and the organization’s ability to withstand network downtime. Risk tolerance. The overall risk tolerance of the organization with regard to the directory services migration. Specifically, this criterion determines the organization’s acceptance of risk to the production environment in relation to achieving a particular migration goal, such as speed or budget. Time constraints. This can include a relative preference for a quick or lengthy migration plan in addition to the timeline on which the organization must complete the directory services migration. Resource availability. The resources, including personnel, facilities, and hardware resources, that the organization has available for the directory services migration. The level of server hardware in the organization affects how much new hardware must be purchased to complete the migration. Application compatibility. The requirement for the maintenance of any server-based applications in the organization that are not compatible with Windows Server. This will affect whether the organization can complete the directory services migration immediately or whether the organization must wait until a compatible application becomes available or can be developed. Budget constraints. Every organization will likely have budget constraints on its migration project. Often the budget considerations will affect other migration path selection criteria. For example, increasing or decreasing the budget can affect the timeline and resource availability. Why prioritize migration goals? If an organization does not clearly meet the criteria for a specific migration path, then the organization must prioritize its migration goals against the criteria that are used for selecting a migration path. The prioritization of migration goals will be unique to the organization. To increase the probability of migration success and to mitigate risk, the organization must prioritize the migration path selection criteria and select those that are most important. SLIDE TRANSITION: ? Upgrade y Re-estructura

Razones para seleccionar la vía del Upgrade
Upgrade al dominio Seleccione hacer un upgrade cuando La estructura de dominio existente es similar a la estructura propuesta para el Directorio Activo La estructura de dominio existente cubre las necesidades de negocio y técnicas de la organización Los nombres de dominio deben mantenerse La organización requiere la vía de migración con el menor riesgo La migración debe ser completada en el menor tiempo posible La organización tiene un número muy limitado de personas para trabajar en la migración La posibilidad de que la organización adquiera hardware adicional está limitada presupuestariamente KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction An upgrade may be the appropriate migration path for an organization depending on the application of the common domain migration path selection criteria. Compare your organization’s requirements to these specific criteria to determine if a domain upgrade is appropriate for your domain. Reasons to select an upgrade Domain upgrade is the appropriate migration path when: The existing domain structure is similar to the proposed Active Directory domain structure. An upgrade is appropriate in this situation because an upgrade does not change the domain structure and it migrates the same domain structure to the new environment. The existing domain structure meets the business and technical needs of the organization for both the existing environment and the proposed Active Directory environment. If the domain to be upgraded will become a domain in the proposed Active Directory domain structure, then the domain controller can be upgraded. The domain name or names must remain the same. When an organization cannot change its Domain Name System (DNS) or domain network basic input/output system (NetBIOS) names, then an upgrade is the only practical option. The organization requires the migration path with the lowest risk. A domain upgrade is the migration path with the lowest risk because all of the domain settings and directory services objects are preserved. The directory services migration must be completed in the least amount of time possible. The domain upgrade is the quickest migration path because the domain controller and the directory services are migrated in a single automated process. The organization has limited number of people to work on the migration. A domain upgrade requires the least amount of resources to complete. The organization’s ability to buy additional hardware is limited by budgetary constraints. As long as the existing domain controller hardware is capable of running Windows Server, then it is not necessary to purchase additional hardware for an upgrade. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Razones para seleccionar la vía de la Restructuración
Elija restructurar cuando La estructura de dominio existente no cumple con las metas de negocio y de migración de la organización La organización no puede tolerar la no disponibilidad del servicio de directorio en producción La organización puede asumir algún riesgo para obtener una estructura de dominio óptima Existe tiempo suficiente para completar las tareas adicionales que implica la restructuración Existe personal suficiente para completar las tareas de restructuración Existe dinero suficiente para adquirir hardware adicional Restructuración del Dominio KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction When an organization does not meet the selection criteria for an upgrade, then the organization must choose the restructure migration path. Compare your organization’s requirements to these specific criteria to determine if a domain restructure is appropriate for your domain. Reasons to select a restructure Domain restructure is the appropriate migration path when: The existing domain structure does not meet the business or migration goals of the organization. In this case, it is best to start with a new environment that is built to meet the Active Directory design requirements. The organization cannot tolerate any downtime to the production directory services environment. Because a domain restructure does not affect the existing environment, it enables the organization to continue working through the directory services migration process. The organization can incur some degree of risk to achieve an optimum domain structure. Due to the additional and more complex tasks involved with restructure, such as resetting permissions on shared resources, there is more risk in the migration process. Having a parallel infrastructure means that migration can be done incrementally and even reversed if required. There is enough time in the migration project schedule to complete the additional tasks involved with a restructure. Creating and populating the new Active Directory forest takes more time than performing a domain upgrade. There are enough people available to complete the restructure tasks. There must be enough people to complete the necessary task of creating the new environment and migrating the security principals to it. There is enough money in the budget to buy additional hardware. The amount of additional server hardware that is required depends on the specifications of the Active Directory design in addition to the amount of hardware that can be repurposed from the Windows NT 4.0–based environment. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Razones para seleccionar la vía de Upgrade y Restructuración
Elija hacer upgrade y restructurar cuando La estructura de dominio existente es similar a la estructura propuesta de Directorio Activo La organización quier usar ciertas características de Directorio Activo pronto debido a los beneficios que proporcionan La organización quiere reducir los costos administrativos y de hardware en el corto plazo La organización es adversa al riesgo pero no quiere mantener su modelo de dominio existente a largo plazo Upgrade y Restructura KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction Many organizations will best meet their migration goals by combining the upgrade and restructure migration paths in the form of a two-phase migration. By doing this, the organization receives the short-term benefits of the upgrade migration path, such as timeline and lower risk, but also gets the long-term restructure benefits of a new Active Directory design and an incremental approach to migrating security principals. Reasons to select upgrade and restructure Upgrade and restructure is the appropriate migration path when: The existing domain structure is similar to the proposed Active Directory domain structure. If the existing Windows NT 4.0 domain model is similar enough to the target domain model, you can consider an initial domain upgrade as an appropriate migration path. The differences that exist can be managed through a restructure after the domain upgrade is complete. The organization wants to use certain Active Directory features early because of the benefits that they provide. Your organization will benefit by first upgrading the domain to Windows Server to make available Active Directory features, including Kerberos security, Microsoft IntelliMirror® management technologies, and managed replication. Then, as the schedule allows, you can migrate the security principals within the Windows Server forest to the ultimate target domain. The organization wants to lower short-term hardware costs and administrative costs. By upgrading the domain first, you can continue to use existing server hardware, and not require additional target domain hardware. Additional hardware will be recovered and added to the target domain as the upgraded domain security principals are restructured within the forest and the upgraded domains decommissioned. The organization is risk adverse but does not want to keep its existing domain model long-term. If the organization does not want to incur the risk associated with a domain restructure, but ultimately wants to move to a new Active Directory design, then the upgrade and restructure migration path is a good option. This option provides the low risk benefit of a domain upgrade with the long-term benefit of consolidating domains. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Limpiando la base de datos SAM de Windows NT 4.0
Group1 Computer1 User1 Limpiar la base de datos SAM User1 Computer1 Computer2 KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction Before you migrate from Windows NT 4.0 to Windows Server and Active Directory, it is recommended that you clean up the SAM database in Windows NT 4.0 so that it is well organized. Cleaning up the SAM database means deleting, disabling, and consolidating unnecessary user accounts, group accounts, or computer accounts. Why clean up the SAM database? The purpose of cleaning up the SAM database is to remove any irrelevant security principals that may have accumulated in the SAM database—this provides you with an opportunity to migrate only relevant data to the new environment. Cleaning up the SAM database is especially helpful in the restructure scenario, in which you are moving security principals into a new environment. Note Cleaning up the SAM database is an important best practice in a Windows NT 4.0–based environment where there is a recommended limit of 40,000 objects in the SAM database. If you do not clean up the SAM database, you can still successfully upgrade or restructure a Windows NT 4.0 domain. However, then you will have a Windows Server domain with a lot of unnecessary data in it. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER: Group1 User1 Group2

Consideraciones para limpiar la base de datos SAM
Cuentas de usuario que pueden ser eliminadas Cuentas de usuario duplicadas Cuentas de usuario no utilizadas Cuentas de grupo no utilizadas Cuentas de grupo para recursos que ya no existen Cuentas de computador no utilizadas Cuentas de usuario que pueden ser deshabilitadas Cuentas de usuario que no hayan sido usadas por un amplio período Cuentas de usuario que tengan derechos, permisos y membresías de grupo que deben ser retenidas Cuentas de usuario que sean dueñas de recursos de red importantes Cuentas de grupo que cumplan la misma función pueden ser consolidadas KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction Before you can delete unnecessary user accounts, group accounts, and computer accounts, you must first identify unnecessary accounts and then decide whether to delete, disable, or consolidate these accounts. There are several considerations to remember when identifying such accounts. Which accounts to delete? Consider the following factors to identify the user accounts, group accounts, and computer accounts that can be deleted before moving these accounts to the new Windows Server–based environment: Duplicate user accounts. These are multiple user accounts that were created for the same user and usually only one of them is active. Even in a multiple domain network, users only need one user account to access resources anywhere in the network, provided that the necessary trust relationships exist. If a user has a duplicate user account, one of the accounts may go unused, or a user’s permissions to resources may be associated with two user accounts and therefore more difficult to monitor. Therefore, delete one of the accounts or the one that is used less frequently. Unused user accounts. These user accounts have been inactive for a long period of time. In most instances, with good network documentation, you can easily identify inactive user accounts, such as an obsolete service account. It is more difficult if users do not use their user accounts frequently. There are tools that you can use to help you identify unused user accounts. Unused group accounts. These group accounts are no longer required because you have moved all of the members into other group accounts. You may have done this when consolidating groups. For example, if a department closed, group accounts that are associated with the department may no longer have members, but the group account could still exist. Group accounts for resources that do not exist. These group accounts were created to assign permissions to resources that no longer exist. Unused computer accounts. These computer accounts were created for computers that no longer exist or that are no longer needed. Why disable and not delete user accounts? After identifying unused user accounts, it is sometimes a best practice to disable rather than to delete the user account. You disable an unused user account for the following reasons: A user does not need a user account for an extended period but will need it again later. You want to retain all rights, permissions, and group memberships for the user account and reassign it to a different user. The user account is the owner of important network resources, and you have not yet determined who will take ownership of the resources. Which group accounts to consolidate? In addition to deleting unused group accounts, it is a best practice to consolidate group accounts. This will reduce redundancy and make administration easier. Consolidating groups involves combining the membership of group accounts that fulfill the same function and ensuring that you retain the appropriate permissions. Evaluating whether group accounts meet the criteria for consolidation is primarily a manual operation. After you identify the group accounts that meet the consolidation criteria, you must determine their actual membership and permissions. This allows you to verify that the group account really does meet the consolidation criteria. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Limpieza de cuentas de grupo
Identificar cuentas de grupo para consolidación Verificar membresía y permisos de una cuenta de grupo Consolidar cuentas de grupo Eliminar cuentas de grupo no usadas Listar todas las cuentas de grupo locales y globales Redireccionar la salida a un archivo de texto Revisar la lista de cuentas de grupo a consolidar Listar todos los miembros de una cuenta de grupo global Listar todos los miembros de una cuenta de grupo local Listar todas las DACLs que contienen permisos para una cuenta de grupo Remover los miembros de una cuenta de grupo y añadirlos a otra cuenta de grupo Copiar la lista de membresía de la cuenta de grupo Consolidar los permisos Usando User Manager for Domains Usando el comando net group y el comando net localgroup KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction Before you migrate from Windows NT 4.0 to Windows Server and Active Directory, you can either delete or consolidate group accounts. Doing this ensures that you do not migrate unnecessary group accounts. To identify group accounts for consolidation, perform the following tasks: List all of the global and local group accounts by using the net group and net local group commands. Redirect the output to a text file. Review the list of group accounts to identify group accounts that can be consolidated. You can verify membership and permissions of a group account by using User Manager for Domains. In addition to User Manager for Domains, you can also use the following commands to obtain a membership list of all global and local group accounts and all of the permissions that are associated with each group account: Use the net group group_name command to list all members of a global group account. Run the command on a domain controller. Use the net localgroup group_name command to list all members of a local group account. Run the command on a domain controller and all member servers. Use the Subinacl program (Subinacl.exe) to obtain a list of the discretionary access control lists (DACLs) that contain permissions for each group account. The Subinacl.exe program is included in the Microsoft Windows NT Server 4.0 Resource Kit. With these lists, you can determine which permissions and members you need to move between group accounts during consolidation, and you can decide whether it is important to consolidate the group accounts. To consolidate group accounts, use any of the following methods: Use User Manager or User Manager for Domains to remove members from one group account and add them to another group account. Use the Group Copy (Grpcpy.exe) program to copy the membership list of one group account to another group account. The Grpcpy.exe program is included in the Microsoft Windows NT Server 4.0 Resource Kit. Use the Subinacl program to consolidate permissions by transferring file and registry permissions that are granted to the group account that you will remove to the group account that you retain. The Subinacl program replaces all occurrences of one group account’s security identifier (SID) in all DACLs with that of another group account’s SID. To delete group accounts, use one of the following methods: User Manager for Domains. You select group accounts and then choose to delete the group accounts. The net group and net localgroup commands. You can create a batch file that uses the net group and net localgroup commands to delete multiple groups. This is especially easy if you use the group account list that you created by using net group and net localgroup. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Limpieza de Computadoras
Identificar computadoras no usadas Eliminar computadoras no usadas Observar todas las computadoras Listar todas las computadoras que no estén siendo usadas Verificar la elegibilidad para ser eliminadas Usando Server Manager Usando el comando netdom KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction To delete the computer accounts that are no longer required before moving to the new environment, you must first identify the unused computer accounts and then delete the unused computer accounts. How to identify unused computer accounts To identify computer accounts that are no longer required, perform the following tasks: View all computer accounts in Server Manager. List all computer accounts that are no longer used. If a computer is running Windows NT 4.0, and if that computer is not available on the network, its icon appears dimmed in the Server Manager window. Verify from the owners of these computer accounts whether the computer associated with the dimmed icon is only disconnected or if it is indeed no longer a part of the domain. How to delete unused computer accounts To delete unused computer accounts, use one of the following methods: Server Manager. To use Server Manager to delete computer accounts, you select the computer accounts and then choose to delete the computer accounts. The netdom command. To use this command to delete a computer account, you enter the following command at the command prompt: netdom member computername /delete SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Secuencia para Actualizar Dominios de Cuentas
Dominio de Cuentas Actualice los dominios en los cuales tenga el acceso físico más fácil a los controladores de dominio Actualice los dominios que contedrán objetos de dominios restructurados (si existen) temprano en el proceso Balancee el riesgo versus el beneficio de actualizar el dominio KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction When you are upgrading multiple account domains, you can improve the efficiency and ease of migration by carefully planning the order of the upgrade. Guidelines Use the following guidelines to choose the sequence in which you upgrade account domains: Upgrade domains in which you have the easiest physical access to the domain controllers. Although you will have tested the upgrade strategy in a lab or in a pilot test, the first live upgrade will be the riskiest because it directly impacts the production environment. To mitigate risk, you should upgrade domains in which you have the easiest physical access to the domain controllers. Upgrade the domains that will contain objects from restructured domains early in the process. If you are planning to restructure some domains, upgrade the domains that will contain objects from restructured domains early in the process. You cannot consolidate domains into a target domain that does not exist. Balance the risk versus the benefit of upgrading the domain. For the remaining domains in the organization, you should balance the risk incurred in upgrading versus the benefit the domain users and administrators will get from an upgrade. First upgrade the domains where the risk to the production environment does not outweigh the benefit. Eventually, you will perform upgrades in the most risky environments, but toward the end of the process the migration team will have the most experience. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Secuencia para actualizar dominios de recursos
Dominio de Recursos Actualice los dominios que contengan aplicaciones que requieran las características de Windows Server 2003 primero Actualice los dominios que contendrán objetos de dominios restructurados (si existen) temprano en el proceso Actualice los dominios con muchas cuentas de computadoras cliente KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction As part of the migration plan, the administrative model must reflect the implications of upgrading a resource domain. If you have already upgraded an account domain, and then you upgrade the resource domain as a child of the account domain, a transitive trust is established between account and resource domains. For this reason, you must consider how this transitive trust affects local administration of resources. Guidelines If you have more than one resource domain, use the following guidelines to help choose the sequence in which to upgrade them: Upgrade any domains that contain applications that require the features of Windows Server first. Upgrade domains in which you are deploying applications that require the infrastructure or features of Windows Server, such as the Active Directory directory service required by Microsoft Exchange 2000. Upgrade domains that will contain objects from restructured domains early in the process. Just as with account domains, if you are planning to restructure your domains, upgrade domains that will contain objects from restructured domains early. You cannot consolidate domains into a target domain that does not exist. Upgrade domains with many client computer accounts. Upgrade domains with the most client computer accounts so that you can take advantage of the computer management features in Active Directory. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Secuencia para actualizar Controladores de Dominio
Actualice primero el PDC Actualice todos los BDCs luego de actualizar el PDC (o decomisione los BDCs e instale nuevos controladores de dominio Windows Server 2003) Actualice un BDC primero si el PDC no reune las condiciones de instalación KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction In any domain upgrade, you must upgrade the primary domain controller (PDC) and all of the backup domain controllers (BDCs) to Windows Server and Active Directory. Guidelines Use the following guidelines to determine the sequence for migrating domain controllers: Upgrade the PDC first. The PDC is always the first domain controller to be upgraded to Windows Server and Active Directory. Upgrading the first PDC establishes the forest root domain. When the PDC of a child domain is upgraded to create a new domain, transitive trust relationships are automatically established to the parent domain during the Active Directory installation. Upgrade all of the BDCs after upgrading the PDC. After upgrading the PDC, upgrade Windows NT 4.0 BDCs, if necessary, to Windows Server and Active Directory. BDCs can generally be upgraded in any order, although it is important to make sure that applications running on BDCs are compatible with Windows Server. Network services that run on BDCs may also affect the decisions you make regarding the BDC upgrade sequence. You may choose to move incompatible applications to a member server so that the domain can be fully upgraded, or you may choose to not upgrade the BDC. Upgrade a BDC first if the PDC does not meet installation requirements. You may have to upgrade the BDC first if you have a PDC that does not meet the installation requirements of Windows Server or if it is not in an optimal operating condition. In such a scenario, you can select and promote a BDC that meets the installation requirements, and then upgrade it first. This demotes the original PDC. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Demostración 1 Limpiando la base de datos SAM y actualizando el PDC a Windows Server 2003
KEY MESSAGE: SLIDE BUILDS: SLIDE SCRIPT: SLIDE TRANSITION:

Las implicaciones de actualizar un PDC Windows NT 4.0
Qué ocurre durante la actualización de un PDC? El nivel de funcionalidad del dominio es Windows 2000 mixto El nivel de funcionalidad del bosque es Windows 2000 El PDC actualizado posee el rol maestro de operaciones PDC emulator El rol maestro de operaciones PDC emulator es importante porque expone la base de datos de Directorio Activo como un almacén de datos planos hacia los BDCs Windows NT 4.0 durante la replicación KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction After a Windows NT 4.0 PDC has been upgraded to Windows Server, it possesses certain default behavior. This behavior is indicated by the level of domain and forest functionality as well as by the presence of the operations master roles. What happens during a PDC upgrade? Following the upgrade of the PDC and the installation of Active Directory, the default domain functionality is Windows 2000 mixed, and the forest functionality is Windows Until the level of domain functionality is raised to Windows 2000 native or Windows Server, you cannot raise the forest functionality to Windows Server. You will want to raise the functionality as soon as possible to take advantage of all the new features in Active Directory. The newly upgraded PDC holds the operations master role of PDC emulator in the Active Directory domain. This role is important because it exposes the Active Directory database as a flat data store to Windows NT 4.0 BDCs during replication. The PDC emulator operations master role also: Appears to be a Windows Server domain controller to other computers running Windows Server. Appears to be a Windows NT 4.0 PDC to computers that are not yet upgraded. Can still be used to create new security principals and to replicate these changes to the Windows NT 4.0 BDCs. Can be used as a possible logon server by computers running Windows NT 4.0. If the Windows Server PDC emulator goes offline or otherwise becomes unavailable and no other Windows Server domain controllers exist in the domain, a Windows NT 4.0 BDC can be promoted to be the PDC. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

El efecto de un upgrade al dominio sobre las relaciones de confianza
Dominios Windows NT 4.0 Dominios Windows Server 2003 Upgrade Forest root ACCT1 ACCT2 Transitive Trust Transitive Trust ACCT1 ACCT2 KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction In Windows NT 4.0, trust between domains allows domains to authenticate users on behalf of domains that trust them. In Windows Server, trusts are, by default, two-way and transitive. As you upgrade domains to join the forest, one-way trust relationships between Windows NT 4.0 domains are automatically implemented as trusts in Windows Server. Some one-way trusts become two-way transitive trusts in the new environment. Others are redefined as shortcut trusts, depending on the order in which the domains are upgraded and the domain parent-child relationships in the Active Directory domain hierarchy. The effect of an upgrade on trusts No additional steps are required to migrate trust relationships. Each domain that is upgraded as a child domain establishes a two-way transitive trust between itself and its parent domain. Domains upgraded as roots of separate trees are also linked by a two-way transitive trust. Existing one-way trusts that do not map to default trust relationships in Windows Server are maintained but are reinterpreted as shortcut trusts. Important Shortcut trusts can be deleted; however, the default transitive trust relationships established between domains in a forest cannot be. How to protect resource security In Windows NT 4.0 domains, one-way trust relationships prevent user accounts and groups in resource domains from being added to discretionary access control lists (DACLs) for resources located in account domains. With the upgrade to Windows Server, migrated one-way trust relationships will translate to two-way trust relationships. When a Windows NT 4.0 domain model is upgraded, transitive trusts allow user accounts and groups from any domain to be recognized by any member computer in the forest and included in groups or DACLs. Although this will not affect the previous security assignments, this does allow user accounts and groups to be assigned access to resources that were not possible with just the one-way trust relationship. To prevent any security assignments from changing, you must perform the following tasks: Audit memberships in all administrative groups to ensure that new accounts have not been added to the memberships. If membership in administrative groups is maintained, this will prevent any user accounts without administrative privileges to suddenly gain these privileges. Review DACLs for important resources. Although it may be time-prohibitive to review all DACLs for all resources, by focusing on important resources for the organization, you can confirm that security has not been compromised. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER: Transitive Trust RES1 RES1

Servicio DNS confiable en el upgrade del dominio
Cómo actualizar los servicios de DNS Actualice el servidor existente corriendo en Windows NT 4.0 Instale un nuevo servidor corriendo Windows Server 2003 Actualice los servidores DNS no Microsoft Cómo minimizar el impacto de una actualización de DNS Administre DNS en Windows Server 2003 y DNS en Windows NT 4.0 con sus respectivas herramientas de administración Defina servidores maestros para servidores DNS corriendo Windows Server 2003 y servidores DNS Windows NT 4.0 Servidor DNS KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction Windows Server depends on DNS as a locator service for its client computers to find Active Directory–related services. During a domain upgrade to Windows Server, it is essential to have a DNS infrastructure in place and operating properly to provide the required support for SRV resource records. The SRV resource records are used to locate network servers that host Lightweight Directory Access Protocol (LDAP) and Kerberos authentication. The effects of a domain upgrade on DNS If you have a DNS server running Windows NT 4.0, then upgrading the primary DNS server to Windows Server, or switching the primary zone to be hosted on a server running Windows Server, gains the immediate benefit of enabling the configuration of zones to accept SRV resource record registrations and dynamic updates of resource records. DNS zones hosted on a Windows Server domain controller can also be configured as Active Directory Integrated zones. How to upgrade DNS servers If you use DNS servers running Windows NT 4.0, then the domain upgrade plan must include upgrading the DNS services in Windows NT 4.0 to DNS services in Windows Server and moving the writable copy of the DNS zone data to Windows Server. To upgrade DNS servers, perform one of the following three tasks: Upgrade the existing server running Windows NT 4.0. Upgrade the existing server running Windows NT 4.0 that contains the DNS primary zone to Windows Server, and then configure the zone to allow dynamic updates. -or- Install a new server running Windows Server. Install a new server running Windows Server and configure it as the secondary DNS server for the existing zone. After the zone transfer has taken place, reverse the roles so that the DNS server running Windows Server is the primary DNS server for the zone. The zone can then be configured to allow dynamic updates. Tip After a domain controller running the DNS service is upgraded to Windows Server, convert the DNS zone to Active Directory Integrated zone to take advantage of secure dynamic updates and multi-master writes. Update non-Microsoft DNS servers. If you use non-Microsoft DNS servers (such as a BIND server), contact your vendor to find out whether the version of DNS must be upgraded to support Active Directory. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Demostración 2 Configurando Directorio Activo para coexistir con Dominios Windows NT 4.0

Terminología de Migración
Migración de dominio Mover usuarios, grupos y cuentas de computador de un dominio Windows NT 4.0 a un dominio Windows Server 2003 Dominio origen El dominio desde el cual se están migrando los objetos de seguridad Dominio destino El dominio hacia el cual se están migrando los objetos de seguridad Dominio de cuentas Un dominio Windows NT 4.0 que contenga usuarios y grupos Dominio de recursos Un dominio Windows NT 4.0 que hospede servicios de archivos, Impresión y otros Consolidar dominios Restructurar un gran número de dominios en una menor cantidad KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Before you start to migrate directory services from Windows NT 4.0 to Windows Server, it is important that you be familiar with some migration terms and their meanings. The following bullets list terms and their meanings related to the directory services migration process: Domain migration. The process of moving the user accounts, group accounts, and computer accounts in a Windows NT 4.0 domain to a Windows Server domain. Domain migration can be achieved either by upgrading the Windows NT 4.0 domain to Windows Server or by creating a new Windows Server forest and copying the user, group, and computer accounts from the Windows NT 4.0 domain to the new forest. You can also achieve domain migration by using a combination of these two methods. Source domain. The domain from which security principals are being migrated. A source domain can be a Windows NT 4.0 domain or a Windows Server domain. Target domain. The domain into which security principals are being migrated. A target domain can be either in the same Windows Server forest or in a different Windows Server forest as the source domain. Account domain. A Windows NT 4.0 domain in the multiple master domain model that contains primarily user and group accounts. Resource domain. A Windows NT 4.0 domain that is used for hosting file, print, and other application services and that contains primarily computer accounts. Consolidate domains. To restructure a larger number of domains into a lesser number. Levels of domain and forest functionality. A feature in Windows Server that provides backward compatibility for the different Windows operating systems that use Active Directory. Windows Server uses levels of domain and forest functionality to identify the functionality that can be introduced at both the domain and forest levels. Implementing domain functionality or forest functionality enables Microsoft to introduce new features in Windows Server that do not activate until all the domain controllers in an organization can handle them, thereby providing backward compatibility. Levels of domain and forest functionality replace the Windows 2000 domain mode feature. Clone. To create new accounts in the target domain that mirror accounts in the source domain but also maintain the source account primary security identifier (SID) in their SID-History attribute. The only time that you can clone accounts is when you are migrating accounts between forests. Cloning is nondestructive; that is, it leaves the source accounts intact. SID-History. An attribute of Active Directory security principals that is used to store the former SIDs of moved objects such as user accounts and security groups. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER: Niveles funcionales Proveen compatibilidad hacia atrás para los diferentes sistemas operativos que usan Directorio Activo clonar Crear nuevas cuentas en el dominio destino equivalentes a cuentas en el dominio origen SID-History Un atributo de los objetos de seguridad en Directorio Activo que es usado para almacenar los SIDs previos de objetos movidos

Beneficios de usar Active Directory Migration Tool (ADMT)
Por qué usar ADMT? Analisis del impacto de migración tanto antes como después del proceso de migración real Prueba de los escenarios de migración antes de llevarla a cabo Soporte a migración dentro del bosque y entre bosques Provee asistentes para soportar las tareas de migración más comunes Tareas de migración soportadas por ADMT Migración de usuarios, grupos, y computadores entre dominios Traducción de seguridad sobre grupos locales, perfiles de usuario y recursos de archivo e impresión Llenado del atributo SID-History con los objetos de seguridad migrados Traducción de seguridad en las cuentas de computadoras Resolución de problemas de seguridad con archivos, directorios y shares KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: ADMT provides an easy–to-use interface for migrating directory services objects from Windows NT 4.0 to the Windows Server and Active Directory. ADMT can also be used for migrations to a Windows 2000 Active Directory environment. ADMT is included with the Windows Server Server family products, and is also available as a download from the Microsoft.com Web site. Why use ADMT?ADMT is a comprehensive utility that: Analyzes the migration impact both before and after the actual migration process. Tests migration scenarios before you perform the migration. Supports a migration from Windows NT 4.0 to Windows Server and Active Directory within a forest and between forests. Provides wizards to support the most common migration tasks. Migration tasks supported by ADMTADMT supports the following migration tasks: Migrating user, group, and computer accounts from one domain to another Performing security translation on local groups, user profiles, files and folders, and printers to update the permissions for migrated user and group accounts Populating the SID-History attribute with the SID from migrated security principals Translating security on computers and, if appropriate, removing redundant SIDs Resolving the related file, directory, and shared folder security issues for the copied accounts by redefining permissions on shared resources SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Características de ADMT
Descripción Scripting e interfaz de línea de comando Las operaciones de ADMT pueden ser ejecutadas usando una interfaz de scripts o la herramienta de línea de comando Migración de password segura Los passwords pueden ser migrados para usuarios entre bosques Archivos de mapeos SID para traducción de seguridad La traducción de seguridad está basada en un archivo separado por comas en lugar de solo el objeto migrado Exclusión de atributos para Windows 2000 La mayoría de los atributos de usuarios, grupos y computadores pueden ser excluidos de la migración si el dominio origen es Windows 2000 o superior KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: The Beta 2 version of ADMT 2.00 has six features that enable it to support several migration tasks. These features include a scripting and command-line interface, password migration, SID mapping files for security translation, attribute exclusion for Windows 2000, agent credentials, and skip membership restoration. Scripting and command-line interface You can also perform most ADMT operations by using a scriptable interface or the command-line tool ADMT.exe. The following table shows when to use a specific interface of ADMT. Use this interface when You require the flexibility to select options (such as domains, users, and groups) interactively. You know which options you want to use and want to perform repetitive operations or batch operations. You want to make migration decisions dynamically based on other sources of input like a database or other decision criteria. Note For information about using the ADMT command-line interface, see Section 4, “Restructuring Tools,” of the Domain Migration Cookbook. This cookbook is under Additional Reading on the Web page on the Student Materials compact disc. For information about the scripting interface, see the TemplateScript.vbs script file that is installed with ADMT. Secure user password migration Passwords can be migrated for user account migrations between forests. ADMT uses a password export server in the source domain to perform the password migration. SID mapping files for security translation ADMT can perform security translation based on a comma-separated file instead of just the previously migrated object. The comma-separated file is represented as “%Source Object%, %Target Object%” followed by a new line. Attribute exclusion for Windows 2000 Most user, group, and computer schema attributes can be excluded from migration if the source domain is running Windows 2000 or later. Agent credentials Agent dispatch credentials are no longer required. ADMT creates a dedicated user account in the target domain to report its results back to ADMT. This account is given default domain user rights, but not domain administrative rights. Skip membership restoration A fix membership option has been added to both the User Account Migration Wizard and the Group Account Migration Wizard so that performance can be improved if group membership reconstruction is not needed. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER: Credenciales de Agente No se requiere credenciales de agente de despacho Obviar la restauración de membresía Una opción de membresía fija ha sido agregada para mejor performance

Asistentes ADMT User Account Migration Wizard Group Account Migration Wizard Computer Migration Wizard Security Translation Wizard Reporting Wizard Service Account Migration Wizard Exchange Directory Migration Wizard Undo Last Migration Wizard Retry Task Wizard Trust Migration Wizard Group Mapping and Merging Wizard KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: ADMT provides an easy, secure, and fast way to restructure a domain from Windows NT 4.0 to the Windows Server and Active Directory. You can also use ADMT to restructure the Active Directory domains in Windows Server. When to use a specific ADMT wizard ADMT has several wizards to simplify the task of migration. This slide shows when to use a specific ADMT wizard. Use this ADMT wizard when… User Account Migration Wizard - Migrating user accounts from Windows NT 4.0 domains to Active Directory. Group Account Migration Wizard - Migrating group accounts from Windows NT 4.0 domains to Active Directory. Computer Migration Wizard - Migrating computer accounts from Windows NT 4.0 domains to Active Directory. Security Translation Wizard - Updating the access control lists for files, shared folders, and other resources previously migrated from Windows NT 4.0 domains to Active Directory. Reporting Wizard - Creating reports containing the information that you must migrate Windows NT 4.0 domains to Active Directory. Service Account Migration Wizard - Migrating service accounts from Windows NT 4.0 domains to Active Directory. Exchange Directory Migration Wizard - Migrating Microsoft Exchange directories from Windows NT 4.0 to Active Directory. Undo Last Migration Wizard - Undoing the last user, group, or computer account migration. These are the only actions that can be undone. The Undo Last Migration Wizard is not available through the scripting and command-line interfaces of ADMT. However, a non-reversible operation, performed through scripting or the command line, can still be undone by the Undo Last Migration Wizard. Retry Task Wizard - Retrying tasks that were unsuccessful during the previous migrations to Active Directory. The tasks that can be retried include: computer account migration, security translation, gathering service account information, and reporting. Trust Migration Wizard - Migrating trust information from Windows NT 4.0 domains to Active Directory. Group Mapping and Merging Wizard - Preparing Windows NT 4.0 groups for migration to Active Directory. How to test migration settings You can run many of the wizards without making any changes to the network by using the Test migration settings and migrate later option, which is available on the second page of many of the ADMT wizards. You can then review the log files and reports generated by the wizards to identify and resolve any errors before performing the actual migration. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER: Use la opción Test migration settings and migrate later para ejecutar un asistente sin realizar cambios

Otras herramientas de migración
Use ClonePrincipal para clonar cuentas de usuario y grupos en el nuevo ambiente basado enWindows Server 2003 Use MoveTree para mover objetos de Directorio Activo entre dominios en un mismo bosque Windows Server 2003 Use Netdom para Agregar, mover y consultar cuentas de computador en un dominio Windows NT 4.0 Consultar un dominio sobre información acerca de relaciones de confianza existentes Crear nuevas relaciones de confianza Use Ldp para mostrar los atributos de cualquier objeto en Directorio Activo KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: In addition to ADMT, there are other tools and utilities available from Microsoft and other third-party software vendors that you can use to upgrade and restructure domains from Windows NT 4.0 to Windows Server and Active Directory. Migration toolsThe following bullets describe the other Microsoft tools that you can use to migrate domains: ClonePrincipal. ClonePrincipal is a set of scripts that clone user accounts and groups to the new Windows Server–based environment. Clonepr.dll and Clonepr.vbs are available on the Windows Server Enterprise Server compact disc in the Support.cab file in \Support\Tools. MoveTree. MoveTree is a command-line tool that is used to help administrators move Active Directory objects, such as organizational units, user accounts, or groups between domains in a single forest. Movetree.exe and Movetree.dll are available on the Windows Server Enterprise Server compact disc in the Support.cab file in \Support\Tools. Netdom. Netdom is a command-line tool that you can use to query a domain for trust relationships and create new trust relationships automatically. You can also use it to add, move, and query computer accounts in a Windows domain. Netdom.exe is available on the Windows Server Enterprise Server compact disc in the Support.cab file in \Support\Tools. Ldp. Ldp is a graphical utility that uses Lightweight Directory Access Protocol (LDAP) to allow an administrator to display the attributes of any object in Active Directory. Ldp.exe is available on the Windows Server Enterprise Server compact disc in the Support.cab file in \Support\Tools. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Consolidando dominios en un solo dominio AD
OU Destino Dominio de Cuentas 1 Migrar el dominio de cuentas OU OU OU Origen Dominio de Recursos OU OU OU OU KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Before you begin restructuring domains, it is important to understand the process and how it affects a user’s ability to access resources. By understanding the components migrated during the process and the prerequisites for restructuring domains, you will be better prepared for the actual migration. Most organizations will want to migrate the account domains first to take advantage of the immediate benefits of migrating to Windows Server and Active Directory. To restructure an account domain, perform the following tasks: Migrate all of the global group accounts so that they exist in the target domain before the user accounts are migrated. Migrate the user accounts incrementally, in small batches. Re-migrate the global group accounts to update any membership changes in the source domain. Migrate the trusts that exist between the Windows NT 4.0 resource domains and the source account domains to the target domain in Windows Server. This ensures resource access for migrated user accounts during the migration process. Following a successful restructuring of the account domain or domains, the next step is to restructure the resource domains. Organizations often consolidate resource domains into organizational units in the target domain. To restructure a resource domain, perform the following tasks: Identify the service accounts running in the source domain. Migrate the member server and workstation computer accounts. Migrate local user profiles. Migrate the shared local groups on the Windows NT 4.0 domain controllers. Migrate the service accounts. Update user rights for files and folders, local groups, printers, the registry, and shared folders. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER: Dominio de Recursos OU Destino 2 Migrar el dominio de recursos

Moviendo Usuarios, Computadores en OUs
Migrar cuentas de usuario y grupo 1 Migrar cuentas de computador clientes 2 Migrar servidores miembro KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction After you determine the sequence in which you will migrate all domains, the next step in developing a migration strategy is to determine the sequence of restructuring objects in each domain. The recommended sequence Although you can restructure objects in each domain in whatever order that you prefer, this is the recommended sequence of restructuring objects in each domain: Migrate user and group accounts. It is preferable to restructure user and group accounts before other objects to take immediate advantage of improved user administration—one of the key benefits of an Active Directory domain. It is also easier to migrate these security principals as opposed to service accounts and member servers, and migrating these objects first provides good experience for migrating more complex objects later. Migrate client computer accounts. It is advisable to migrate client computer accounts (machine accounts in Windows NT 4.0) soon after user accounts so that Group Policy can reduce the overhead of configuration management. Migrate member servers. If you use Active Directory Migration Tool (ADMT), migrated user accounts will be able to access resources on member servers during the migration process, so it is not essential that these servers are migrated immediately. Also, member servers running file, print, or other application services require more attention than workstations during a restructure to ensure that shared resource access is preserved following the migration. It is recommended that you perform easier migrations to gain experience before performing more complicated processes. Move domain controllers. Domain controllers are not migrated as computer accounts in the migration process. Instead, you move the domain controllers as the last step in restructuring objects because it is important to keep a reasonable number of domain controllers active in the Windows NT 4.0 source domain until: No, or very few, users are logging on to the source domain as their home domain. No, or very few, services are requiring the source domain to authorize access requests by users in another domain. Note Because BDCs are required for authentication processing while resources and services in a Windows NT 4.0 source domain are being accessed, you should retain BDCs in the source domain until most of the member servers have been moved. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER: 3 Mover controladores de dominio (a menos que se decomisionen) 4

Demostración 3 Moviendo Usuarios en Contenedores de Directorio Activo

Migración de usuarios: ADMT
Opción Propósito Traducir perfiles roaming Copia perfiles roaming desde el dominio origen al dominio destino para los usuarios seleccionados Actualizar derechos de usuario Configura los derechos de usuario asignados a la nueva cuenta en el dominio destino para que sean los mismos de la cuenta de usuario original Migrar grupos de usuario asociados Migra los grupos asociados al usuario al mismo tiempo que la cuenta Actualizar objetos previamente migrados Actualiza los grupos a los cuales pertenecen los usuarios migrados KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction You can use the User Options page of the User Account Migration Wizard to control what rights and permissions user accounts will maintain after they are copied to the target domain. On the User Options page, you can select to translate the user’s roaming profile at the same time as the account migration. This will ensure that the server-based profile will be updated with the new security identifier of the migrated user account. Options This table lists the purpose of the options on the User Options page. (Option: Purpose) Translate roaming profiles: Copies roaming profiles from the source domain to the target domain for the selected user accounts. This process associates the roaming user profile with the new user account in the target domain. Update user rights: Sets the user rights assigned to the new user account in the target domain to be the same as the user rights assigned to the original user account in the source domain. Migrate associated user groups: Migrates the user’s group at the same time as the user account but not all of the members of those groups. You do not need to select this option if you first migrate the global group accounts to the target domain. ADMT automatically adds users to the correct global group if the group already exists in the target domain. Update previously migrated objects: Updates the groups of which the migrated user accounts are members, even if those groups were previously migrated. This option is available only if Migrate associated user groups is selected. Do not rename accounts: Tries to assign the migrated account the same name as the account in the source domain. If a naming conflict occurs, the options specified on the Naming Conflicts page control how the migrated account is named. Rename with prefix: Adds the specified prefix to the name of each migrated account in the target domain. The original account with the same name in the target domain remains unchanged. Rename with suffix: Adds the specified suffix to the name of each migrated account in the target domain. The original account with the same name in the target domain remains unchanged. Note Local user profiles are migrated as a separate step following the migration of computer accounts from the resource domain. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER: No renombrar las cuentas Intenta asignarle a la cuenta migrada el mismo nombre de cuenta que en el dominio origen Renombrar con prefijo Añade al prefijo especificado al nombre de cada cuenta migrada en el dominio destino Renombrar con sufijo Añade el sufijo especificado al nombre de cada cuenta en el dominio destino

Opciones de migración de Password en ADMT
Mantiene el password durante la migración de la cuenta Opción Propósito Passwords complejos Genera automáticamente un password complejo para cada cuenta de usuario migrada Igual al nombre de usuario Configura el password para cada cuenta copiada igual a los primeros 14 caracteres del nombre de cuenta del usuario Migrar passwords Ubicación para guardar el archivo de password Especifica un archivo de password al cual se escriben los passwords asignados o generados KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction On the Password Options page of the User Account Migration Wizard in ADMT, you have the option to set the password to the user’s name, generate a complex password, or migrate the existing source domain password. Why install Password Encryption Service for password migration? To migrate passwords by using the User Account Migration Wizard, you must first install Password Encryption Service on a domain controller in the source domain. This Windows NT 4.0 domain controller must be configured for 128-bit encryption, which is achieved by installing the 128-bit version of Windows NT 4.0 Service Pack 4 or later. After you install Password Encryption Service and the encryption key is created on the target domain controller, you then use a floppy disk to copy this key to the domain controller running Password Encryption Service. Note For more information about installing Password Encryption Service, see the Readme.doc file in the \VALUEADD\MSFT\MGMT\ADMT folder on the Windows Server Enterprise Server compact disc. Options This table lists the purpose of the options on the Password Options page. (Option: Purpose) Complex passwords: Automatically generates a complex password for each migrated user account. ADMT records the new passwords in the password file. Same as user name: Sets the password for each copied user account to the first 14 characters of the user account name. ADMT records the passwords in the password file. Migrate passwords: Maintains the user password during the account migration. Password migration requires installation of the Password Encryption Service on a domain controller in the source domain. Password Encryption Service creates a secure channel over which the passwords are migrated. Location to store password file: Specifies the location of the password file to which the assigned or generated passwords are written. Both the Complex passwords and Same as user name options use this text file to output the username-to-password list. The default location for this file is C:\Program Files\Active Directory Migration Tool\Logs\Passwords.txt. When either a matching or complex password is created, it is added to a log file, and you can then specify the path and name of the log file. Because this password log file could create a security risk if a new password is created, the User must change password at next logon attribute is set for the migrated user account in the target domain. If the Migrate passwords option is selected, this attribute is not set. Why can’t the password complexity or length be verified? Because of the way in which a password is copied from an account in the source domain to an account in the target domain, it is not possible for any password filter to verify the password’s complexity or length. It is not possible because only a hash (an algorithm that transforms data into fixed length normalized values) of the password exists in the source domain, and it is this hash that is copied to the target domain. Therefore, the password filter cannot examine the copied password to verify whether it meets complexity or length requirements. Password history is still verified because password history verification compares the hash against previous hashes. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Migrando Grupos Globales
Domain1 Domain3 Domain2 Grupos Globales Windows NT 4.0 Dominio Windows Server 2003 El Asistente de Migración de Grupos Lee los objetos de grupos globales en el dominio origen Crea un nuevo objeto de grupo global en el dominio destino; se crear un nuevo SID primario para el objeto en el nuevo dominio Agrega el SID del grupo global en el dominio origen al atributo SID-History del nuevo grupo global en el dominio destino Genera eventos en el dominio origen y destino KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction To preserve the global group memberships of users, you must first migrate the global groups. This creates a corresponding global group in the target domain for all global groups that exist in the source domain. The newly created global group in the target domain receives a new primary SID that contains the domain identifier of the target domain as part of the SID. The primary SID of the global group in the source domain is added to the SID-History attribute of the newly created group. What does the Group Account Migration Wizard do? During the migration of a global group, the Group Account Migration Wizard in ADMT performs the following steps: Reads the global group objects in the source domain Creates a new global group object in the target domain and creates a new primary SID for the object in the new domain Adds the SID of the global group in the source domain to the SID-History attribute of the new global group object in the target domain Logs events in the source and target domains The Group Account Migration Wizard can be configured to copy group members at the same time that it copies the groups. This option is more common in the intraforest migration scenario, which is discussed in the Restructuring Account Domains After an Upgrade lesson later in this module. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Opciones de migración de grupos en ADMT
Opción Propósito Actualizar derechos de usuario Copia los derechos de usuario asignados en el dominio origen al dominio destino Copiar miembros de grupo Copia los miembros de los grupos seleccionados para migrar Actualizar objetos previamente migrados Actualiza los miembros de los grupos seleccionados para migrar Migrar los SIDs de grupo al dominio destino Añade el SID de las cuentas migradas en el dominio origen al atributo SID-History de las nuevas cuentas en el dominio destino No renombrar las cuentas Intenta asignar al grupo migrado el mismo nombre que el grupo en el dominio origen Renombrar con prefijo Añade el prefijo especificado al nombre de cada grupo migrado en el dominio destino Renombrar con sufijo Añade el sufijo especificado al nombre de cada grupo migrado en el dominio destino KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction There are several options available in the Group Account Migration Wizard in ADMT that you should be aware of to successfully migrate group accounts. You can use the Group Options page of the wizard to set specific options on the migrated object. Group optionsThe following table lists the purpose of the options on the Group Options page. (Option: Purpose) Update user rights: Copies the user rights assigned in the source domain to the target domain. Copy group members: Copies the members of the groups that you selected to migrate. This option allows you to maintain the group membership information in the target domain. Update previously migrated objects: Updates the members of the groups that you selected to migrate, even if those members were previously migrated. This option is available only if the Copy group members check box is selected. Migrate group SIDs to target domain: Adds the SID of the migrated user accounts and groups in the source domain to the SID-History of the new user accounts and groups in the target domain. This feature uses a secure connection to the source domain controller. Do not rename accounts: Tries to assign the migrated group the same name as the group in the source domain. If a naming conflict occurs, the options specified on the Naming Conflicts page control how the migrated group is named. Rename with prefix: Adds the specified prefix to the name of each migrated group in the target domain. The original group with the same name in the target domain remains unchanged. To make group names unique, you could specify a prefix or a suffix that is added to the group name. Rename with suffix: Adds the specified suffix to the name of each migrated group in the target domain. The original group with the same name in the target domain remains unchanged. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Opciones de conflictos de nombres en ADMT
Opción Propósito Ignorar cuentas conflictivas y no migrarlas Deja intacta la cuenta en el dominio destino Reemplazar cuentas conflictivas Cambia propiedades de cuentas existentes en el dominio destino a equivalentes en la cuenta con el mismo nombre en el dominio origen Remover derechos de usuario existentes Asegura que la cuenta en el dominio destino no tenga mas derechos que la cuenta con el mismo nombre en el dominio origen Remover miembros existentes de los grupos a reemplazar Asegura que los miembros de los grupos migrados en el dominio destino sean los mismos que en los grupos relacionados en el dominio origen Renombrar cuentas conflicitivas añadiendo lo siguiente Añade el prefijo o sufijo especificado al nombre de la cuenta migrada en el dominio destino KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction The naming conflict options specify how the ADMT handles accounts in the target domain that have the same name as a copied account in the source domain. There are several options available on the Naming Conflicts page in the Group Account Migration Wizard. Naming conflict options The following table lists the purpose of the options on the Naming Conflicts page. (Option: Purpose) Ignore conflicting accounts and don’t migrate: Leaves the account in the target domain unchanged. Replace conflicting accounts: Changes properties of existing accounts in the target domain to match the properties of the account with the same name in the source domain. Remove existing user rights: Ensures that the account in the target domain does not have more user rights than those granted to the account with the same name in the source domain. This option is only available when the Replace conflicting accounts check box is selected. Remove existing members of groups being replaced: Ensures that the members of the migrated groups in the target domain are the same as the members of the associated groups in the source domain. This option is only available when the Replace conflicting accounts check box is selected. Rename conflicting accounts by adding the following: Adds the specified prefix or suffix to the name of the migrated account in the target domain to avoid conflict with the other account with the same name in the target domain. The original account with the same name in the target domain remains unchanged. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Opciones de transición de cuentas en ADMT
Opción Propósito Inhabilitar cuentas de origen Deshabilita la cuenta de usuario original en el dominio origen Inhabilitar cuentas en el destino Deshabilita la nueva cuenta de usuario en el dominio destino Dejar ambas cuentas abiertas Deja ambas cuentas activas en los dominios origen y destino KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction On the Account Transition Options page of the User Account Migration Wizard, you select how you would like to handle the source and target domain user accounts. Configure this wizard page depending on when you plan for your users to switch over to the target domain. One of the most important options on this page is the option to migrate user SIDs. This option must be selected to preserve resource access in the Windows NT 4.0–based environment during the migration process. Options The following table lists the purpose of the options on the Account Transition Options page. (Option: Purpose) Disable source accounts: Disables the original user account in the source domain. This option prevents a user from using the source domain account to log on to the source domain. Disable target accounts: Disables the new user account in the target domain. This option prevents a user from using the target domain account to log on to the target domain. This option can affect migrated service accounts. Leave both accounts open: Leaves both the existing account in the source domain and the new account in the target domain active. This option allows a user to log on to the source domain (using the source domain account) and to the target domain (using the target domain account). Days until source account expires: Sets the number of days after which the source account will no longer be available. This setting prevents a user from using the source account to log on to the domain after the specified number of days. Migrate user SIDs to target domain: Adds the SID of the migrated accounts in the source domain to the SID-History attribute of the new accounts in the target domain. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER: Días para que la cuenta origen expire Configura el número de días luego de los cuales la cuenta origen no estará ya disponible Migrar SIDs de usuario al dominio destino Añade el SID de las cuentas migradas en el dominio origen al atributo SID-History de las nuevas cuentas en el dominio destino

Relaciones de Confianza
Trusts Domain1 Domain3 Domain2 Windows NT 4.0 Dominio Windows Server 2003 KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction In scenarios in which there will be a delay between restructuring the account domains and the resource domains on which these account domains rely, trusts must be maintained between the resource domain and the target domain. These trusts can be created manually, or, in more complex domain models, you can use the Trust Migration Wizard in ADMT to automatically migrate these trusts. The resulting trust between the Windows NT 4.0 resource domain and the Windows Server target domain is an external, non-transitive, one-way trust. Users from the target domain can be authenticated in the resource domain to access resources. Users from the Windows NT 4.0 domain (the trusting domain) cannot authenticate in the Windows Server domain. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Relaciones de Confianza
Trusts Proceso 2 Iniciar ADMT y luego abrir el Trust Migration Wizard Especificar los dominios origen y destino Especificar el nombre del trust a migrar 1 2 3 KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction To migrate a trust that exists between the source domain and another domain to the target domain, use the Trust Migration Wizard in ADMT. Unlike global group and user account migration, there are no options to choose from when you migrate trusts. Procedure To migrate a trust that exists between the source domain and another domain to the target domain, perform the following steps: Start ADMT, and then open the Trust Migration Wizard. In the Trust Migration Wizard, complete the migration of the trust that exists between the source domain and another domain to the target domain by using the information in the table on this slide. (“On this wizard page: Do this”) Domain Selection: Specify the source and target domains. Trust Information: Select the trust that you want to migrate to the target domain.Click Copy Trust to copy a trust for the target domain. Then, when prompted for a user account and password that has administrative rights in the trusted domain, specify the user account and password. Completing the Trust Migration Wizard: Review the specifications for the trust migration, and then complete the migration. Verification To verify the migration of a trust to the target domain, perform the following steps: Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Domains and Trusts. In the console tree, right-click the target domain, and click Properties. In the Properties dialog box, click the Trusts tab, and verify that the migrated trust appears in the list of domains that trust this domain. Select the trust from the list, and click Properties. In the Properties dialog box, click Validate. Provide the appropriate user account and password with administrative privileges in the source domain to validate the trust in the trusting domain. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER: Verificación Verificar la migración de un trust al dominio destino usando Active Directory Domains and Trusts

Migrando Computadores
Domain1 Domain3 Domain2 Windows NT 4.0 Computadores Dominio Windows Server 2003 Las cuentas de computador incluye tanto estaciones como servidores miembro Las estaciones y servidores miembros tienen su propia base de datos de cuentas SAM Las cuentas usadas para dar acceso a recursos se mueven automáticamente con las cuentas de computador KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Introduction When you migrate resource domains to Windows Server, you must also migrate the computer accounts that reside in the resource domains. During this step, you migrate the computer accounts from the resource domains to the organizational unit in the Windows Server domain that holds the user and group accounts that you have already migrated. Computer accounts to migrate The computer accounts include both workstations and member servers. Workstations and member servers have their own SAM account databases. If they are moved between domains, they always take their databases with them. If accounts that exist in the local SAM database—accounts such as local groups—were used to grant access to resources, then they will always move with the computer. Therefore, migrating these accounts is not necessary. Domain controllers are not migrated between forests, but they can be upgraded and moved into the domain as part of the restructure process. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Migrando perfiles locales
Domain1 Domain3 Domain2 Windows NT 4.0 Perfiles de Usuario Dominio Windows Server 2003 Para estaciones corriendo Windows NT 4.0 Windows 2000 Windows XP KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: After you migrate a batch of computer accounts from the source domain, you can migrate the local user profiles for the associated users. The migration of local user profiles is only required on workstation computers running Microsoft Windows NT 4.0, Windows 2000, or Windows XP. Other operating systems, such as Microsoft Windows 95, do not support local user profiles. Registry modifications Unlike the processes for user, group, and computer accounts, this process does not actually migrate any object. Rather, you use the Security Translation Wizard in ADMT to modify the registry on the workstation computer running Windows NT 4.0. The profile on the computer is identified by the user SID in the registry at the following key: HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList The wizard translates the old SID for the new SID thereby preserving user access to the local profile. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Opciones para migrar perfiles locales de usuario
En esta opcíon del wizard Haga esto Traducir Objetos Opciones de traducción de seguridad (1) seguridad (2) Especifique el tipo de objetos para los cuales ADMT traducirá la seguridad Seleccione Previously migrated objects para recuperar objetos previamente migrados para la traducción Seleccione Other objects specified in a file para recuperar objetos especificados en un archivo Seleccione Replace para intercambiar el SID de la cuenta en el dominio origen con el SID de la cuenta en el dominio destino Seleccione Add para incluir tanto el SID anterior como el nuevo en la clave de registro profile list en el computador cliente corriendo Windows NT 4.0 Seleccione Remove para eliminar el SID de la cuenta en el dominio origen KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: There are relatively few options to consider when you use the Security Translation Wizard in ADMT to migrate local user profiles. It is helpful to remember the following options when you migrate local profiles. Translate objects options The options on the Translate Objects page specify the type of objects for which you want ADMT to translate security. You can select the following object types: Files and folders Local groups Printers Registry Shares User profiles User rights If you are only interested in migrating local profiles, select the User profiles check box. If, however, the computer you are sending the agent to hosts any other feature that requires security translation, you can select those features as well. Security translation options Security translation options specify how ADMT will handle the security translation process. There are two Security Translation Options pages. This table lists the purpose of the options on the first Security Translation Options page. Option: Purpose Previously migrated objects: Retrieves previously migrated objects for security translation. Other objects specified in a file: Retrieves objects that are specified in a file, called the SID mapping file. The following table lists the purpose of the options on the second Security Translation Options page. Option Purpose Replace: Replaces the SID for the account in the source domain with the SID for the account in the target domain in the discretionary access control lists (DACLs) and system access control lists (SACLs) in the security descriptors of the selected objects. This option gives the account in the target domain the same permissions on the selected objects as the account in the source domain. This option also removes these permissions from the account in the source domain. Add: Adds the SID for the account in the target domain to the DACLs and SACLs in the security descriptors of the selected objects that contain the SID for the account in the source domain. This option gives the account in the target domain the same permissions to the selected objects as the account in the source domain. Remove: Removes the SID for the account in the source domain from the DACLs and SACLs in the security descriptors of the selected objects. This option removes the permissions to the selected objects from the account in the source domain. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Migrando grupos locales compartidos
Domain1 Domain3 Domain2 Dominio Windows Server 2003 Shared Local Groups Windows NT 4.0 Para asegurar el acceso a los recursos luego de la migración Migre los grupos locales al dominio Windows Server 2003, y luego actualice el controlador de dominio a Windows Server 2003 y muévalo al mismo dominio Actualice todos los controladores de dominio en el dominio de recursos a Windows Server 2003, suba el nivel funcional, y cambie el tipo de grupo a grupo universal KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: After the migration of computer accounts, you must ensure that the users can still access resources on a server that was moved. Methods to ensure resource access after the migration You can use one of the following methods to ensure resource access: If your organization uses shared local groups to organize access rights and the local groups reside on a domain controller, you must migrate the local groups to the Windows Server domain to ensure that users can access resources after you move the domain controller. After you have migrated the shared local groups, you can upgrade the domain controller to Windows Server and move it to the same domain. An alternative method of ensuring that users can access resources on a server after you move it is to upgrade all domain controllers in the resource domain to Windows Server, raise the functional level of the domain to Windows 2000 native or later, and change the group type of the former shared local groups to universal groups. After you have done this, demote the domain controllers to member servers one by one, and move them to the target domain. Users will always have access to the resources because universal groups can exist anywhere in the forest and be used to grant permissions. Before you move the last domain controller and decommission the domain, you must move the universal groups by using ADMT. Note For more information about moving domain controllers and decommissioning domains, see Decommissioning Windows NT 4.0 Source Domains in Module 10, “Completing the Restructure Process,” in Course 2283A, Migrating from Microsoft Windows NT 4.0 to Microsoft Windows Server Directory Services (Beta). SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Migrando Cuentas de Servicio
Domain1 Domain3 Domain2 Windows NT 4.0 Cuentas de Servicio Dominio Windows Server 2003 Identificar las cuentas de servicio KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: During the migration of resource domains, you must migrate the service accounts that are used to operate services in the Windows NT 4.0–based environment. Definition A service account is a user account created explicitly to provide a security context for the applications that run as services. The service account is a standard user account that is granted the “Log on as a service” user right. Service accounts are differentiated from the local system account that is used by many services but is not identified as a separate user account. Tasks for migrating service accounts To migrate service accounts, you perform the following tasks: Identify the service accounts by using the Service Account Migration Wizard. Migrate the service accounts by using the User Account Migration Wizard in ADMT. For service accounts that inherit the “Log on as a service” right through membership in a local group, update the services to log on using the migrated service accounts by using the Security Translation Wizard. Note The steps in the service account migration process are not performed at one time. First, you will identify the service accounts, then you will migrate the computer accounts (which is discussed in the next lesson), then you can migrate the service accounts and, if necessary, update the user rights to log on as a service. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER: Migrar las cuentas de servicio Actualizar los servicios para hacer log on usando las cuentas migradas

Reconfigurar Permisos en Recursos Compartidos
Hacer log en un controlador de dominio Windows Server 2003 como Administrator 1 Proceso 2 Iniciar el Security Translation Wizard Especificar la información requerida en el Security Translation Wizard para reconfigurar los permisos sobre recursos compartidos 3 Hacer log on como un usuario de pruebas migrado Abrir un archivo en la carpeta compartida y para verificar el control total, cree un archivo en la carpeta Verificación KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: You can use the Security Translation Wizard in ADMT to scan a file server and update access control entries with new SIDs to allow migrated accounts the same level of access that they had before they were migrated. This approach works as long as the group or user accounts are not built-in group or user accounts. ADMT does not migrate built-in accounts. To reconfigure permissions on shared resources: Log on to a Windows Server domain controller as Administrator. Start ADMT, and then open the Security Translation Wizard. In the Security Translation Wizard, complete the reconfiguration of permissions on shared resources. To verify that the migrated group and user accounts now have access to the shared resource: Log on as a migrated test user. Open a file in the shared folder. Then, to verify full control, create a file in the folder. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER: Recursos Compartidos

Iniciar el Security Translation Wizard
Migrar Trusts Trusts Proceso 2 Entrar al DC Windows Server 2003 como Administrator Iniciar el Security Translation Wizard Entrar la información requerida en el Security Translation Wizard para los permisos en recursos compartidos 1 2 3 KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: To migrate a trust that exists between the source domain and another domain to the target domain, use the Trust Migration Wizard in ADMT. Unlike global group and user account migration, there are no options to choose from when you migrate trusts. To migrate a trust that exists between the source domain and another domain to the target domain, perform the following steps: Start ADMT, and then open the Trust Migration Wizard. In the Trust Migration Wizard, complete the migration of the trust that exists between the source domain and another domain to the target domain by using the information in the following table. To verify the migration of a trust to the target domain from the Active Directory Domains and Trusts Snap-in, open the Properties dialog of the target domain, click the Trusts tab, and click Properties, then Validate. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER: Verificación Entrar como un usuario de pruebas Abrir un archivo en la carpeta compartida y crear un archivo en la carpeta

Servicio DNS confiable para la restructuración de dominios
Para igualar dominios de Directorio Activo con dominios DNS Establecer un servidor DNS en el dominio destino Windows Server 2003 Configurar el servidor DNS corriendo Windows Server 2003 en el bosque destino como el servidor DNS primario para todos los dominios de Directorio Activo Promover el servidor DNS corriendo Windows Server 2003 para que sea un controlador de dominio en el dominio destino de Directorio Activo Cambiar las zonas DNS primarias a zonas integradas al Directorio Activo en el bosque destino Para crear nuevos dominios DNS que hospeden los registros de recursos SRV Instalar un servidor DNS en el dominio destino Windows Server 2003 Integrar el nuevo servidor DNS con los servidores DNS existentes Mover las zonas de búsqueda inversa a un servidor DNS corriendo Windows Server 2003 KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: When you perform a domain restructure from Windows NT 4.0 or from a separate Windows Server forest, one of the first administrative tasks is to integrate the DNS infrastructure from the source domain with the DNS infrastructure that is required for the target domain in the Windows Server forest. If your current DNS infrastructure does not support Active Directory, you must plan to immediately move the primary zones to a system that supports Active Directory, such as a Windows Server, to provide support for SRV resource records that are required by Active Directory. The method that you employ to ensure ongoing DNS name resolution during the migration phase depends on the name of the Active Directory root domain. To match the new Active Directory domain name to the existing DNS domain name in Windows NT 4.0, perform the following tasks: Establish a DNS server in the target Windows Server domain. Configure the DNS server in the target forest as the primary DNS server for all Active Directory domains. If using a DNS server running Windows Server, promote it to a domain controller for the target Active Directory domain. This will enable DNS data to be integrated into Active Directory. If using a DNS server running Windows Server, change any primary DNS zones to Active Directory integrated zones in the target forest. To create a new DNS domain that will host the SRV resource records of the Active Directory domain, perform the following tasks: Install a DNS server in the target Windows Server domain. Integrate the new DNS server with the existing DNS servers. Move the reverse lookup zones to a DNS server running Windows Server. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Restructurando un Dominio de Cuentas luego de un Upgrade
Domain1 Domain3 Domain2 U P G R A D E Windows NT 4.0 Dominio Windows Server 2003 KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: An alternative migration path to restructuring a domain between Windows NT 4.0 and Windows Server is to restructure the domain after a domain upgrade to Windows Server. Restructuring domains after an upgrade is procedurally the same as restructuring domains instead of upgrading. However, there are some technical implications of having both the source and target domains as part of the same Windows Server forest. What is different about migrating accounts between Windows Server domains? The process of migrating user and group accounts between Windows Server domains is similar to that of the Windows NT 4.0 to Windows Server scenario, except that you must move user and group accounts together as a closed set. The effect that this has on the migration is that it is not nearly as flexible as migrating user and group accounts between forests. In the Windows NT 4.0 to Windows Server scenario, you are able to move all groups at one time and then incrementally move the user accounts. In a Windows Server to Windows Server scenario, this method will most likely break the group membership. Instead, you must move the groups and all of their user accounts together. Therefore, the most practical solution may be to move all user and group accounts at the same time. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER: R E S T R U C T U R A Dominio Windows Server 200e

Qué cambia al restructurar luego de un Upgrade?
SID-History al restructurar post-upgrade SID-History puede ser usado para preservar el acceso a los recursos Para que SID-History funcione bien, debe mover un objeto desde el dominio origen al dominio destino Operación destructiva Restructurar objetos de seguridad dentro del mismo bosque Windows Server 2003 resulta en que los objetos sea movidos en lugar de copiados Los objetos del dominio origen dejan de existir KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: There are a number of differences between restructuring an account domain from Windows NT 4.0 to Windows Server and restructuring an account domain after an upgrade to Windows Server. SID-History in a post-upgrade restructure As with restructuring accounts from Windows NT 4.0 to Windows Server, when restructuring accounts within a domain that has been upgraded to Windows Server you can use the SID-History attribute to preserve users’ access to resources. However, for SID-History to work properly in this scenario, you must move an object (as opposed to clone) from the source domain to the target domain so that the source object ceases to exist as a result of the migration. You must do this because an object’s security identifier can only exist once in the Windows Server forest—whether it is in the objectSID attribute or the sIDHistory attribute. Note When Active Directory objects are viewed using an LDAP client, such as Ldp, the SID and SID-History attributes are displayed by using their LDAP display names: objectSID and sIDHistory, respectively. Destructive operation Because restructuring objects within a Windows Server forest by using the SID-History attribute requires that the source object be moved instead of cloned, you cannot implement a parallel environment during the migration process. Restructuring security principals within the same Windows Server forest results in the objects being moved rather than copied. The source domain objects, in this scenario, cease to exist. When you use ADMT, the process itself is identical. Closed sets Migrating security principals as a closed set means that you must move user accounts and the groups to which they belong at the same time. This is different from a migration from a Windows NT 4.0 source domain to a Windows Server target domain, where user accounts and groups can be migrated either together or separately. The closed set requirement with respect to migration in a forest is required to maintain group membership rules. Because this is a destructive operation, this is often impossible without migrating the entire domain. ADMT does not calculate a complete closed set, however, so you must be very careful when migrating users who are members of global groups. If you migrate a group that contains a user who is a member of another global group and that global group is not recursively a member of any groups being migrated at this time, it will break the membership between that user and the global group that is not included. Other group types do not have this issue because they can contain members outside of their domains. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER: Conjuntos cerrados Las cuentas de usuario y grupos al que pertenecen deben ser movidas al mismo tiempo para mantener las reglas de membresía ADMT no calcula un conjunto cerrado completo

El efecto de la migración en las políticas del sistema
Efectos de un upgrade al dominio Se aplican Políticas de Grupo si un crontrolador de dominio Windows Server 2003 autentica computadores cliente corriendo Windows Server 2003 Se aplican Políticas de Sistema si un controlador de dominio Windows NT 4.0 autentica computadores cliente corriendo Windows Server 2003 Se aplican Políticas del Sistema si una cuenta de usuario o computador está localizada en un dominio Windows NT 4.0 Se aplican Politicas de Grupo si una cuenta de usuario o computador está localizada en un dominio Windows Server 2003 Efectos de una restructuración Las Políticas del Sistema del dominio origen no son automáticamente procesadas por los computadores cliente migrados Las Políticas del Sistema son aplicadas si una cuenta de usuario o computador está localizada en un dominio Windows NT 4.0 Las Políticas de Grupo son aplicadas si una cuenta de usuario o computador está localizada en un dominio Windows Server 2003 KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: Windows NT 4.0 system policies do not migrate to Windows Server automatically. If a client computer running Windows NT 4.0 managed by a server running Windows Server is upgraded to Windows Server, then it receives only the Group Policy settings of Active Directory. Effects of a domain upgrade After an upgrade, the following effects will occur. (If…Then…) A Windows Server domain controller authenticates client computers running Windows ServerGroup Policy is appliedA Windows NT 4.0 domain controller authenticates a client computer running Windows ServerSystem policies are appliedA computer account is located in a Windows NT 4.0 domainSystem policies are applied to the computerA user account is located in a Windows NT 4.0 domainSystem policies are applied to the user accountA computer account or a user account is located in a Windows Server domainGroup Policy is applied to that account Effects of a domain restructure After a restructure, system policies from the source domain are not automatically processed by migrated client computers authenticating in the target domain. To allow system policies to continue to process for client computers running Windows NT 4.0, you must either integrate FRS with LAN Manager replication service to allow synchronization between the two file replication services or migrate system policies to Windows Server. During a restructure between forests, different mixes of system policies and Group Policy will be applied to user accounts and computer accounts. This depends on whether the user account or computer account is located in a Windows Server domain or Windows NT 4.0 domain. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

El efecto de la migración en los Logon Scripts
Efectos de un upgrade Los logon scripts de usuario guardados en la carpeta compartida NETLOGON no son afectados Los computadores cliente corriendo Windows Server 2003 ejecutan cualquier logon script de usuario o cualquier script asignado al usuario o computador usando Políticas de Grupo si son almacenados en la carpeta compartida NETLOGON Efectos de una restructuración Los logon scripts continuan funcionando para las cuentas clonadas y movidas si los scripts son migrados al dominio destino Los logon scripts que no se migren no funcionarán para las cuentas que hayan sido clonadas o movidas al nuevo dominio KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: User-based logon scripts in Windows NT 4.0 are implemented as MS-DOS® batch files stored in the NETLOGON shared folder of primary domain controllers (PDCs) and backup domain controllers (BDCs). When user accounts are moved or cloned to a target Windows Server domain, the logon script property for those user accounts is retained as an account attribute in the target Windows Server domain. Effects of a domain upgrade When a domain controller is upgraded to Windows Server, user-based logon scripts stored in the NETLOGON shared folder are not affected, and they continue to be available when client computers authenticate. FRS synchronizes the contents of the NETLOGON folder with all Windows Server domain controllers. To synchronize the contents of the NETLOGON folder with domain controllers in the domain not yet upgraded, the LAN Manager replication service must be replicated to FRS. Client computers running Windows Server run any user-based logon scripts that are located in the NETLOGON shared folder in addition to any scripts assigned to the user account or computer account by using Group Policy. Effects of a domain restructure Logon scripts continue to process for cloned and moved user accounts, provided that the logon scripts are properly migrated to the target domain. Logon scripts that are not migrated do not process for accounts that have been cloned or moved to a new domain because the logon scripts are not found in the authenticating domain controller’s NETLOGON shared folder in the target domain. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Migrar Políticas de Sistema a Políticas de Grupo en un ambiente basado en Windows Server 2003
KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: To ensure that system policies continue to process for Windows NT 4.0–based computer accounts in a Windows Server domain, you must migrate the system policy file of Windows NT 4.0, called Ntconfig.pol, to the NETLOGON shared folder in Windows Server. To connect the NETLOGON shared folders so that system policies are available in the Windows Server network, you use a bridge between the LAN Manager replication service and FRS. When to stop processing system policies Processing system policies for migrated client computers in a Windows Server domain is necessary only until client computers are upgraded to Windows Server. After all user accounts are migrated to and authenticating against the Windows Server target domain and client computers are upgraded, System Policy functionality must be replaced with Group Policy. Process To migrate system policies to Group Policy, perform the following tasks: Determine which migrated client computers running Windows NT 4.0 require system policies. Only client computers running Windows NT 4.0 that contain accounts that have been moved to the target domain require system policies from the NETLOGON shared folder. Determine which settings from system policies must be applied to client computers upgraded to Windows Server. System Policy settings can be migrated to Group Policy using the Gpolmig.exe utility in Microsoft Windows Server Server Resource Kit. This utility translates current System Policy settings into Group Policy settings and maps the necessary registry settings to the registry settings for Windows Server. Determine where in the organizational unit structure to deploy Group Policy. You can apply Group Policy at different levels of the Active Directory hierarchy. When deploying Group Policy, you must determine which policies must be applied at the domain level and which policies must be applied at specific organizational units in the Active Directory hierarchy. Determine whether system policies must be decommissioned in the source domain. Only when all client computers running Windows NT 4.0 are upgraded to Windows Server can you remove system policies from the NETLOGON shared folder and replace them with Group Policy. For a restructure, you can remove system policies after all client computers have been migrated to Windows Server. To remove system policies, you delete the Ntconfig.pol file from the NETLOGON shared folder of a Windows Server domain controller. FRS will ensure that the file is deleted from all other domain controllers in the domain. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER:

Migrar Logon Scripts a Políticas de Grupo en un ambiente basado en Windows Server 2003
1 Identificar todos los logon scripts en la carpeta compartida NETLOGON 2 Determinar si los logon scripts de usuario pueden ser eliminados Determinar dónde aplicar scripts de Políticas de Grupo en la jerarquía de Directorio Activo 3 KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: If user accounts are cloned to a Windows Server target domain, the user-based logon scripts of Windows NT 4.0 must be migrated to the NETLOGON shared folder in Windows Server by bridging the LAN Manager replication service and FRS. The bridge will ensure that the contents of the NETLOGON shared folder are identical in both the source and target domains so that the same logon script is processed for both the source and cloned user accounts. If user accounts are moved between two Windows Server domains, then ensure that any required logon scripts are copied into the NETLOGON shared folder of a domain controller in the target domain. Why convert logon scripts to Group Policy? When moving computer accounts to a target Windows Server domain, logon scripts can be converted to Group Policy in Windows Server. Group Policy allows greater flexibility in applying logon scripts; for example, logon scripts can be assigned to both computer and user accounts at the container level in Active Directory. Additional logon scripts, such as user logoff and computer start up and shutdown, can also be applied through the use of Group Policy. By using Windows Script Host to process the logon scripts, more flexible commands can be executed than were possible in the MS-DOS batch file format used for the user-based logon scripts of Windows NT 4.0. Process To migrate logon scripts to Group Policy, perform the following tasks: Identify all of the logon scripts in the NETLOGON shared folder. Identify all of the logon scripts and the person responsible for maintaining them. This person’s account must be granted write access to the logon script in the target domain for editing purposes. Determine if user-based logon scripts can be removed from the network. Users authenticating at client computers running Windows NT 4.0 will require the user-based logon scripts of Windows NT 4.0. If these client computers exist on your network, you must maintain user-based logon scripts. Also, because Group Policy cannot be applied to user accounts directly, there may be situations that require the continued use of standard logon scripts. Determine where to apply Group Policy scripts in the Active Directory hierarchy. If you intend to deploy Group Policy as a replacement or supplement to user-based logon scripts, you must consider where you will apply the scripts in the Active Directory hierarchy. Group Policy can only be applied at the site, domain, and organizational unit levels. SLIDE TRANSITION: ADDITIONAL INFORMATION FOR PRESENTER: Logon Scripts Políticas de Grupo

Resumen de la Sesión Planifique y prepare inteligentemente la migración examinando la estructura existente Configuraciones diferentes llevan hacia un upgrade, restructuración o ambas Limpiar antes de migrar facilita el proceso de migración Una variedad de herramientas, incluyendo ADMT, están disponibles para ayudar a simplificar la migración KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: SLIDE TRANSITION: ADDITIONAL INFORMATION/CROSS REFERENCE FOR PRESENTER:

Para más información… www.microsoft.com/technet/tnt1-74
Sitio principal de TechNet en Página de recursos de esta sesión KEY MESSAGE: SLIDE BUILDS: None SLIDE SCRIPT: SLIDE TRANSITION:

MS Press Información interna para profesionales IT
Key Message: Talk about MS Press books and introduce the Build your own book feature SLIDE BUILDS: 1 SLIDE SCRIPT: [BUILD 1] (Add book script here) SLIDE TRANSITION: ADDITIONAL INFORMATION/CROSS REFERENCE FOR PRESENTER: Para los últimos títulos para profesionales de IT visite

Entrenamiento Recursos de enseñanza para técnicos
Migrating from Microsoft Windows NT 4.0 to Microsoft Windows Server 2003 Directory Services Curso Número: 2283 Disponibilidad: Desde Marzo 2003 Syllabus detallado: Microsoft Training & Certification develops the courseware called Microsoft Official Curriculum (MOC), including MSDN Training courses. MOC offers comprehensive training courses for both IT professionals and developers who build, support, and implement solutions using Microsoft products and technologies. Please be sure to tell the audience that these training courses are related to the subject that was just covered in the slides, but they do not necessarily provide in-depth coverage of this exact subject as it may include other topics. Anyone interested in more information about the course(s) listed should visit the Microsoft Training & Certification Web site at and review the syllabus. All MOC courses are delivered by Microsoft’s premier training channel, Microsoft Certified Technical Education Centers and classes are taught by Microsoft Certified Trainers. Para ubicar un proveedor de entrenamiento, acceda a Los Centros Técnicos de Educación Certificados Microsoft son los socios premier Microsoft en servicios de entrenamiento

Eventos y Web Casts en TechNet
Qué es TechNet? Las respuestas correctas a la mano TechNet es la colección de recursos para ayudar a los implementadores de TI a planificar, distribuir y administrar exitosamente los productos Microsoft Suscripción TechNet Actualizaciones mensuales en DVD o CD El recurso definitivo para ayudarle a evaluar, distribuir y mantener productos Microsoft Sitio Web de TechNet Accesible en Recursos en línea y comunidades Servicios en línea para suscriptores TechNet Flash e-newsletter cada dos semanas Actualizaciones de seguridad, nuevos recursos y ofertas especiales While the monthly subscription software is the most obvious component of TechNet, there’s also much more. The TechNet web site gives subscribers access to valuable information as well as threaded discussion pages and online seminars. Many subscribers use the web as frequently as they use the software. In the subscribers only section, subscribers can access the Online Concierge Chat Support service-a Microsoft support special can help them locate technical information quickly and easily. TechNet Plus subscribers also get access to our Managed Newsgroup Support Service. You can post questions in over 90 IT related public newsgroups and Microsoft will ensure that you get a response within 72 hours TechNet Flash is a bi-weekly newsletter subscribers can register for-it gives them up to date information on the latest postings to the web site TechNet Events-TechNet subscribers have access to free events that explain how to use Microsoft products and technologies at a technical level TechNet Communities ????? Eventos y Web Casts en TechNet Recursos sobre los últimos productos y tecnologías Microsoft Hands-on, información sobre “cómo hacer” Comunidades TechNet Grupos de usuarios Grupos de noticias manejados

La Suscripción TechNet
TechNet es un servicio de suscripción mensual que provee las herramientas, software y recursos que un profesional de TI necesita para planear, distribuir, administrar y dar soporte eficientemente a los productos Microsoft La Suscripción TechNet ha demostrado que ahorra tiempo y dinero a las compañías Si Ud es un profesional de TI trabajando en soporte técnico, administración de redes o sistemas, o arquitecturas tecnológicas, entonces TechNet es para Ud. “You have everything you need to solve problems in one place” – Wayne Brown, VP Information Technology, Heald College

Cómo puedo tener TechNet?
Visitando TechNet Online en Registrándose en el TechNet Flash Uniéndose al foro TechNet Online en Suscríbase a TechNet Asistiendo a eventos TechNet o en línea KEY MESSAGE: Purpose of this slide is to educate IT Pros on where to go and how to be a part of TechNet. SLIDE BUILDS: None SLIDE SCRIPT: There is one place you should go to start: WW.MICROSOFT.COM/TECHNET There is one communication you should subscribe to: TechNet Flash. Twice monthly for the IT Pro community - focuses on news, information, resources and events. Post questions on the discussion forum. Subscribe online Look for TechNet branded events - feature SLIDE TRANSITION: Last slide in the deck. Round off however you like. ADDITIONAL INFORMATION FOR PRESENTER:

Migrando a Windows® Server 2003 desde Windows NT® 4.0

Presentaciones similares

Presentación del tema: "Migrando a Windows® Server 2003 desde Windows NT® 4.0"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Migrando a Windows® Server 2003 desde Windows NT® 4.0

Presentaciones similares

Presentación del tema: "Migrando a Windows® Server 2003 desde Windows NT® 4.0"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback