Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information.
The information gathered may enable Pearson but not the third party web trend services to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.
This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising.
Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site. Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.
Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider.
Marketing preferences may be changed at any time. If a user's personally identifiable information changes such as your postal address or email address , we provide a way to correct or update that user's personal data provided to us.
This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service informit. Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT.
If you choose to remove yourself from our mailing list s simply visit the following page and uncheck any communication you no longer want to receive: www. While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest pearson. California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice.
The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.
This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site. Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.
We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance.
Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions. Microsoft spent a lot of effort tuning Active Directory in Windows Server , to improve scalability and speed and to correct key deficiencies.
In this sample chapter, you'll learn what's new, and how to take advantage of Active Directory's new features. This chapter is from the book. Overview Pearson Education, Inc. Collection and Use of Information To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including: Questions and Inquiries For inquiries and questions, we collect the inquiry or question, together with name, contact details email address, phone number and mailing address and any other additional information voluntarily submitted to us through a Contact Us form or an email.
Surveys Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Contests and Drawings Occasionally, we may sponsor a contest or drawing. Newsletters If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information informit. Service Announcements On rare occasions it is necessary to send out a strictly service related announcement.
Customer Service We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form. Other Collection and Use of Information Application and System Logs Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Web Analytics Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site.
Cookies and Related Technologies This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Security Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.
Children This site is not directed to children under the age of However, Universal Group Membership Caching has some negative impact on users and on the domain. Because the cache is a static value that is refreshed or updated periodically, this can cause delays in the user being affected by group membership changes.
Therefore, if you're thinking about implementing this feature at a site, take note of the following:. Whether an Administrator is available to maintain this this is difficult to anticipate, but be aware that there will be some administrative overhead.
If there are hundreds of users at a site, it might be prudent to locate a GC at that site, even if it is connected to the rest of the network via slow links. HP designed its network so that GCs are placed more frequently in sites with slow WAN links, thus shielding the users from those links. If there are only a few users in a small sales office, the use of Universal Group Membership Caching will give the users the performance of a local GC without the overhead and expense of having one at that site.
The difference, of course, is the membership update latency. In addition to the Universal Group Membership Caching feature, several other significant improvements were made to GC server functionality, including improved replication performance of the partial attribute set PAS , improvements in GC demotion performance, and improvements in the way GCs advertise themselves. GCs provide quick access to commonly used objects and attributes for any domain in the forest, reducing WAN traffic and improving search performance from the user's perspective.
By definition, GCs contain all the objects of all domains in the forest, all the attributes of the objects in the domain for which the GC is a DC, and some of the attributes of the objects in the other domains in the forest. The objects and attributes for the other domains are stored in a read-only context and comprise the PAS, which is defined in the schema. If an Administrator desires to add additional attributes to the PAS so that searches on certain attributes occur more quickly, he or she could edit the appropriate object via the Active Directory Schema Manager, and change the attribute from the Optional list in the object properties to the Mandatory list.
For instance, on the PrintQueue object, printColor is an optional attribute. An Administrator who is a member of the Schema Admins group desires to add printColor as a mandatory attribute so that attribute will be replicated to all GCs.
Thus, a user visiting a site from another domain can locate a color printer faster because the local GC has the printColor attribute associated with the printers.
To set this, the Administrator would open the Active Directory Schema Manager snap-in, right-click on the printQueue object on the left pane, go to Properties, and add the printColor attribute from the Optional list to the Mandatory list, as illustrated in Figure 1. In Windows , an operation as simple as this would cause all GCs in the forest to perform a full synchronization of the read-only directory partitions, causing a bandwidth spike for each GC roughly equivalent to promoting a DC to a GC, and causing a temporary disruption of service.
Windows Server changes this behavior by replicating only the changed attributes. This is a significant improvement in performance, making the attribute change almost insignificant in most cases.
In Exchange and Windows , there was an issue with Exchange failures caused during a GC promotion. When a GC is promoted, it does not require a reboot at the end of the process. If it is rebooted before the read-only partitions are fully replicated, some MAPI clients might use the GC for the GAL, causing possible mail failure for those clients.
This parameter does not allow the new GC to advertise itself until replication is complete for all naming contexts NCs. Windows Server implements a new value in this same Registry location to set this behavior by default. The value is Global Catalog Promotion Complete, and the data for this value is set to 1 by default. The media can be tape, CD, DVD, hard disk or other media that will be local to the new server of course, the media must have the capacity to store the restored system state files.
DCPromo produces an additional dialog box, shown in Figure 1. At the end of DCPromo, a connection is made to a live DC to source changes that occurred since the media was created. The "DCPromo" section later in this chapter details how the IFM feature works, and discusses the use of unattended answer files. Although it is highly beneficial to build DCs using this feature, it's even more beneficial to build GC servers in this way because of the size of the GC compared to a DC.
A good example is Hewlett-Packard's AD deployment. Because of the size of the AD and available bandwidth on the network, rebuilding a GC took from three to five days, depending on the location.
HP viewed this as a critical feature to making the AD environment more resilient and significantly reducing downtime. Thus, HP was running its production environment on beta software. One of the contributing factors in the lengthy process of rebuilding a GC in Windows was the time required to demote the GC. The operation is quite simple. On the Properties page, there is an option for Global Catalog. If this box is checked, clearing it initiates a demotion process that removes the read-only partitions from that DC.
By default, this was every 15 minutes. Using the default minute interval, this would require 5 hours and 15 minutes to complete this change. Windows Server changed the way this demotion is handled. Instead of replicating a certain number of objects per each KCC cycle, the operation continues removing objects until all objects are removed. Replicating these objects is a low priority among replication tasks, so if another replication request comes in, it takes priority. Thus, if you remove the GC role during low utilization periods, the process continues, possibly uninterrupted.
Otherwise, it uses available bandwidth until the job is complete. This results in a more efficient way to remove the GC. While supporting Windows Administrators during the past several years, I ran into a number of situations in which the name of the DC had to be changed. The problem with Windows , of course, is that the only way to change the computer name of a DC is to demote it, change the name, and then repromote it.
This is a complex process to perform a simple task. Windows Server provides a very viable feature called Domain Controller Rename not to be confused with Domain Rename. This functionality requires the domain to be in Windows Server domain functional level and can be performed either via the GUI Graphical User Interface or by using the Netdom option. You'll learn both methods in the following sections. This method is fairly simple. A pop-up message appears, as shown in Figure 1. Just click OK and the familiar Computer Name Changes dialog box appears that allows you to change the name, as shown in Figure 1.
You are prompted for credentials and, if all goes well, you are notified of the need for a reboot. As you can see, this process is pretty much the same as the process for renaming any other computer. This process modifies Registry values and cleans up DNS mostly. Windows Server added a couple of new options to the Netdom command-line utility: Computername and RenameComputer.
The RenameComputer option isn't made to work for a DC. Although it does seem to work without error, it doesn't do all the things it needs to for a DC rename, so don't use it. Using the Netdom Computername command requires several steps, and the process gives you a good view of what is going on under the hood. Before proceeding, you must set the domain functional mode to Windows Server all DCs in the domain must be Windows Server The Netdom option called computername should not be confused with an actual computername.
You should enter the word Computername after the Netdom command, followed by the existing computername, as in this example. For this example, the following command would be used. Here we see that DC1.
Verify the results by executing the following command:. You will see the old name, DC1. This is expected behavior and will be corrected after rebooting the computer, but don't reboot yet.
Open a command window and use Netdom to enumerate the computernames. Go to My computer, select Properties, and then click the Computer Name tab. The new name should be displayed. Although both methods of DC rename do a good job of cleaning up DNS, they both fail in changing the name of delegation records with the old computername.
If you have child domains and use this delegation, a DC from each domain will have a delegation record to this zone. This is demonstrated in Figure 1. Left in this state, all queries for Cname records and GC records will fail because the referral will go to a nonexistent server.
You can easily change this by right-clicking on the record in the right pane, selecting Properties, selecting EDIT, and then entering the correct name and the IP address. Do this for each delegation record that points to a renamed DC. One of the criticisms of AD has been that its scalability is limited by the fact that you have only three naming contexts: configuration, schema, and domain. Windows introduced application partitions. An application partition is a user-defined naming context that can be hosted by any set of DCs from any domain.
Thus, there is no domain boundary in such a partition. Think of a partition as a truck and data, such as the zone information, as cargo on the truck. When you replicate the partition, the zone information goes with it. You can add other data to the partition and replicate it to the DCs in the replica set.
Application partitions have the following characteristics:. Impacts the site topology in terms of replication traffic. These partitions replicate in addition to the configuration, schema, and any domain partitions defined by default.
The forest also contains EU. The application partition contains a DC from each of the three domains. This partition is represented in the figure as a triangle, which usually denotes a domain. This is appropriate because this partition is a NC just like a domain is, although with limited capabilities.
Microsoft implemented two application partitions in Windows domains that are created and configured by default when a domain is created. There is a separate DomainDnsZones partition for each domain in the forest. Each domain has one of these zones.
Because it really isn't recommended to use these default partitions for other purposes, let's look at an example of how you can use a custom application partition. The CFO of a company wants to develop a new in-house application to manage the compensation plan of the company's employees. Most of the data that the application will use is semi-static pay rate, tax ID, health benefit selections, health benefit costs, and so on and typically changes only on an annual basis.
The human resources organizations that will leverage the application are split into two distinct groups. The CFO mandates to the developers that unlike most information in the AD, the data managed by this application should be considered sensitive and should be replicated only between New York and Tokyo both hub sites , but nowhere else. The in-house developers decide that the data needs to be replicated between both the New York and Tokyo sites and should also be updated from both locations for the purposes of day-to-day human resources functions, data analysis, and application fault tolerance.
As such, the developers determine that the type of data, the data's user affinity, the requirement for replicated data, and the need for multi-master updates fit well with the features and capabilities of AD. The down side to this is that these partitions will work only on DCs, and it has long been recognized that installing applications on DCs is not a best practice.
In the following example, we will create an application partition called MyAppPart in a forest that has three domains: Company. From a command prompt, run ntdsutil. Go to the Domain Management menu, then to the Connection menu, and connect bind to a DC in the domain.
In this case, we'll assume we connected to DC1. You will see a screen listing the application partitions and asking for confirmation that you want to continue and delete these partitions. Microsoft made a number of improvements to AD replication. This section provides a quick summary of these improvements, but you'll find a more detailed description, including examples of implementation, in the "Replication Topology" section of Chapter 5.
Lingering objects have been causing problems in Windows deployments for some time, yet at conferences, none of the attendees recognize this issue. Simply stated, lingering objects are objects that are reanimated after their tombstonelifetime expires and is purged. This is caused when a DC or GC comes back online after having been offline for more than the tombstonelifetime period, 60 days by default.
This causes security problems because the user object of a dismissed employee could be reanimated, cause replication to break, and otherwise clutter the AD. The real problem is when a GC comes back online and reanimates read-only contexts of the objects, which were difficult or impossible to delete before Windows SP3. Windows and Windows SP3 and later provide functionality to prevent these objects from replicating through the forest and permit deletion of the read-only objects via a Registry key.
Loose behavior is the default in Windows and is the default after upgrading from Windows to Windows Server We discuss this thoroughly in Chapter 5. This is the foundation of AD replication. The efficiency of this topology determines replication latency and the time the AD takes to perform its calculations.
The performance of the KCC was inefficient enough to impose a practical limit on the number of about sites in a topology in Windows Windows Server has a completely rewritten spanning tree algorithm that makes dramatic improvements in the ISTG's performance, raising the site limit to about 3,, according to Microsoft testing as of this writing.
It also has improved general AD performance and reduced latency in many cases. Another limit in Windows was the number of sites that could be connected to a single hub site in a single domain.
That is, if you have a strict hub and spoke topology and a single domain, you are limited to about to sites connected to a hub site.
The solution in Windows was to create all the connection objects manually, making connections from the site BHS to multiple DCs in the hub site. Unfortunately, this had to be managed manually as well. Chapter 5 provides details on this feature as well.
Windows Server has improved the algorithm that decompresses inter-site replicated data. This improves replication performance and reduces latency. Windows Server also permits you to turn off inter-site compression of data, trading the increased bandwidth for local DC performance.
See Chapter 5 for additional details. Chapter 5 also covers a number of improvements in Windows Server in the area of AD replication. The chapter describes and analyzes practical examples and case studies of companies that have had success and failure in deploying AD in Windows and Chapter 5 also covers the new features and fixes made in Windows Server , and provides a good description of new troubleshooting and diagnostic tools.
For the purpose of this chapter, a brief summary is in order. This caused all FRS content from all DCs to be pulled to the new DC at the same time, causing a high-bandwidth utilization on the network, and the sourcing DCs were unavailable for a period of time. Windows provides a serial vvjoin whereby one DC is sourced for the new DC, and then the others are sourced, one at a time, for changes, resulting in better performance and higher availability of the DCs. Changes to the automatic non-authoritative restore functionality: When Windows FRS encountered certain serious errors, such as Journal Wrap, it would automatically perform a nonauthoritative restore from a good DC to the one with the error, forcing a full sync of FRS content.
This caused the sourcing DC to be unavailable for a period of time. Windows turns this behavior off by default, logging an event to inform the Administrator that a nonauthoritative restore should be performed at the Administrator's earliest convenience. You can turn the default back to automatic via a Registry key. When the NTFS Journal was filled, it would overwrite the entries at the start, causing FRS to get lost, break replication, and require a nonauthoritative restore to get going again.
These programs can cause large numbers of files to be copied to the staging directories. FRS now identifies situations where files are being replicated repeatedly in short periods of time and suppresses the replication, accompanied by an event.
FRS does not stop replicating if the staging area is filled: Windows still has a MB limit on the staging area before replication is disabled, but it implements a cleanup operation. Allows compressed data replication: Windows FRS allows replication of compressed data, which is not possible in Windows Windows permits multiple DFS roots on a single server. DFS referral list can be configured to prioritize DFS servers based on site cost, which is much more efficient than in Windows Kerberos authentication relies heavily on accurate time synchronization between all computers in the forest.
By default, the time skew between any two computers in the forest must be five minutes or less. Windows Server also provides a new version of the Win32tm. Chapter 5 describes in detail how time services work in conjunction with Kerberos for security, as well as time-service configuration and troubleshooting tips. If Windows Server were a retail business with a big electric sign out front advertising three exciting reasons to patronize the business, Domain Rename would likely be one of the three.
In fact, HP is a good example of such a situation. At the time of the merger with HP, Compaq was just completing a two-year migration of users from the old NT domains inherited from mergers with Digital and Tandem.
HP, on the other hand, had a small NT environment and had not built a Windows structure at all. The decision was made to use Compaq's Windows infrastructure and to migrate the HP users into it. This made perfect sense, except for the name of the domain. NET and was structured as shown in Figure 1. Thus, there became a business requirement to rename the domain. As of this writing, HP has not renamed this domain, but is planning on it. However, Microsoft has had a couple of customers successfully rename a domain, and Microsoft successfully renamed its corporate development domain as well.
One of its customers mistakenly renamed a domain with Exchange pre-SP1 and then had to rename it back to the original. Pretty impressive to do it twice, ending up with the same name and be successful. It also shows good resiliency. This section provides a fairly high-level description of how Domain Rename works to give you an idea of what's involved.
We give pointers to Microsoft whitepapers that provide the details on how to actually rename a domain. The remainder of the section reviews Domain Rename from a design perspective, discussing capabilities and limitations of Domain Rename, application compatibility issues, details on Exchange compatibility, benefits and risks analysis, and a few examples along the way.
In this section, we don't rehash the material in the whitepapers, but rather, summarize their contents and apply my experience to make recommendations. The whitepapers are the definitive guide to Domain Rename, so download, read, and use them.
The step-by-step guide provides the actual procedure. In addition, I have worked with a few customers who were considering using it, so I've had a good bit of exposure to Domain Rename. Following is a high-level view of the procedure.
The forest must be at Windows functional level, and all domains must be at Windows Server functional level. This means every DC in the forest must be Windows Server Identify a member server in a domain must have reliable access to the domain naming master from which to run the Domain Rename commands. Get the Domain Rename tools, rendom. It's best to get them from the Web site to get any new versions available.
Following is an overview of that process:. Using the rendom. Run rendom. In addition, as a side effect, the Service Principal Name attribute of the DC accounts is updated as well. Make sure all DCs can be contacted, and then execute the script on each DC. You can retry the command to execute the script as many times as needed until all DCs execute it successfully.
The rename process generates a "state" file every time you execute the command to run the script on each DC. The state file reports the state of each DC that is, whether it has been updated. Rerunning the command to execute the scripts does not execute on DCs that have been successfully updated. These steps have been included here to show you how complex this process really is, and that there really isn't an easy way back once you start. The key is step 5. You need to realistically determine how long it will take to contact every DC in every site in the entire forest.
According to HP's AD team, end-to-end replication took a few hours, but they estimated that it could take several weeks to update all the DCs in the Domain Rename process.
It is important to note that Domain Rename is not the same as "Prune and Graft. Moving the B. Domain rename is bounded by the forest. Domain Rename is not the same as Prune and Graft.
Prune and Graft, or merging of domains across forests, is not possible in Windows Now let's see what you can and can't do with Domain Rename. The following list identifies significant operations that Domain Rename can perform:. So they created a split name in Windows with the NetBIOS name retaining the name with the illegal character, and the DNS name comprising a new version without the character.
Domain Rename has a number of limitations, some of which could prevent you from deploying Domain Rename, forcing you to use a migration solution instead. These limitations include the following:. The forest root domain cannot be restructured for placement in another location in the domain tree, such as moving it to become a child domain of another domain. Applications may not support Domain Rename.
See the upcoming "Application Compatibility" section of this chapter for more details. Renaming a domain impacts all child, grandchild, and so on, domains under it. You must rename all of them. All DCs must be able to be contacted during the rename process. If you can't contact them to execute the rename instructions, you have to shut them off and reinstall or manually demote them, and then promote them back into the new domain. Because the rename instruction is executed independently on each DC, if some DCs cannot be contacted, some DCs will become members of the new domain and some will still be members of the old domain.
This is a problem because it essentially splits the DCs into two domains and as such it cannot replicate domain data between them. If there are changes such as group membership modifications, user password changes, user object modification, and so forth, they will not replicate to the other domain until the Domain Rename has completed successfully. This could result in a loss of service. All clients must have their domain suffix changed to the new domain.
However, you can do this prior to the rename operation via Group Policy. The problem at this point in the evolution of the Domain Rename technology is that there just isn't much data on application compatibility. Even Microsoft, at the time of this writing, doesn't have a definitive list of Microsoft applications that support Domain Rename. Note that no application is completely "incompatible," as it can certainly be uninstalled and reinstalled, but obvious costs and risks are involved in doing that.
There are certainly other ways to solve a problem than by renaming the domain and cleaning up afterwards. Refer to the Domain Rename whitepapers we noted earlier in this section for details. See details in the upcoming "Exchange Recovery Options" section if you rename a domain with Exchange or pre-SP1 deployed these options aren't pretty, but Microsoft says they work.
Exchange SP1 supports Domain Rename. However, as of this writing, SP1 has not been released, so there are no cases to cite. Check with Microsoft for current information. You can prepare and clean up Certificate Services to support Domain Rename. Details are in the Microsoft Domain Rename whitepapers previously noted. This management experience is designed to be consistent with how you manage native Azure virtual machines.
When a hybrid machine is connected to Azure, it becomes a connected machine and is treated as a resource in Azure. More information can be found at the Azure Arc enables servers documentation. Improvements to Windows Admin Center to manage Windows Server include capabilities to both report on the current state of the Secured-core features mentioned above, and where applicable, allow customers to enable the features.
More information on these and many more improvements to Windows Admin Center can be found at the Windows Admin Center documentation. Hotpatching is a new way to install updates on new Windows Server Azure Edition virtual machines VMs that doesn't require a reboot after installation. More information can be found at the Azure Automanage documentation. There are several platform improvements for Windows Containers, including application compatibility and the Windows Container experience with Kubernetes.
There are several other enhancements that simplify the Windows Container experience with Kubernetes. These enhancements include support for host-process containers for node configuration, IPv6, and consistent network policy implementation with Calico. In addition to platform improvements, Windows Admin Center has been updated to make it easy to containerize.
NET applications. Once the application is in a container, you can host it on Azure Container Registry to then deploy it to other Azure services, including Azure Kubernetes Service.
With support for Intel Ice Lake processors, Windows Server supports business-critical and large-scale applications, such as SQL Server, that require up to 48 TB of memory and 2, logical cores running on 64 physical sockets. Windows Server brings support for nested virtualization using AMD processors, giving more choices of hardware for your environments. More information can be found at the nested virtualization documentation.
It is built on Chromium open source and backed by Microsoft security and innovation. It can be used with the Server with Desktop Experience installation options. More information can be found at the Microsoft Edge Enterprise documentation.
For details, see Microsoft Edge lifecycle documentation. UDP is becoming a very popular protocol carrying more and more network traffic due to the increasing popularity of RTP and custom UDP streaming and gaming protocols. In addition, we have also made hundreds of improvements to the UDP data path both transmit and receive. Windows Server and Windows 11 both have this new capability. These features are enabled in the transport stack by default and provide a smoother network data flow with better performance at high speeds.
This allows the hypervisor network to coalesce packets and process as one larger segment. CPU cycles are reduced and segments will remain coalesced across the entire data path until processed by the intended application. This means improved performance in both network traffic from an external host, received by a virtual NIC, as well as from a virtual NIC to another virtual NIC on the same host.
Enhancements to Storage Migration Service in Windows Server makes it easier to migrate storage to Windows Server or to Azure from more source locations. Here are the features that are available when running the Storage Migration Server orchestrator on Windows Server
0コメント