Step By Step Installing AD LDS on Windows 2008 Member Server.

 

In this post we will be installing Active Directory Lightweight Directory Services, previously known as ADAM.

Member Server of hostname DL-LDS is joined to fictitious domain resrc.vrnmyp.net. The forest root domain is vrnmyp.net

We have used resrc\Administrator account to install AD LDS on DL-LDS server. A service account can be used instead of Administrator account of domain resrc.vrnmyp.net. By default AD LDS use the following port for its operation.

Port 389 for LDAP and 636 for secure LDAP, these ports can be changed however you need to get necessary ports open on windows server and firewall wall.

To start with let’s begin with installation of AD LDS. The document is created using screenshots which are quite self-explanatory. The process has been simplified however detail information can be found on technet.microsoft.com if required.

  1.       Click on Start > Administrative Tools > Server Manager.

2.       Select Roles and Click on Add Roles

3.       Under Roles select Active Directory Lightweight Directory Services. If you don’t have .net framework 3.5 installed then you will be prompted to add .net framework 3.5. Click on Add Required Features.

4.       Click on Install to proceed.

5.       AD LDS will be installed and will be available under Start > Administrative Tools> Active Directory Lightweight Directory Services Setup Wizard. This wizard helps to create AD LDS instances.

 

 

 

6.       Specify an instance name and its description. A service by the name of ADAM_InstanceName will be available under windows services console. This service will be used to start/stop AD LDS instance.

 

7.       The default ports will be populated by itself, update the port numbers if you want to use a different port.

8.       To better manager AD LDS we will create Application Partition. Specify the distinguished Name of application partition

9.       Here you have choice to use service account and it will be granted administrative permissions over AD LDS instance that we are creating. We have used domain\Administrator account instead in this example.

 

10.   Click on Next, now we are presented with Importing LDIF Files. These are default LDIF files which come along with AD LDS binaries. Each LDIF file contains Classes and Attributes which will be imported into the schema of AD LDS. In this scenario we have selected all of the LDIF files except MS-AzMan.LDF. Click on Next twice to trigger the installation.

Below is the brief description about function of each LDIF file.

 

 

.ldf file	User classes	Import this file if ...
MS-ADAM-DisplaySpecifiers-0409.LDF	o    Not applicable	You want to use an Active Directory snap-in (such as Active Directory Sites and Services) with AD LDS.
MS-AdamSyncMetadata.LDF	o    Not applicable	You want to use adamsync to synchronize AD LDS with Active Directory Domain Services (AD DS).
MS-AZMan.LDF	o    Not applicable	You want to use Windows Authorization Manager with AD LDS.
MS-InetOrgPerson.LDF	o    Person o    Organizational-Person o    User o    inetOrgPerson	You want to create user objects in the AD LDS directory, and you want to create users of the InetOrgPerson class (as defined in RFC 2798). MS-InetOrgPerson.LDF is a sample file that you can modify to meet your particular requirements.
MS-User.LDF	o    Person o    Organizational-Person o    User	You want to create user objects in the AD LDS directory, but you do not want to create users of the InetOrgPerson class (as defined in RFC 2798). MS-User.LDF is a sample file that you can modify to meet your particular requirements.
MS-UserProxy.LDF	o    User-Proxy	You want to create simple proxy objects in AD LDS for use in bind redirection. MS-UserProxy.LDF is a sample file that you can modify to meet your particular requirements.
MS-UserProxyFull.LDF	o    User-Proxy-Full	You want to create complete proxy objects in AD LDS for use in bind redirection. To use this file, you must also import MS-InetOrgPerson.LDF or MS-User.LDF. MS-UserProxyFull.LDF is a sample file that you can modify to meet your particular requirements.

 

 

 

 

 

Accessing Internet through RRAS

RRAS [Routing and Remote Access Service] provides Multiprotocol LAN-to-LAN, LAN-to-WAN, virtual private network [VPN], Dial-up and NAT [network address translation] service.

We would use RRAS server to give internet access to our internal clients sitting on private network.
The RRAS server would be in a workgroup with two NIC. One is connected to Public Interface or internet facing NIC and second Private NIC connecting to the Private Network where our rest of the machines are present.

In this setup we have an internet Modem connected to Router which is NATting the IP address. The external NIC on RRAS server will have private IP address although it can be used to access internet and hence called Internet facing NIC.

We would be statically assigning the IP address to the Internal and External NIC on RRAS server.

1. Under Hyper-v manager, make sure Gateway Hyper-v machine is shutdown.

2. Make a right click on the Gateway Hyper-V and click on settings. Click on Add Hardware and on right hand side select Network Adapter and click Add.


3. Select the Network Adapted that is just added. From Network drop down select the External Switch and specify the static MAC address. The MAC address will populate itself. Click Apply and Ok.



4. Make Right click on Gateway Hyper-V and Click Start to turn on Hyper-V machine.

5. Login to the Hyper-V machine. If the hostname hasn’t been configured earlier, configure it now. You can do it via Server Manager.

6. Click on Start > Administrative Tools > Server Manager

7. Select Server Manager at Top. On right hand side, click on Change System Properties to change the Hostname of the server.

8. Click on View Network connections. For better understanding rename the network adapters to Private and Public. Select the network adapter, right click and select rename.

9. Assign Static IP address to Public and Private IP address. Select the Public NIC, right click, properties. Select Internet Protocol Version 4 (TCP/IPv4), click on properties and set the address

Public [the address can be different based on your environmnet]
IP: 10.0.0.198
Netmask: 255.0.0.0
Default Gateway: 10.0.0.1
DNS: 10.0.0.1

Private [NIC connecting to Internal private network]

IP: 192.168.0.1
Netmask: 255.255.255.0
Leave Default Gateway and DNS blank, click on Ok and Apply. Ignore the warning messages.
Installing and Configuring RRAS Role

1. Click on Start > Administrative Tools > Server Manager

2. Select Roles, Click on Add Roles, Select Network Policies and Access Services [RRAS is present under NPAS], Click Next

3. Click Next on Information Page and Select Routing and Remote Access Services



4. Click on Next, Click on Install and Click on Finish.

5. Click on Start > Administrative Tools > Routing and Remote Access. This will bring RRAS console

6. Select the server [hostname(local)]. Notice that Server has red down arrow which means that RRAS is not enabled and configured. Make a right click on it and Select Configure and Enable Routing and Remote Access. This will launch wizard. Click on Next

7. Select Custom Configuration, click Next.

8. Select LAN Routing and NAT and click Finish. Click on Start Service when prompted. This will configure the RRAS server and start the RRAS service. Notice that RRAS server will have a green up arrow denoting that server is enabled and configured.

9. Expand IPv4, Select NAT, make a right click on it and select New Interface. Select Public and click OK.



10. You will be prompted to Select Interface type. Select Public Interface connected to Internet and Select Enable NAT on this Interface. Click OK.



11. We are done now. Now our machines on Private NIC will be able to access Internet using RRAS server as a Gateway.

How Terminal Services Licensing Works

All communication during the licensing process occurs between the client and the terminal server, and between the terminal server and the license server. The terminal server client never communicates directly with the license server.

When a client device attempts to connect to a terminal server in Per Device mode, the terminal server determines if the client has a license token. Terminal server clients store license tokens in the following registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\MSLicensing

If a client has no license token, the terminal server attempts to contact a license server from its list of discovered license servers. If no contact is made, the terminal server restarts the discovery process. If no license server responds, the device can not connect to the terminal server unless it is operating within the terminal server grace period.

When a license server responds, the terminal server requests a temporary token for the device because this is the first time the device has connected to a terminal server. The terminal server then pushes this temporary token to the device. After a user has provided valid credentials resulting in a successful logon, the terminal server instructs the license server to mark the issued temporary token as validated.

The next time a user attempts to connect to a terminal server in Per Device mode from this device, the terminal server requests a Windows Server 2003 TS Device CAL token for this device. If the license server has available TS Device CAL tokens, the license server removes one token from the available pool, marks it as issued to the device, logs the device name, the user name of the device, and the date issued, and then pushes this TS Device CAL token to the device.

If the license server has no TS Device CAL tokens, it will first look to any other license server in its domain, workgroup, or site. License servers maintain information about where other accessible license servers exist, and if they have license tokens. If another license server is accessible that does have inventory, the first license server will request a license token from the second license server and deliver it to the terminal server, which then passes the token to the client device. If there are no available TS Device CAL tokens, the device will continue to connect with the temporary token.

Temporary tokens allow devices to connect for 90 days, and will then expire. TS Device CALs, while representing perpetual licenses, are set to expire 52-89 days from the date they are issued. The terminal server always attempts to renew these tokens 7 days prior to their expiration. The purpose of this system is to recover TS Device CAL tokens that are lost due to events such as hardware failure or operating system reinstallation.

Client License Distribution Per User
When a terminal server is configured in Per User mode, the terminal server must be able to locate a license server after the grace period has expired. While it is possible to install TS Per User CAL tokens on a license server, there is currently no method of assigning a TS Per User CAL token to a particular user account.

Setting up Secure FTP with FTP 7.5

Hi,

Secure FTP also known as FTPS or to be particular FTPES [Explict SSL]. Recently I have done a project for one of the clients helping him setup FTPES.

Following is the download-able word document specifying
How To Setup FTPES

Network Load Balance Clusters in Windows Server 2008 R2

Today we going to look setup Network Load Balanced Clusters in Windows Server 2008 R2. NLB provides high availabilty and scability for IP based traffic for TCP, UDP and GRE (General Routing Encapsulation). In server 2008 you can build NLB cluster with two node/host with max upto 32 nodes/hosts.

The four basic Network Load Balancing modes are as follows:

·         Unicast with Single Network Adapter - The MAC address of network adapter is disabled and the cluster MAC address is used. Traffic is received by all nodes in the cluster and filtered by the NLB driver. Nodes in the cluster are able to communicate with addresses outside the cluster subnet, but node to node communication within cluster subnet is not possible.

·         Unicast with Multiple Network Adapters - The MAC address of the network adapter is disabled and the cluster MAC address is used. Traffic is received by all nodes in the cluster and filtered by the NLB driver. Nodes within the cluster are able to communicate with each other within the cluster subnet and also with addresses outside the subnet.

·         Multicast with Single Network Adapters - Both network adapter and cluster MAC addresses are enabled. Nodes within the cluster are able to communicate with each other within the cluster subnet and also with addresses outside the subnet. Not recommended where port rules are configured to direct significant levels of traffic to specific cluster nodes.

·         Multicast with Multiple Network Adapters - Both network adapter and cluster MAC addresses are enabled. Nodes within the cluster are able to communicate with each other within the cluster subnet and also with addresses outside the subnet. This is the ideal configuration for environments where there are significant levels of traffic directed to specific cluster nodes.

Now Lets start building our NLB. Install Network Load Balancing Feature using Server Manager.
Once the feature is installed we would be adding Nodes to the clusters

Add Cluster IP

Client affinity involves the tracking of both destination port and source IP address information to optionally ensure that all traffic to a specific port from a client is directed to the same server in the cluster. The available Client affinity settings are as follows:

• Single - Requests from a single source IP address are directed to the same cluster node.
• Network - Requests originating from within the same Class C network address range are directed to the same cluster node.
• None - No client affinity. Requests are directed to nodes regardless of previous assignments.

Additional considerations
Multicast—Multicast mode allows communication among hosts because it adds a Layer 2 multicast  address to the cluster instead of changing the cluster. Communication among hosts is possible because the hosts retain their original unique media access control (MAC) addresses and already have unique, dedicated IP addresses. However, the address resolution protocol (ARP) reply that is sent by a host in the cluster (in response to an ARP request) maps the cluster’s unicast IP address to its multicast MAC address. Some routers do not support the resolution of unicast IP addresses to multicast MAC addresses, and they discard the ARP reply.

As a result, an administrator must add a static ARP entry in the router, mapping
the cluster IP address to its MAC address.
 

The cluster operation mode parameters specify whether a multicast media access control (MAC) address should be used for cluster operations. If multicast is enabled, NLB converts the cluster MAC address for the cluster adapter into a multicast address. It also ensures that the cluster's primary IP address resolves to this multicast address as part of the Address Resolution Protocol (ARP). The adapter can now use its original, built-in MAC address that was disabled in unicast mode.

You must first enable multicast support before enabling Internet Group Management Protocol (IGMP) support. IGMP support can also be enabled on the network adapter.

The IGMP multicast check box enables IGMP support for limiting switch flooding by limiting traffic to "Network Load Balancing ports" only. That is, enabling IGMP support ensures that traffic intended for an NLB cluster passes through only those ports serving the cluster hosts and not all switch ports.

Additional Consideration for the NLB cluster

When you create an NLB cluster, NLB is automatically bound to each of the network adapters in the cluster.

When you add additional hosts after the first host is added, the subsequent hosts will automatically inherit the cluster port rules from the initial host.

The new cluster host will not immediately be in a running state in the cluster. The new host settings must first be circulated through all cluster hosts.

DC GC Service Records

Domain Controller-Specific Records

Mnemonic        Type    DNS Record     
LdapIpAddress   A       <DnsDomainName>
Ldap    SRV     _ldap._tcp.<DnsDomainName>     
DcByGuid        SRV     _ldap._tcp.<DomainGuid>.domains._msdcs.<DnsForestName> 
Kdc     SRV     _kerberos._tcp.dc._msdcs.<DnsDomainName>       
Dc      SRV     _ldap._tcp.dc._msdcs.<DnsDomainName>   
Rfc1510Kdc      SRV     _kerberos._tcp.<DnsDomainName> 
Rfc1510UdpKdc   SRV     _kerberos._udp.<DnsDomainName> 
Rfc1510Kpwd     SRV     _kpasswd._tcp.<DnsDomainName>  
Rfc1510UdpKpwd  SRV     _kpasswd._udp.<DnsDomainName>  

Global Catalog-Specific Records

Mnemonic        Type    DNS Record     
Gc      SRV     _ldap._tcp.gc._msdcs.<DnsForestName>   
GcIpAddress     A       gc._msdcs.<DnsForestName>      
GenericGc       SRV     _gc._tcp.<DnsForestName>       

Where are the GPO logs?

Client Log Files
Log files can be generated by the core client engine (Userenv) and by every CSE except the Scripts CSE. Scripts processing is logged in the Application log on the client with source=UserInit. Use Event Viewer to view the Application log on the client, or look for these entries on the Policy Events tab of the Group Policy Results report.
The Policy Events tab in Group Policy Results reports generated in GPMC displays the Group Policy–related events that you would see if you used Event Viewer to view these events in the Application log on the client for which you generated the report.
The following table lists several log files you can generate at the client that relate to Group Policy troubleshooting.
Client Log Files for Troubleshooting Group Policy

Note   The UserEnv logs entries pertaining to profiles as well as Group Policy core processing and registry (.adm) processing on the client. The entries pertaining to profiles are intermingled with the Group Policy entries and not easily distinguished from them. Use Wilogutl.exe to analyze the Windows Installer log files. For more information, see Wilogutl.exe on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkID=16156).  
Server Log Files
You can enable logging of events generated by the Group Policy Object Editor on the Server. There are two different log files, one for events relating to core Group Policy processing and the registry CSE, and another for events relating to all other CSEs.
The following table lists several log files you can generate at the server that relate to Group Policy troubleshooting.

Userenv Logging
Because Userenv tracks the Group Policy engine and registry-based Group Policy, it is the most frequently used log file for Group Policy troubleshooting. Userenv is especially useful in a Windows 2000 environment because you don't have the benefit of using Resultant Set of Policy (RSoP). Most of the questions that RSoP answers, are in the userenv log.
To use userenv.log you need to first enable verbose logging.
To enable verbose logging

1. Log onto the client computer as the administrator and run Regedit.
2. Locate the following key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon.
3. Right click Winlogon, select New, and then click DWORD Value.
4. Enter the following name for the DWORD Value: UserEnvDebugLevel.
5. Enter 30002 as the hexadecimal value. This writes the userenv into userenv.log, located in the \%windir%\debug directory.
6. Run "gpupdate /force" to ensure a full listing of total Group Policy processing.

Setting up Cross Forest Trust between W2K3 R2 and W2K8 R2

Hi All,

Today we will be looking into Setting Up Cross Forest Trust between Top-level domains in two different forest. Before we start we need start we need to get some components in place so that we can successfully setup Cross Forest Trust.

Name Resolution : We must be able to resolve names across forest for that Purpose we need to setup our DNS so that it will be able resolve. There are multiple ways in which you can setup your DNS to do Name Resolution

1. Conditional Forwarders
2. Secondary Zone Transfers
3. Stub Zone

The benefit of using a conditional forwarder is that it is much easier to configure and troubleshoot than a zone transfer. The process of configuring a conditional forwarder is straightforward: all you need to know is the DNS domain name of the domain that houses the DNS server that you are configuring to forward requests and the IP address of the target DNS server.

However, a conditional forwarder is not an efficient way to keep a DNS server that hosts a parent zone aware of the authoritative DNS servers for a child zone. If you use a conditional forwarder, whenever the authoritative DNS servers for the child zone change, the conditional forwarder setting on the DNS server that hosts the parent zone must be configured manually with the IP address for each new authoritative DNS server for the child zone.

Using a secondary zone with zone transfers enabled is beneficial because this configuration maintains a list of all the authoritative DNS servers for the secondary copy of the zone, and the list is updated as DNS servers are added and removed from the target forest or domain. Secondary zones also host a full copy of the DNS zone.

The drawbacks to using secondary zones with zone transfers enabled are that this configuration is much more complicated to configure and maintain and you do not have the direct, point-to-point contact with a DNS server in the target forest or domain as you do with a conditional forwarder. In addition, with secondary zones you expose hosts to IP address mappings for all hosts in the zone. This can expose the domain or forest to security risks due to unauthorized access.

DNS Resource Records That Are Required for Secondary Zones

There are two DNS resource records that must be registered properly on the DNS server that hosts the secondary copy of the trusted domain or forest:

    * Service (SRV) resource record (_ldap._tcp.dc._msdcs.<computer account domain>)

    * Host (A) resource record

To test the name resolution use the following command
Nltest /dsgetdc:domainNameOfSpecifiedForest

Issue this command from target domain to check the name resolution.

There are other considerations like Firewall port opening at perimeter network to establish a cross forest trust.

Creating Forest Trust
 
Following are the types of Trust Relationship found

1. External Trust
2. Forest Trust
3. Relam Trust
4. Shortcut Trust
5. Tree-Root

I will not be going into creation of each Trust type however will provide you with common steps across all the trusts.
Lets say you manage IT Infra of Company A and Company B is acquired and a One way Trust needs to be created to access resources in Forest B (Domain B, Company B) however IT Functions are still not streamlined (you don't have access over IT resources) In that case you need to create One way Incoming Forest Trust and The other side has to create One Way Outgoing Trust before One way trust can fully work.

Authentication can be set to Forest Wide, Domain Wide and Selective Authentication. If you proceed with Selective Authentication that you need to give right "Allow user to be authenticated" on computer object of the server which you want to access. Forest Wide and Domain Wide are pretty much automated

 Trust can be transistive between two forest but that doesn't imply that it will be automatically transistive with another forest for example A Trust B Trust C and B Trust A that doesn't mean that A trust C. This is not true in case of forest trust.

To create a one-way, incoming, forest trust for one side of the trust

   1. Open Active Directory Domains and Trusts.
   2. In the console tree, right-click the domain node for the domain that you want to establish a trust with, and then click Properties.

   3. On the Trusts tab, click New Trust, and then click Next.
   4. On the Trust Name page, type the Domain Name System (DNS) name (or network basic input/output system (NetBIOS) name) of the domain, and then click Next.

   5. On the Trust Type page, click Forest trust, and then click Next.
   6. On the Direction of Trust page, click One-way: incoming, and then click Next.
      For more information about the selections that are available on the Direction of Trust page, see the section "Direction of Trust" in Appendix: New Trust Wizard Pages.

   7. On the Sides of Trust page, click This domain only, and then click Next.
      For more information about the selections that are available on the Sides of Trust page, see the section "Sides of Trust" in Appendix: New Trust Wizard Pages.

   8. On the Trust Password page, type the trust password twice, and then click Next.
   9. On the Trust Selections Complete page, review the results, and then click Next.
  10. On the Trust Creation Complete page, review the results, and then click Next.
  11. On the Confirm Incoming Trust page, do one of the following:
          * If you do not want to confirm this trust, click No, do not confirm the incoming trust.

          * If you want to confirm this trust, click Yes, confirm the incoming trust, and then supply the appropriate administrative credentials from the specified domain.

  12. On the Completing the New Trust Wizard page, click Finish.

Similary You can create One way outgoing trust from other side. Once created you can validate trusts using Active Directory domains and trusts.

If you have admin credentials for Forest/Domain B then you can create Two way Trust in one step.

For more info check the TechNet Link
http://technet.microsoft.com/en-us/library/cc740018%28WS.10%29.aspx

Introducing Windows Server 2008 DC in Windows 2003 Forest

Hi All,

Today we will be looking into the process of Introducing Windows Server 2008 DC into Windows Server 2003 Forest.

To achieve this we need to prepare our forest and domain to accommodate new W2K8 DC.
Few items to keep in mind.Minimum Forest Functional Level and Domain Function level needs to be Windows 2000 Native.

You need to run adprep using an account that is a member of Schema Admin Groups and Enterprise Admin.
It's not recommended that you disable replication on the schema master before you run Adprep.exe. Adprep.exe skips redundant updates. Conflicting updates such as the introduction of duplicate object identifiers, causes adprep.exe to stop until an administrator reconciles the conflicts. You can stop and restart adprep.exe. It resumes from where it's left.

Before you perform adprep /forestprep make sure you must have a health system statebackup for disaster recovery.

Adprep performs the following tasks
1. Updates the Active Directory Schema
2. Improves default Security descriptors
3. Upgrades display specifiers
4. Adjust ACL on Active Directory objects and on files in the SYSVOL shared folder to allow domain controller access. Anonymous user group is no longer a included in everyone
    group.
5. Create new objects that are used by application such as COM+ and WMI
6. Creates new containers in Active Directory that are used to verify that preparation was successful
Insert Server 2008 DVD on W2K3 domain controller

Go to x:\support\adprep>adprep /forestprep
To verify that adprep /forestprep completed successfully
   1. Log on to an administrative workstation that has ADSIEdit installed. ADSIEdit is installed by default on domain controllers that run Windows Server 2008 or Windows Server
        2008 R2.
  
2. Click Start, click Run, type ADSIEdit.msc, and then click OK.
  
3. Click Action, and then click Connect to.
4. Click Select a well known Naming Context, select Configuration in the list of available naming contexts, and then click OK.
  
5. Double-click Configuration, and then double-click CN=Configuration,DC=forest_root_domain
    where forest_root_domain is the distinguished name of your forest root domain.
6.Double-click CN=ForestUpdates.
 
7. Right-click CN=ActiveDirectoryUpdate, and then click Properties.
  
8. If you ran adprep /forestprep for Windows Server 2008 R2, confirm that the Revision attribute value is 5, and then click OK.
   If you ran adprep /forestprep for Windows Server 2008, confirm that the Revision attribute value is 2, and then click OK.
9. Click ADSI Edit, click Action, and then click Connect to.
 
10. Click Select a Well known naming context, select Schema in the list of available naming contexts, and then click OK.
11. Double-click Schema.
12. Right-click CN=Schema,CN=Configuration,DC=forest_root_domain, and then click Properties
     where forest_root_domain is the distinguished name of your forest root domain.
13. If you ran adprep /forestprep for Windows Server 2008 R2, confirm that the objectVersion attribute value is set to 47, and then click OK.
     If you ran adprep /forestprep for Windows Server 2008, confirm that the objectVersion attribute value is set to 44, and then click OK.

run x:\support\adprep>adprep /domainprep in all the domains where you are planning to introduce W2K8 DC. Make sure that you can logon to infrastructure master  server with an account that is a member of domain admin

To verify that adprep /domainprep completed successfully

   1. Log on to an administrative workstation that has ADSIEdit installed. ADSIEdit is installed by default on domain controllers that run Windows Server 2008 or Windows Server 
      2008 R2.
  
  2. Click Start, click Run, type ADSIEdit.msc, and then click OK.
  
  3. Click Action, and then click Connect to.
  
  4. Click Select a well known Naming Context, select Default naming context in the list of available naming contexts, and then click OK.
  
  5. Double-click Default naming context, double-click the container that is the distinguished name of the domain, and then double-click CN=System.
  
  6. Double-click CN=DomainUpdates, right-click CN=ActiveDirectoryUpdate, and then click Properties.
  
  7. If you ran adprep /domainprep for Windows Server 2008 R2, confirm that the Revision attribute value is 5, and then click OK.
      If you ran adprep /domainprep for Windows Server 2008, confirm that the Revision attribute value is 3, and then click OK.

run x:\support\adprep>adprep /gpprep

Running adprep /gpprep adds inheritable access control enteries on Group Policy Objects in the SYSVOL share folder. The additional ACEs give Enterprise Domain Controller read access permissions on GPOs. These permissions are required to support Resultant Set of Policy functionality (modeling) for the site based policy.
Run adprep /gpprep during off production hours because it can generate substansial replication traffic because each GPO would be updated
For optimal performance, make sure the Default Domain and Default Domain Controller policy is located on Infrastructure master role server.
If you running a Anti virus on server from where you would be running adprep /gpprep make sure to disable it as it may cause interfance
Once you finish running adprep /gpprep you can verify that the operation added the Read permission for the Enterprise Domain Controllers group on all GPOs

RODC Staged Installation

RODC in Remote Branch Office

RODC is a new feature added in Windows Server 2008. For remote branch office,poor network connectivity, less secure location, low user base we can use RODC. RODC can be run on Windows Server 2008 Core Installation with least requirements like memory,HDD, processor. A low end server would be enough for this kind of setup hence proving to be cost effective.

We would be doing a Staged Installation of RODC. In this type of installation There are two stages.

Before we begin lets take a look at prerequistives.

1. Forest Functional Level and Domain functional level must be windows server 2003 or higher.
2. At least one writeable windows server 2008 Domain Controller.
3. Adprep /rodcprep must be run. Running this will give update permission on all DNS servers and allow them to be replicated by RODC which are running DNS as well.

Verifying rodcprep success

To verify that adprep /rodcprep completed successfully
   1. Log on to an administrative workstation that has ADSIEdit installed. ADSIEdit is installed by default on domain controllers that run Windows Server 2008 or Windows Server 2008 R2.
   2. Click Start, click Run, type ADSIEdit.msc, and then click OK.
   3. Click Action, and then click Connect to.
   4. Click Select a well known Naming Context, select Configuration in the list of available naming contexts, and 
       then click OK.
   5. Double-click Configuration, and then double-click CN=Configuration,DC=forest_root_domain
      where forest_root_domain is the distinguished name of your forest root domain.
   6. Double-click CN=ForestUpdates.
   7. Right-click CN=ActivedirectoryRodcUpdate, and then click Properties.
   8. Confirm that the Revision attribute value is 2, and then click OK.

To install RODC there are 3 options available.

1. Running directly using dcpromo /adv setup
2. Install from Media
3. Staged Installation

As mentioned earlier we would be doing RODC using staged installation

First: member of domain admin adds necessary computer accout information, site info, dns, gc.

Steps for creating Pre Staged RODC installation account

To create an RODC account by using the Windows interface

1. Click Start, click Administrative Tools, and then click Active Directory Users and Computers.
2. Double-click the domain container, then you can either right-click the Domain Controllers container or click the Domain Controllers container, and then click Action.
3. Click Pre-create Read-only Domain Controller account, as shown in the following figure.

4. On the Welcome to the Active Directory Domain Services Installation Wizard page, if you want to modify the default the Password Replication Policy, select Use advanced mode installation, and then click Next.
5. On the Network Credentials page, under Specify the account credentials to use to perform the installation, click My current logged on credentials, as shown in the following figure, or click Alternate credentials, and then click Set. In the Windows Security dialog box, provide the user name and password for an account that can install the additional domain controller. To install an additional domain controller, you must be a member of the Enterprise Admins group or the Domain Admins group. When you are finished providing credentials, click Next.

6. On the Specify the Computer Name page, type the computer name of the server that will be the RODC.
7. On the Select a Site page, select a site from the list or select the option to install the domain controller in the site that corresponds to the IP address of the computer on which you are running the wizard, and then click Next.
8. On the Additional Domain Controller Options page, make the following selections, as shown in the following figure, and then click Next:
• DNS server: This option is selected by default so that your domain controller can function as a DNS server. If you do not want the domain controller to be a DNS server, clear this check box. However, if you do not install the DNS server role on the RODC and the RODC is the only domain controller in the branch office, users in the branch office will not be able to perform name resolution when the WAN to the hub site is offline.
• Global catalog: This option is selected by default. It adds the read-only directory partitions of the global catalog to the domain controller, and it enables global catalog search functionality. If you do not want the domain controller to be a global catalog server, clear this option. However, if you do not install a global catalog server in the branch office or enable universal group membership caching for the site that includes the RODC, users in the branch office will not be able to log on to the domain when the WAN to the hub site is offline.
• Read-only domain controller. When you create an RODC account, this option is selected by default and you cannot clear it.
9. If you selected the Use advanced mode installation check box on the Welcome page, the Specify the Password Replication Policy page appears. By default, no account passwords are replicated to the RODC, and security-sensitive accounts (such as members of the Domain Admins group) are explicitly denied from ever having their passwords replicated to the RODC.

To accept the default setting, click Next.

-or-

To add other accounts to policy, click Add. If you want the accounts to be allowed to have their passwords replicated to the RODC, click Allow passwords for the account to replicate to this RODC. If you want the accounts to be denied from having their passwords replicated to the RODC, click Deny passwords for the account from replicating to this RODC. Then, click OK. When you are done adding other accounts, click Next.

When you install the first RODC in a domain, domain group accounts that are required for RODCs to function are created. Depending on your replication topology, the wizard might return an error indicating that these group accounts are not available when you try to install another RODC in the domain. In this case, wait for replication to complete before you install the additional RODC.

10. In Select Users, Computers, and Groups, type the names of the accounts that you want to add to the policy, and then click OK.
11. On the Delegation of RODC Installation and Administration page, type the name of the user or the group who will attach the server to the RODC account that you are creating, as shown in the following figure. You can type the name of only one security principal.

To search the directory for a specific user or group, click Set. In Select Users, Computers, or Groups, type the name of the user or group. We recommend that you delegate RODC installation and administration to a group.

This user or group will also have local administrative rights on the RODC after the installation. If you do not specify a user or group, only members of the Domain Admins group or the Enterprise Admins group will be able to attach the server to the account.

When you are finished, click Next.

12. On the Summary page, review your selections. Click Back to change any selections, if necessary.

To save the settings that you selected to an answer file that you can use to automate subsequent AD DS operations, click Export settings. Type a name for your answer file, and then click Save.

When you are sure that your selections are accurate, click Next to create the RODC account.

13. On the Completing the Active Directory Domain Services Installation Wizard page, click Finish.

After you create the account for the RODC, the user or group to whom you delegated installation and administration of the RODC (in step 11 in the previous procedure) can run the Active Directory Domain Services Installation Wizard on the server that will become the RODC to complete the RODC installation. Make sure that the server is not joined to the domain before you start the wizard.

To attach a server to an RODC account using the Windows interface

1. Log on as local Administrator to the server that will become the RODC, and then open a command prompt.
2. Type the following command, and then press ENTER:

dcpromo /UseExistingAccount:Attach

3. On the Welcome to the Active Directory Domain Services Installation Wizard page, click Next, or, if you want to install from media or identify the source domain controller for AD DS replication, select the Use advanced mode installation check box.
4. On the Network Credentials page, type the name of any existing domain in the forest where you plan to install the additional domain controller, as shown in the following figure. Under Specify the account credentials to use to perform the installation, click Alternate credentials, and then click Set. In the Windows Security dialog box, provide the user name and password for an account that was delegated the ability to install and administer the RODC when the RODC account was created. When you are finished providing credentials, click Next.

5. On the Select Domain Controller Account page, confirm that the wizard has found an existing RODC account that matches the name of the server, and then click Next.
6. On the Location for Database, Log Files, and SYSVOL page, type or browse to the volume and folder locations for the database file, the directory service log files, and the system volume (SYSVOL) files, and then click Next.

Windows Server Backup backs up the directory service by volume. For backup and recovery efficiency, store these files on separate volumes that do not contain applications or other nondirectory files.

7. On the Directory Services Restore Mode Administrator Password page, type and confirm the restore mode password, and then click Next. This password is used to start AD DS in Directory Service Restore Mode for tasks that must be performed offline. The password complexity and length must comply with the domain security policy.
8. On the Summary page, review your selections. Click Back to change any selections, if necessary.

To save the settings that you selected to an answer file that you can use to automate subsequent AD DS operations, click Export settings. Type a name for your answer file, and then click Save.

Part B

I have installed RODC on Windows core installation.

You will need to create an answer file in order for RODC setup to be successfully completed.

You need to use command line or you can use CoreConfigurator to finish RODC.

dcpromo /unattend /UseExistingAccount:Attach /ReplicaDomainDNSName: contoso.com /UserDomain:contoso.com /UserName:contoso\da1 /password:* /databasePath:"e:\Windows\ntds" /logPath:"e:\Windows\ntds" /sysvolpath:"e:\Windows\sysvol" /safeModeAdminPassword:FH#3573.cK /rebootOnCompletion:yes

The contents of answer file are as follows

I have used CoreConfiguration to generate answerfile. It can them be modified as per needs.

I hope this post would be informational for you.