IT Core Blog

Never stop questioning. Curiosity has its own reason for existing…

Posts Tagged ‘Active Directory

Hyper-V R2 Cluster CSV stops working when NTLM is disabled in cluster with Hyper-V Enabled

leave a comment »


Hyper-V R2 Cluster CSV stops working when NTLM is disabled in cluster with Hyper-V Enabled

ID: 5121
Source: Microsoft-Windows-FailoverClustering
Version: 6.1
Symbolic Name: DCM_VOLUME_NO_DIRECT_IO_DUE_TO_FAILURE
Message: Cluster Shared Volume ‘%1′ (’%2′) is no longer directly accessible from this cluster node

This error may be caused because the NTLM was disabled in your Hyper-Host. Enabling a policy to disable NTLM may break CSV and cause the alert described before.

If the NTLM was disabled using GPO in your Active Directory Domain, identify the GPO with this setting and create an exception to this policy for all clustered Hyper-V computer objects. Alternatively you can create and link another GPO (GPO with “enable NTLM” setting) that applies just to the clustered hosts. 

 🙂

Written by IT Core

September 21, 2010 at 10:07 PM

TechEd 2010 Virtualization Sessions

leave a comment »

Here’s some interesting sessions for virtualization from TechEd.

Networking and Windows Server 2008 R2 Hyper-V: Deployment Considerations

 

Microsoft System Center Virtual Machine Manager 2008 R2: Advanced Virtualization Management

The Microsoft System Center Operations Manager Top 20 Must-Have Customizations

Microsoft System Center Operations Manager and Virtual Machine Manager: Monitoring the Service Stack

See the Largest Mission Critical Deployment of Microsoft SQL Server around the World

Check the Latest Videos from TechEd North America

Have Fun 😀

TechNet Wiki – AV Exclusion List

leave a comment »

Wouldn’t it be handy to have one place on the web where you could find an updated list of ALL the AV exclusions you might want to configure? This wiki stub topic is meant to be that list. Feel free to add to the list, it is the wiki way!  

  

Windows:
KB822158 Virus scanning recommendations for Enterprise computers that are running currently supported versions of Windows

Windows / Active Directory: 
http://support.microsoft.com/kb/822158
http://support.microsoft.com/kb/837932
http://support.microsoft.com/kb/943556

Cluster:
http://support.microsoft.com/kb/250355

Forefront: Considerations when using antivirus software on FF Edge
Products

http://support.microsoft.com/kb/943620
http://technet.microsoft.com/en-us/library/cc707727.aspx

FRS:
http://support.microsoft.com/kb/815263

SQL:
http://support.microsoft.com/kb/309422

IIS:
http://support.microsoft.com/kb/821749
http://support.microsoft.com/kb/817442

DHCP:
http://support.microsoft.com/kb/927059

SCOM / MOM:
http://support.microsoft.com/kb/975931

Hyper-V:
http://support.microsoft.com/default.aspx/kb/961804

Exchange:
Exchange 2010: http://technet.microsoft.com/en-us/library/bb332342.aspx
Exchange 2007: http://technet.microsoft.com/en-us/library/bb332342(EXCHG.80).aspx
http://support.microsoft.com/kb/328841
http://support.microsoft.com/kb/823166
http://support.microsoft.com/kb/245822
http://technet.microsoft.com/en-us/library/bb332342(EXCHG.80).aspx
http://technet.microsoft.com/en-us/library/bb332342.aspx

SharePoint:
http://support.microsoft.com/kb/952167
http://support.microsoft.com/kb/320111
http://support.microsoft.com/kb/322941

SMS:
http://support.microsoft.com/kb/327453

ISA:
http://support.microsoft.com/kb/887311

WSUS:
http://support.microsoft.com/kb/900638

SBS:
http://support.microsoft.com/kb/885685

 Med-V
Recommended Anti-Virus exclusions for MED-V client and workspace installations

System Center:
Recommendations for antivirus exclusions in MOM 2005 and Operations Manager 2007

Active Directory Federation Services 2.0 Available For Download

leave a comment »

Active Directory Federation Services 2.0 helps IT enable users to collaborate across organizational boundaries and easily access applications on-premises and in the cloud, while maintaining application security. Through a claims-based infrastructure, IT can enable a single sign-on experience for end-users to applications without requiring a separate account or password, whether applications are located in partner organizations or hosted in the cloud.

Get it Active Directory Federation Services 2.0 RTW
Read more about Federation Services

Written by IT Core

May 5, 2010 at 7:42 PM

Domain Controllers and Active Directory Domains Part 7

with one comment

Click if you want to review part 1, part 2, part 3, part 4, Part5 or part 6 of Domain Controllers and Active Directory Domains series.

“How to deploy a Read-only Domain Controller in a Windows 2003 domain”

In part 7 of this series, we’re going to discuss a new type of domain controllers, the Read-only domain controllers (RODCs).

Read-only domain controllers (RODCs) are additional domain controllers that host read-only partitions of the Active Directory database. RODCs were introduced in Windows 2008 as new feature of Active Directory Domain Services. This new type of domain controllers are the Microsoft solution to clients that had the need to deploy domain controllers at locations where security could not be 100% guaranteed (e.g. branch offices, perimeter networks). With RODCs Microsoft “offers” a solution that may help to resolve a number of security or manageability issues that existed in older operating system versions .

 So what make the RODCs so especial and what do they have that Read/Writable Domain Controllers (RWDCs) don’t? RODCs have:

  • Read-only copy of Active Directory Database. (Applications can only read data from AD database on RODCs. RODCs will forward certain write operations to writable domain controllers, and they will also send referrals to writable domain controllers when necessary).
  • RODCs have a read-only copy of the SYSVOL folder contents.
  • Unidirectional Replication (RODCs get information from WRDCs, but RWDCs do NOT get information from RODCs, this applies to both AD database and SYSVOL data).
  • Administration Role Separation (ARS) – Domain administrators can delegate both the installation and the administration of RODCs to any domain user, without granting them any additional rights in the domain and without compromising the security of the rest of the domain.
  • Credential caching. By default an RODC does not store user credentials or computer credentials, except for its own computer account and a special krbtgt account for that RODC, this means that by default all authentication requests will be forwarded by RODCs to RWDCs).
  • Password Replication Policy (PRP) – Ability to configure which passwords that are allowed to be cached in a RODC.
  • Filtered Attribute Set (FAS) – Control which attributes are not replicated to RODCs – this allows you to protect sensitive data in scenarios where RODCs are stolen or compromised.

 Active Directory prerequisites to deploy the a RODC?

  • The Forest functional level (FFL) must be set to Windows Server 2003 or higher. FFL 2003 is needed because linked-value replication (LVR) and constrain delegation are only available at this FFL or latter. This also means that all domain controllers (DCs) in the forest must have windows 2003 or later Operating system installed.
  • Before introducing RODCs in a Forest, a  writable domain controller running Windows Server 2008 or Windows Server 2008 R2 MUST exist in the same domain as the RODC. The writable domain controller must be a DNS server that has registered a name server (NS) resource record for the relevant DNS zone. RODCs must be able to replicate domain updates from a writable domain controllers running Windows Server 2008 or Windows Server 2008 R2.
  • IF you’ve a Windows Server 2003 domains, you must also run adprep /rodcprep before introducing a RODC in that Forest. Note: The infrastructure master for each domain and for each application directory partition must be available within the environment for the operation to succeed. If these requirements are not met, you may experience the symptoms described at KB 949257. Also read (Known Issues for Deploying RODCs).
  • To learn how to introduce Windows 2008/2008 R2 Domain controllers in your domain/forest, check part 6 of this series.

 Some considerations to be aware of with RODCs:

  • As discussed before, RODCs need at least one 2008 RWDC, this requirement is due the nature of RODCs context in AD. Write operations, DNs updates, Authentication (non-cached accounts), will be forwarded to RWDCs/ authoritative DNS servers. With these operations in mind is generally a good idea to have enough (more than 1) windows 2008 DC available to serve RODCs requests. To learn how to introduce Windows 2008/2008 R2 Domain controllers in your domain/forest, check part 6 of this series.
  • When a RODC that runs 2008 R2 is added to a domain that has RWDC that runs Windows Server 2008, the RODC logs Event ID 2916.This error can be disregarded, and it will not be logged if there is a RWDC that runs Windows Server 2008 R2 in the domain.
  • Cross-domain authentication will fail if the WAN is offline. RODC domain authentication for cached accounts (including User and Computer accounts) succeeds even if the WAN is offline. RODC domain authentication for accounts that are not cached will fail if the WAN is offline.
  • RODCs can only synchronize their time from a RWDCs that run Windows Server 2008, they are restricted from synchronizing with other RODCs and they are restricted from synchronizing with domain controllers outside their own domain (Client computers can synchronize time from any domain controller, including an RODC).
  • Do not use highly privileged accounts (like members of domain admins) to logon in RODCs.
  • Microsoft Exchange Server does not use RODCs. However, you can configure Outlook clients in a branch office that is serviced by a read-only global catalog server to use the read-only global catalog server for global address book lookups (Applications That Are Known to Work with RODCs).
  • Perform staged RODC Installations. The first stage of the installation (requires Domain Admin credentials) is to create an account for the RODC in AD. The second stage of the installation attaches the actual server that will be the RODC in a remote location, such as a branch office, to the account that was previously created for it. You can delegate the ability to attach the server to a non-administrative group or user.
  • When you upgrade a Windows Server 2003 domain controller it always remains a writable domain controller. You cannot make a Windows Server 2003 domain controller an RODC during the upgrade. If you want to upgrade a Windows Server 2003 domain controller and make it an RODC, you must remove Active Directory Domain Services (AD DS). You can remove AD DS either just before or just after you upgrade the operating system. After you upgrade the server and it is no longer a domain controller, reinstall AD DS and choose the RODC option during the AD DS installation.
  • You cannot convert from a full installation to a Server Core installation, or the reverse.

 Deploy RODCs:

Currently there are, at least, 2 ways to deploy RODCs, Staged installation and Direct installation.

Direct installation is the “normal” way to deploy any Domain Controller, basically you complete a full promotion of an RODC as a member of the Domain Admins group or as a member of an additional group with equivalent delegated permissions.

In this blog post I’m going to show you the Staged installation because I think that makes more sense due the nature of the RODCs security context (RODCs are normally placed at unsecure/un-trusted locations, right :)).

 The Staged Installation is divided in 2 stages:

  1. The Domain Admin prepares the Active Directory to receive the new RODC and delegates the final stage of an RODC installation to any user or group.
  2. The delegated user or group installs the RODC at the remote site and adds the RODC to the domain without the need to have a highly privileged account.

 I suggest the use of the IFM installation option in conjunction with a Staged installation (I’ll show you how during the video). Using the Install from Media (IFM) option, you can minimize the replication of directory data over the network. This helps you install additional domain controllers in remote sites more efficiently. After you create the IFM installation media for a RODC, you can secure the installation media before transporting it to the branch office by removing secrets such as user account passwords from it. If the installation media is lost or stolen while it is being transported, it cannot be compromised to reveal passwords. This is valid for RODCs because the RODC does not cache any passwords by default, they do not need to be present in the RODC installation media. 

That said, let’s check “How to deploy a Read-only Domain Controller in a Windows 2003 domain
(Note: Before introducing RODCs into 2003 domains, you must have at least 1 Windows 2008/2008R2 DC, to learn how to introduce Windows 2008/2008 R2 DCs in an existing 2003 Forest/domain check part 6 of this series).

Final Notes:
Do not use highly privileged accounts (like members of domain admins) to logon in RODCs.

– Consider the RODC installation in Windows Server Core.

– Consider the use of Bit Locker on RODCs to protect data more efficiently.

– Unless you’re using DFS Replication, any changes in the RODC SYSVOL  will not be replicated to RWDCs and this change can affect any computer that obtains Group Policy objects or logon scripts from that RODC, not only computers that are defined in the PRP.  To synchronize the contents of the SYSVOL folder again, you can make a change on a writable domain controller to force the directory or file to replicate to the RODC, or you can set the Burflags registry setting to D2, check KB315457 for more information. This behavior is by design because FRS provides limited support for read-only SYSVOL on an RODC.

– Extend the RODC FAS to include any attributes that you want to prevent from replicating to any RODC in the forest. When the attributes are prevented from replicating to RODCs, they cannot be exposed unnecessarily if an RODC is stolen or compromised. (As a best practice, make sure that the forest functional level is Windows Server 2008 or latter if you plan to configure the RODC FAS)

– Use remote management tools to administer RODCs (Microsoft Remote Server Administration Tools (RSAT) – Windows Remote Management (WinRM) protocol and Windows Remote Shell (WinRS))

Reliable time synchronization is required for Kerberos authentication. Client computers can synchronize time from any domain controller, including an RODC. An RODC can synchronize time only from a writable domain controller that runs Windows Server 2008 or later.

After 1,500 security principals are in the Allowed List and the RODC stops caching passwords, if you attempt to cache the password for a user in the Allowed List—using repadmin /rodcpwdrepl for example—you will see the following error message (Check: Administering the Password Replication Policy):
Unable to replicate secrets for user CN=user… on read-only DC dsp17a30 from full DC <GUID=126c27dc-cbb2-41b0-b847-71e5d6b69ea2>.
Error: Replication access was denied. (8453)

 Additional Documentation:
Read-Only Domain Controller Planning and Deployment Guide
RODC Technical Reference Topics
Known Issues for Deploying RODCs
Applications That Are Known to Work with RODCs
Read-only Domain Controllers Step-by-Step Guide
Understanding “Read Only Domain Controller” authentication
Read-Only Domain Controllers and Account Lockouts
KB 944043: Description of the Windows Server 2008 read-only domain controller compatibility pack for Windows Server 2003 clients and for Windows XP clients and for Windows Vista
Active Directory and Active Directory Domain Services Port Requirements
To review all video demonstrations, check video section of Active Directory Windows 2008 and 2008 R2 Documentation

Written by IT Core

April 22, 2010 at 11:59 PM

Posted in Deployment, How to..., Videos

Tagged with

Domain Controllers and Active Directory Domains Part 6

with 2 comments

If you want to review part 1, part 2, part 3, part 4 or Part5 of these series click the hyperlinks.

In part 6 of this series, we’re going to discuss “How to introduce Windows 2008 and 2008 R2 domain controllers in 2003 domains“. Windows 2008 and 2008 R2 have new features and roles, some of those were Microsoft response to their client needs/requests, the result is a great server operating system where (between others) security, stability and management were largely improved.
Before discussing how to introduce windows 2008 / 2008 R2 into 2003 domains, let’s check some of the new Active Directory features in Microsoft Windows 2008 and 2008 R2:

 Windows 2008:
– Auditing
– Fine-Grained Password Policies
– Read-Only Domain Controllers
– Restartable Active Directory Domain Services
– Database Mounting Tool
– User Interface Improvements

Windows 2008 R2, all features in windows 2008 and:
-Active Directory Recycle Bin
-Active Directory module for Windows PowerShell and Windows PowerShell™ cmdlets
-Active Directory Administrative Center
-Active Directory Best Practices Analyzer
-Active Directory Web Services
-Authentication mechanism assurance
-Offline domain join
-Managed Service Accounts

Cool!!! 🙂 In future blog posts I will show you how to use some of these new tools and how to setup some of the new features described earlier.

Before Start:
– Make sure that your forest is healthy, use diagnostic tools like repadmin, nltest, netdiag, dcdiag, etc… to diagnose the health of all existing domains, domain controllers within that forest.
– Design a good rollback plan, this can be achieved in different ways, in most  scenarios the rollback plan includes a complaint backup solution that will allow you to rollback changes if necessary. Some actions may be irreversible (e.g.: Schema upgrades) and the only way to revert them is to rollback all DCs to the state that they were before that change, and that can be a challenge if you’ve a big forest,  keep that in mind. Make sure that you test all procedures before going to production so you won’t be sorry latter… 🙂
– Make sure that the new Domain Controllers or existing ones to be upgraded have the hardware requirements for Windows 2008/2008 R2.
– Create a lab, test, test, test and test again all steps and document everything.
– If you’ve DCs running W200, make sure that SP4 is installed.
Note: To increase security, domain controllers that run Windows Server 2008 and Windows Server 2008 R2 require (by default) that all client computers attempting to authenticate to them perform Server Message Block (SMB) packet signing and secure channel signing. If your production environment includes client computers that run platforms that do not support SMB packet signing (for example, Microsoft Windows NT® 4.0 with Service Pack 2 (SP2)) or if it includes client computers that run platforms that do not support secure channel signing (for example, Windows NT 4.0 with Service Pack 3 (SP3)), you might have to modify default security policies to ensure that client computers running older versions of the Windows operating system or non-Microsoft operating systems will be able to access domain resources in the upgraded domain.
By modifying the settings of the default security policies, you are weakening the default security policies in your environment. Therefore, Microsoft recommends that you upgrade your Windows–based client computers as soon as possible. After all client computers in your environment are running versions of Windows that support SMB packet signing and secure channel signing, you can re-enable default security policies to increase security.

AD Upgrade Options:
You can upgrade your Active Directory environment in 2 different ways: Introducing new DCs with W2008/2008R2 or Performing an in-place upgrade of all existing domain controllers. From my experience you should avoid in-place upgrades when possible and use newly installed DCs, from my experience, newly installed DCs can save you a lot of headaches.
In-Place Upgrade Notes: Direct in-place upgrades from W2000 DCs to W2008 DCs are not supported, if you need to do that you must first upgrade your 2000 DC to 2003 and then to W2008. Windows 2008 R2 is a 64Bit OS, in-place upgrades are only possible in DCs with Windows 2003 64Bit installed.

Prepare the Forest and Domains:
– Check your Forest Functional Level and make sure that is set to 2000 Native or Latter. Check KB322692
– Before introducing a new DC with Windows 2008 / 2008 R2 in our existing Active Directory forest we must prepare the forest schema and each existing domain with a tool called adprep.exe:
Check the Forest Schema version , from cmd type (after running “adprep /forestprep” you should run this commands again to confirm that the forest was upgraded):
dsquery * cn=schema,cn=configuration,dc=domainname,dc=tld -scope base -attr objectVersion
or
schupgr
Additional methods to find the schema version – HERE
Update the Forest schema by running “adprep /foretsprep” from command line (Run this command at the schema master, to find the DC holding the Schema Role type from cmd: “netdom query fsmo“. This action requires a user account that is a member of the Schema Admins, Enterprise Admins, and Domain Admins groups).
After running adprep /foretsprep“, wait for replication or force replication between all existing DCs. After having all DCs in sync, go to each domain where you want to install a domain controller that runs Windows Server 2008 or Windows Server 2008 R2 and run from cmd: “adprep /domainprep /gpprep” (in the Infrastructure master)
Prepare the forest for read-only domain controllers (RODCs), if you plan to install them, by running “adprep /rodcprep” (optional).

After upgrading your Active Directory:
Be patience, wait for replication to occur between all DCs in ALL domains in the AD Forest.
Make sure that everything is working as expected, run diagnostic tools (dcdiag, nltest, repadmin, netdiag) and inspect the update logs (“Adprep.log – %SystemRoot%\Windows\Debug\ADPrep\Logs” – “Dcpromoui.log and Dcpromo.log – %systemroot%\Windows\debug”).
Consider an offline defragmentation of Active Directory Database in all existing DCs.
If everything is ok, do a backup now to guarantee all steps performed until now.
The next process is to start adding the new 2008 / 2008 R2 Domain Controllers. It’s recommended that you start at the forest root domain and then to existing child domains. If you’re doing in-place upgrades, you should start the upgrade in servers with the PDCe FSMO role for each domain. If you’re introducing new DCs with 2008/2008 R2 installed, is recommended after introducing them in each domain, you should transfer the FSMO roles to that new Domain Controllers and set the Toop Root Domain PDCe authoritative Time server for the Forest.
Once again be patience during this process, make sure that new information is replicated across all existing DCs before introducing new ones, also make sure that replication is working as expected.

Additional Notes:
– Review, update, and document the domain architecture to reflect any changes that you made during the domain upgrade process.
– Verify that the NETLOGON and SYSVOL shared folders exist and that the File Replication Service (FRS) or Distributed File Service (DFS) Replication is functioning without error by checking Event Viewer.
– Verify that Group Policy is being applied successfully by checking the application log in Event Viewer for Event ID 1704.
– Verify that all service (SRV), alias (CNAME), and host (A) resource records have been registered in Domain Name System (DNS).
– Verify Windows Firewall status.
Note: Although the default behavior for Windows Server 2008 and Windows Server 2008 R2 is that Windows Firewall is turned on, if you upgrade a Windows Server 2003 computer that had Windows Firewall turned off, the firewall will remain off after the upgrade unless you turn it on using the Windows Firewall control panel.
– Continuously monitor your domain controllers and Active Directory Domain Services.

Additional Links:
Upgrading Active Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains & from TechNet
Migrate Server Roles to Windows Server 2008 R2
ADMT Guide: Migrating and Restructuring Active Directory Domains
Windows Server 2008 R2 Migration Utilities x64 Edition
The Net Logon service on Windows Server 2008 and on Windows Server 2008 R2 domain controllers does not allow the use of older cryptography algorithms that are compatible with Windows NT 4.0 by default
How to view and transfer FSMO roles
Compact the directory database file
AD DS Backup and Recovery Step-by-Step Guide

Check the next demo for “How to deploy a Read-only Domain Controller in a Windows 2003 domain” in Part 7 of this series.

To review all video demonstrations, check video section of Active Directory Windows 2008 and 2008 R2 Documentation
🙂

Written by IT Core

April 3, 2010 at 12:01 AM

Posted in Deployment, How to..., Videos

Tagged with

Active Directory and Personal Virtual Desktops

leave a comment »

Here’s a nice article from Remote Desktop Services Team Blog, that explain de Active Directory schema requirements for virtual desktop pools and personal virtual desktops.

Microsoft’s VDI solution offers two deployment scenarios: virtual desktop pools and personal virtual desktops. Virtual desktop pools are not dependent on a specific Active Directory schema level; however, personal virtual desktops do need a Windows Server 2008 or Windows Server 2008 R2 schema.

Here are the Active Directory requirements for personal virtual desktops:

  • To deploy personal virtual desktops, your schema for the Active Directory forest must be at least Windows Server 2008. To use the added functionality provided by the Personal Virtual Desktop tab in the User Account Properties dialog box in Active Directory Users and Computers, you must run Active Directory Users and Computers from a computer running Windows Server 2008 R2 or from a computer running Windows 7 that has Remote Server Administration Tools (RSAT) installed.
  • You must use a domain functional level of at least Windows 2000 Server native mode. The functional levels Windows 2000 Server mixed mode and Windows Server 2003 interim mode are not supported.

 

Domain Controllers and Active Directory Domains Part 5

with 5 comments

If you want to review part 1, part 2, part 3 or part 4 of these series click the hyperlinks.

In Part 4 of this series we talk about Child Domains and Domain Trees. To continue our discussion on Domain Controllers and Active directory Domains, let’s check How to Create a new Domain Tree in a Remote Site.

Check the next demo for “How to introduce Windows 2008 and 2008 R2 domain controllers in 2003 domains” in Part 6 of this series.

To review all video demonstrations, check video section of Active Directory Windows 2008 and 2008 R2 Documentation

🙂

Written by IT Core

March 9, 2010 at 12:00 AM

Posted in Deployment, How to..., Videos

Tagged with

Sysinternals Updates: AdExplorer v1.3, VMMap v2.6, Disk2vhd v1.5, LiveKd v3.14, Sigcheck v1.66

leave a comment »

AdExplorer v1.3: This update to AdExplorer, an Active Directory editor, has major node expansion performance improvements and a number of minor bug fixes.

VMMap v2.6: VMMap, a powerful process virtual and physical memory analysis tool, now shows both graphical and numeric breakdowns of private virtual memory, as well as heap configuration flags.

Disk2vhd v1.5: Disk2Vhd v1.5 works with Hyper-V SCSI direct-attached volumes and reports an error when a snapshot includes offline volumes.

LiveKd v3.14: This version of LiveKd has better detection of the Debugging Tools package installation and launches the debugger in a mode that skips the unnecessary root-cause analysis of the virtual dump file.

Sigcheck v1.66: This update to Sigcheck, a file version and signature checking utility, fixes a bug in the certificate revocation check logic.

From Sysinternals

Domain Controllers and Active Directory Domains Part 4

with 8 comments

If you want to review part 1, part 2 or part 3 of these series click the hyperlinks.

In Part 4 (“a” & “b“) I’ll show you “How to create a child domain in a remote site” additionally I’ll also show you “How to pre-configure the DNS Zones and Delegations for a child domain“. This pre-configurations tasks are useful when you’re running older versions of Windows (2000/2003). In Windows 2008 R2 those DNS pre-configurations are not mandatory nor necessary because Dcpromo.exe will take care of all necessary configurations for you.

As stated in What Are Domains and Forests & Domains and Forests Technical Reference
Domains and Forests are logical representations of the directory hierarchy in Active Directory.

Forests:
A forest is a complete instance of Active Directory. Each forest acts as a top-level container in that it houses all domain containers for that particular Active Directory instance. A forest can contain one or more domain container objects, all of which share a common logical structure, global catalog, directory schema, and directory configuration, as well as automatic two-way transitive trust relationships. The first domain in the forest is called the forest root domain.

Domains:
Each Domain is a container for a collection of administratively defined objects that share a common directory database, security policies, and trust relationships with other domains. In this way, each domain is an administrative boundary for objects.

Tree Root and Child Domains:
A domain tree represents a unique DNS namespace: it has a single root domain, known as the tree root domain, and is built as a strict hierarchy: Each domain above the tree root domain has exactly one superior, or parent, domain (the forest root domain). The namespace created by this hierarchy, therefore, is contiguous — each level of the hierarchy is directly related to the level above it and to the level below it. In other words, the names of domains created beneath the tree root domain (child domains) are always contiguous with the name of the tree root domain. The DNS names of the child domains of the root domain of a tree reflect this organization; therefore, the children of a root domain called Somedomain are always children of that domain in the DNS namespace (for example, Child1.somedomain, Child2.somedomain, and so forth).

Multiple domain trees can belong to a single forest and do not form a contiguous namespace; that is, they have noncontiguous DNS domain names. Although the roots of the separate trees have names that are not contiguous with each other, the trees share a single overall namespace because names of objects can still be resolved by the same Active Directory instance. A forest exists as a set of cross-reference objects and trust relationships that are known to the member trees. Transitive trusts at the root domain of each namespace provide mutual access to resources.
The domain hierarchy in a forest determines the transitive trust links that connect each domain. Each domain has a direct trust link with its parent and each of its children. If there are multiple trees in a forest, the forest root domain is at the top of the trust tree and, from a trust perspective, all other tree roots are children. That means authentication traffic between any two domains in different trees must pass through the forest root.

 
That said, here are some tips that you may need to consider before starting to think about additional domains within your forest:
– The First created Domain will ALWAYS be the ROOT Domain. It doesn’t matter if you rename it (only possible if your FFL is at 2003 or later) or if you move other domains within your forest logical structure.
– The ROOT domain is very important to the entire forest (this includes all existing domains) because it contains unique objects (for example: The Enterprise Admins and Schema Admins groups are located in this domain) and because by hierarchical design all domains will depend of the ROOT domain. This means that if you lose the forest ROOT domain , you’ll lose the entire forest logical structure. This also applies to to child domains and their parent domains.
– Each Domain should have at least 2 DCs (at minimum).
– When security boundaries are needed you need a second forest not a child domain nor a new Root Tree domain. Only forests are security Boundaries NOT Domains. Active Directory domains, unlike Windows NT domains, are always part of a forest, and they are not themselves the security boundary. For Windows 2000 and later networks, though, domains are the boundaries for administration and for certain security policies, such as password complexity and password reuse rules (Note: this has changed in Windows 2008 with Fine-Grained Password Policies), which cannot be inherited from one domain to another. Each Active Directory domain is authoritative for the identity and credentials of the users, computers, and groups that reside in that domain. However, service administrators have abilities that cross domain boundaries. For this reason, the forest is the ultimate security boundary, not the domain.
In most scenarios child domains or new Tree Root domains are created by the wrong reasons.
– Some reasons to create Multiple Domains: Meet security requirements, Meet administrative requirements, Optimize replication traffic, Retain Microsoft Windows NT domains. Do not create multiple domains to accommodate polarized groups or for isolated resources that are not easily assimilated into other domains. Both the groups and the resources are usually better candidates for organizational units (OUs).
When determining whether to create multiple Domains, keep the following items in mind:
– DNS structure becomes more complex.
– Hardware cost Increases.
– Each time a domain is added, a Domain Admins pre-defined global group is added as well. More administration is required to monitor the members of this group.
– Security principals. As domains are added, the likelihood that security principals will need to be moved between domains becomes greater. Although moving a security principal between OUs within a domain is a simple operation, moving a security principal between domains is more complex and can negatively affect users.
– Group policy and access control. Because group policy and access control are applied at the domain level (Note: in Windows 2008 Fine-Grained Password Policies can be applied at lower level), if your organization uses group policies or delegated administration across the enterprise or many domains, the measures must be applied separately to each domain.
– Domain controller hardware and security facilities. Each Windows Server 2003 domain requires at least two domain controllers to support fault-tolerance and multimaster requirements. In addition, it is recommended that domain controllers be located in a secure facility with limited access to prevent physical access by intruders.
– Trust links If a user from one domain must log on in another domain, the domain controller from the second domain must be able to contact the domain controller in the user’s original domain. In the event of a link failure, the domain controller might not be able to maintain service. More trust links, which require setup and maintenance, might be necessary to alleviate the problem.

That Said, let’s check the videos:

Domain Controllers and Active Directory Domains Part 4.a
 

Domain Controllers and Active Directory Domains Part 4.b
 

Check the next demo for “How to Create a new Domain Tree in a Remote Site” in Part 5 of this series.

To review all video demonstrations, check video section of Active Directory Windows 2008 and 2008 R2 Documentation

🙂

Written by IT Core

February 17, 2010 at 10:20 PM

Posted in Deployment, How to..., Videos

Tagged with

Active Directory Windows 2008 and 2008 R2 Documentation

with 8 comments

Here are some documents that may help you with some specific Active Directory tasks
(I’ll try to keep this list updated).

Global:
Changes in Functionality from Windows Server 2003 with SP1 to Windows Server 2008
Changes in Functionality in Windows Server 2008 R2 and from TechNet
Active Directory Design Guide
AD DS Deployment Guide
AD DS Installation and Removal Step-by-Step Guide
Active Directory Domain Services – Technet & Operations Guide.doc
Running Domain Controllers in Hyper-V

Licensing
Windows Server 2008 R2 Licensing Overview
Licensing Microsoft Server Products in Virtual Environments white paper

DNS:
DNS Step-by-Step Guide
DNSSEC Deployment Guide

Migration/Upgrade:
Upgrading Active Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains & from TechNet
Migrate Server Roles to Windows Server 2008 R2
ADMT Guide: Migrating and Restructuring Active Directory Domains
Windows Server 2008 R2 Migration Utilities x64 Edition

Read Only Domain Controllers:
Read-Only Domain Controllers (RODC) Branch Office Guide and from TechNet
Read-Only Domain Controllers (RODC) in the Perimeter Network
Read-only Domain Controllers Step-by-Step Guide from TechNet
Read-only Domain Controllers Known Issues for Deploying RODCs
Read-Only Domain Controllers Planning and Deployment Guide

Firewall:
Active Directory and Active Directory Domain Services Port Requirements
Service overview and network port requirements for the Windows Server system
How to configure a firewall for domains and trusts
How to restrict FRS replication traffic to a specific static port
Restricting Active Directory replication traffic and client RPC traffic to a specific port
Active Directory Domain Services in the Perimeter Network (Windows Server 2008)
Active Directory in Networks Segmented by Firewalls (Windows Server 2003)

Security/Delegation:
How to Delegate Basic Server Administration To Junior Administrators
Best Practice Guide for Securing Active Directory Installations.doc
Active Directory Domain Services in the Perimeter Network (Windows Server 2008)
Windows 2000 Security Event Descriptions (Part 1 of 2)
Windows 2000 Security Event Descriptions (Part 2 of 2)
Description of security events in Windows Vista and in Windows Server 2008
Description of security events in Windows 7 and in Windows Server 2008 R2

How to use Group Policy to configure detailed security auditing settings KB 921469
Security Auditing Windows Server 2008, Windows Server 2008 R2 TechNet

Backup/Recover:
Recovering Your Active Directory Forest
How to restore deleted user accounts and their group memberships in Active Directory KB840001
How to restore deleted user accounts and their group memberships in Active Directory
Best practices around Active Directory Authoritative Restores in Windows Server 2003 and 2008
The importance of following ALL the authoritative restore steps

Others:
The Net Logon service on Windows Server 2008 and on Windows Server 2008 R2 domain controllers does not allow the use of older cryptography algorithms that are compatible with Windows NT 4.0 by default – KB942564

Videos:
Domain Controllers and Active Directory Domains Series

How to introduce the First Domain Controller in Active Directory Domain
How to create the second domain controller in Active Directory
How to add a Domain Controller in a Remote Site using the new Windows 2008 R2
How to create a child domain in a remote site
How to Create a new Domain Tree in a Remote Site
How to introduce Windows 2008 and 2008 R2 domain controllers in 2003 domains
How to deploy a Read-only Domain Controller in a Windows 2003 domain

Written by IT Core

February 6, 2010 at 3:34 PM

Domain Controllers and Active Directory Domains Part 3

with 9 comments

If you want to review part 1 and part 2 of these series click in the hyperlinks.

As discussed in  part 2 of these series, having more than 1 DC per domain is a good bet, but what about remote sites? Should we have a Domain Controller for remote sites?

Well… The answer may differ from scenario to scenario. You may want to consider your real needs before invest money in a new DC to serve a given remote site, some of those question would be:

How many users are in that site? Do I have a reliable connection between my Main Site and that remote office? What applications are users using to perform their job in that site? Are those applications Active Directory dependent? If my WAN link crashes, can my company afford to have those users waiting for the WAN connection repair? If I introduce a Domain Controller in that Site, will I have advantages? What is the price to maintain a Domain Controller in that Site? Is that remote site a trusted site to have a Domain Controller in it? Do I have IT people in that Site? Will I need IT people in that site after I add a Domain Controller in it?

These are a few questions that you may need to consider before invest money in a domain controller for a remote site. In part 3 of this series I will NOT talk about design/planning considerations for Active Directory Domains, but I’ll show you an example of “How to add a Domain Controller in a Remote Site using the new Windows 2008 R2“.

In this demonstration, we’ll see how to set up additional Active Directory Sites and assign subnets, we’ll also see how to configure IPSiteLink replication intervals and how to set up replication schedule availability. I really hope that you enjoy it, have a look:

Check the next demo for  “How to create a child domain in a remote site” in Part 4 of this series.

To review all video demonstrations, check video section of Active Directory Windows 2008 and 2008 R2 Documentation

🙂

Written by IT Core

February 4, 2010 at 10:33 PM

Posted in Deployment, How to..., Videos

Tagged with

Domain Controllers and Active Directory Domains Part 2

with 12 comments

After the “How to create the first domain controller in Active Directory Part1”, it’s time to consider an additional domain controller to your domain.

Why should you to consider that?

Redundancy: If you have more than one DC for a given domain you can provide better redundancy for users, computers and apps. Apart to active directory redundancy, you may also have additional roles in those DCs that you want to keep available in case of a DC failure or DC overload. Roles commonly used in DCs are DNS server role and the Global Catalog.

Workload distribution: With multiple DCs you can “load balance” requests from users, apps, computers, etc… This is particularly important when those services/servers are across sites over WAN links, when that happens you can place a DC or more on those sites and take advantage of local authentication/requests without having them across the WAN link.

Domain hierarchy: The first domain that is created is the Root Domain of the forest. If you lose that domain you lose the entire forest. In a scenario where you have multiple domains within a forest, if you have only one DC for that top Root Domain and you lose that DC forever, you may say goodbye to your entire forest. Hum… that’s not good is it?!! As you already guessed domain hierarchy is very important in Active Directory.

Recovery/Availability: Consider the following scenario. Your DC suffers a hardware failure, and to recover from that hardware failure you’ll have to wait some time. If you have only one DC, you may have a problem, the domain apps may need that DC and may stop working until that DC is back online again, the users that use those apps will also stop working and your company will lose money because of that down time. Anyway, you recover that DC from hardware failure, but then you discover that the DC cannot start (BSoD-More down time), no problem (you think), you start the Backup Recovery process, but you discover that the backup isn’t enough to recover that DC. Now you’ve a big problem, no one is working and the company isn’t making money because that. Everyone will have to wait until you replace the domain controller with a new one. With a second DC, you can reduce that problem, and the dead DC could be replaced easily without affecting users or apps that depend on it.

And if I lose both DCs?
It’s true, you can lose both DCs and you’ll be “dead” anyway, but that is another story with a different planning to a different blog post. The point that I’m trying to make clear is with 2 DCs per domain “at the minimum” you will get a good chance to recover from down times (with good percentage of success) plus better redundancy and distributed workload. I could give you a lot more reasons to have additional DCs, but keep those in mind and hopefully they should be enough to make you think twice before consider only one DC for your Domain.

Ok, back to the beginning, How to create the second domain controller in Active Directory. Actually is a very simple process, we just need to have healthy domain (run dcdiag tools to check if everything is ok), and if everything is working correctly you are ready to add the 2nd DC to your domain.

Before start:
Plan carefully your FQDN of the domain controller, make sure that follow the rules of your internal company documentation. Although it’s possible to rename DCs that are running Windows 2003 and latter, I would rather do it correctly at first time preventing latter changes. Check the Naming conventions at Microsoft KB909264.

Configure your NIC with a static IP address. Avoid the use of multiple NICs in DCs, this type of configuration may lead to errors and Active Directory communication might fail on multihomed domain controllers, check MS KB272294 and 191611 for more information.

Make sure that the Administrator account has a strong password. If possible, avoid using the Administrator account and use a dedicated account to perform your everyday work in AD. Think in Administrator account as the SOS account, and try to use it only for emergency situations.

You must have at least one drive formatted with NTFS.

Install the latest updates from Microsoft website.

Check your event log for errors and correct them before proceed.

Plan and test the Backup strategy for your Active directory Forest. After that take a full backup of the existing DC in case that you need to rollback.

At last check the date and time settings, make sure that are correct, and make sure that the existing DC is in sync with a trusted and valid authoritative time server. By Default the DC that holds the PDCe will be (by default) the authoritative time server for your forest and additional DCs will sync their time with this DC.

Don’t miss Part 3 – “How to add a Domain Controller in a Remote Site using the new Windows 2008 R2

To review all video demonstrations, check video section of Active Directory Windows 2008 and 2008 R2 Documentation

🙂

Written by IT Core

January 20, 2010 at 10:08 PM

Posted in Deployment, How to..., Videos

Tagged with

Domain Controllers and Active Directory Domains Part 1

with 9 comments

In this blog post I’ll show you an example of How to introduce the First Domain Controller in Active Directory Domain. This will be the first of many other blog posts that will help you with domain controllers configuration and related services across your forest, I’ll also show you how to introduce new domains and different ways to perform identical tasks. Let’s start qith a quick review about Domain Controllers basics:

A Domain controller (DC) is a server role that has the Active Directory service installed. Domain controllers have a database called “NTDS.dit” that stores information about Active Directory objects. This database is divided in different partitions. Domain partition has all information about the domain where that DC is located and is replicated between all DCs within the same domain, each DC has read/write permission to the domain partition. Schema and Configuration directory partitions that are common to the entire forest and replicated between all Domain Controllers within the same forest, it doesn’t matter if they belong to the same Domain or not, as long as they are in the same Forest they’ll need to have a Schema and Configuration directory partitions (which are only writable by their FSMO masters) + Domain Partition for the domain where the DCs were configured. Depending of the version that you’re running, DCs can also store one or more application directory partitions (this applies to Windows 2003 and later OS).

In addition to Active Directory database, DCs can also hold specific roles needed by Active Directory:
Flexible Single Master OperationFSMO” (pronounced Fiz-mo). Domain controllers that hold operations master roles are designated to perform specific tasks to ensure consistency and to eliminate the potential for conflicting entries in the Active Directory database. Active Directory defines 5 operations master roles (2 are Forest wide and the other 3 exist in each domain):

Forest operation masters:
– Schema master
– Domain naming master

Domain operation masters:
-Primary domain controller emulator (PDCe)
-Infrastructure master (IM)
-Relative ID master (RID)

Global Catalog (GC). A global catalog server is a domain controller that, in addition to its full writable domain directory partition replica (does not apply to RODC), also stores a partial, read-only replica of all other domain directory partitions in the forest. The attributes that are replicated to the global catalog are identified in the schema as the partial attribute set (PAS).
GCs are needed when: doing forest wide searches, User logons (when more than one domain exists in that forest), when a user principal name (UPN) is used at logon and the forest has more than one domain, to cache the user membership when is member of a Universal Group (Universal groups are only available when the domain is native mode or later), Exchange Address Book lookups and exchange clients also use global catalog servers to access the global address list (GAL). These are the most common scenarios, but you can also have specific apps that need to contact the GC to function properly.

DNS: Although DNS is not a component of Active Directory, Active Directory uses DNS as its domain controller location mechanism and leverages the namespace design of DNS in the design of Active Directory domain names. Is possible to have a non-Microsoft DNS solution to support Active Directory, but the DNS server must support service resource records (RFC 2782) and dynamic update protocol (RFC 2136). Active Directory uses DNS as the location mechanism for domain controllers, enabling computers on the network to obtain IP addresses of domain controllers. During the installation of Active Directory, the service (SRV) and address (A) resource records are dynamically registered in DNS. Both types of records are necessary for the functionality of the domain controller locator (Locator) mechanism among other functions.

That being said, now it’s time to setup of the First Domain Controller.

Before start:
· Plan carefully your FQDN (fully qualify domain name), the NetBIOS name and the Domain controller name, this is very important to avoid changes that may crash your entire forest later. Check the Naming conventions at Microsoft KB909264.
· Configure your NIC with a static IP address. Avoid the use of multiple NICs in DCs, this type of configuration may lead to errors and Active Directory communication might fail on multihomed domain controllers, check MS KB 272294 and 191611 for more information.
· Configure the Administrator account with a strong password.
· Install the latest updates from Microsoft website.
· You need to have at least one hard drive formated with NTFS.
· Check your event log for errors and correct them before proceed.
· Consider the use of at least 2 DCs for each domain that you plan to have in your forest, this will give you better redundancy but also a fastest way to recover from server failures.
· Plan and test the Backup strategy for your Active directory Forest.
· At last check the date and time settings, make sure that are correct, and make sure that the server is in sync with a trusted and valid authoritative time server. By Default the first DC will be the authoritative time server for your forest and additional DCs will sync their time with this DC.

Now it’s time to install Active directory in your server, check the video and follow the steps bellow:

Check the next article : How to create the second domain controller in Active Directory

To review all video demonstrations, check video section of Active Directory Windows 2008 and 2008 R2 Documentation

🙂

Written by IT Core

January 19, 2010 at 11:34 PM

Posted in Deployment, How to..., Videos

Tagged with

Updated Read-Only Domain Controller (RODC) Branch Office Guide

leave a comment »

Planning for RODC?
Before any implementation have a look at this updated guide at:

RODC) Branch Office Guide
or using
Technet

This guide describes new features in Windows Server 2008 that can provide benefits for Active Directory deployments that include branch offices. It explains how to assess an existing deployment of domain controllers in branch offices to determine whether deploying read-only domain controllers (RODCs) in existing or future branch offices is appropriate for your organization. For more general information about how to install and configure an RODC, see Planning and Deploying Read-Only Domain Controllers. For more information about deploying an RODC in a perimeter network (also known as DMZ), see Active Directory Domain Services in the Perimeter Network (Windows Server 2008).

Written by IT Core

January 15, 2010 at 12:23 AM