Augusto Alvarez

Ok then, after completing the first configurations made on the Part I of this guide we can perform a clean but attended network installation of Windows Vista.

There are two main steps to take and complete a full image and unattended deployment:

1. Creating the base image to deploy: OS, programs and other special configurations + uploading it to the WDS server.

2. Making an unattended file to be used with that image.

Creating the Base Image

Note: On this series of posts we are only considering to deploy Windows Vista or Windows Server 2008 images. The files used on WDS Native mode as unattended files are only valid to those operating systems, if you want to make unattended deployment with Windows XP or 2003 OS; you will need to use RIS or WDS Legacy Mode.

The first step it’s pretty simple, it consists on installing the operating system with all the features, programs and configurations that you want. But there are some considerations first:

After you complete the image, there’s a process where you release all the specific data involving the computer where it’s installed, like the Security Identifier (SID), computer name, etc. Here are some of the things that the image won’t keep after the release process:

· Computer name
· Owner and Company name
· SID
· Domain or workgroup membership
· TCP/IP Settings
· Regional and keyboard settings
· Specific hardware drivers. This refers to specific computer hardware, like video or audio drivers. But if you only applied drivers used on the Windows installation, the same will apply for the deployment, but any other external driver installed will be unavailable.
· Any saved network connections (wireless networks saved)
· OS product key. This is an important note, since no matter if your product has been activated; the key is reset after this process.

But here are some of the things that are kept after this release process:

· Programs and features installed (pretty obvious to say that at this moment right?)
· Local Users and Groups created.
· Product Keys used for programs installed. Meaning if you have Microsoft Office installed, the key used will remain as the same on the deployments.
· Windows updates installed
· User Profiles: Since all the profiles configuration are basically data stored on the Users folders, all that information will be uploaded within the image.
· Printers installed.

All the uploading process is made from the client side; but we must first prepare the WDS server to be ready to receive images.

First, we are going to add a boot image that will be specially to capture operating system images.

1. Go to WDS Console and let’s upload a second boot image; it can be the same that we added on the first post using the boot.wim from a Vista or Windows Server 2008 media.

2. Instead of naming it Windows PE, use a name like “Image Capture”.

3. After the process completes, right click on the image you just added and select “Create Capture Boot Image”

Now we have set our WDS server, let’s prepare the client using the sysprep tool and upload the image:

1. On the Vista or Windows 2008 client open a “cmd” as administrator and insert “cd c:\windows\system32\sysprep”.

2. Run “sysprep /oobe /generalize /reboot”.

This process will require for a few second and after it completes the OS will automatically reboot.

3. Soon as the machine is rebooting, press F12 to select different devices to boot.

4. Select to boot from the network card connected to the LAN

Now the client is communicating with the DHCP server to require an IP and a boot image, the DHCP will forward the request to the WDS. You will be prompted to press F12 one more time.

5. Since we have two boot images, let’s select “Image Capture”

The boot image will start to load.

6. A image capture wizard will start, click on “Next”

7. Now let’s select the volume we want to capture, in our case C:\. And put a name for the image that will be uploaded as long with a description.

It’s important to note that if the sysprep process did not completed properly no volume will be available to select.

8. On the next window you must select where the .wim file will be temporary stored locally. Select to keep it on the root C:\ (this file it’s not uploaded within the image).

9. Select the option “Load the image to a WDS server”; put the name of the server and click on “Connect”

10. You will be prompted with credentials, use a privileged account on the domain or local administrator account of the WDS server.

11. Now select the image group name where you want to store the new image and click on Finish.

Here the process of the image compression and preparation starts, this could take several minutes (~30 mins to ~1hr) depending on the image size and the hardware involved. After this process, the image is uploaded to the WDS server.

After it completes, check on the WDS console, the image should be uploaded and ready to be deployed.

Still we have not configured any unattended file, so the image can be deployed but the entire OS configuration should be entered manually, like on normal OS installation but all the programs will be installed.

For the unattended files preparation and configuration take a look to the third post of WDS.

Cheers!

It’s a common best practice to run the DCDIAG tool in all DC in your forest whenever a significant change has been made, i.e. a new DC has been added or deleted in the forest. With this you are testing if the change you just made was done correctly.

It’s also common that if you have at least two domains in your forest (and the trust relationships in place), when you run dcdiag in any DC you get a message indicating that when the test of replication on a specific server applies, it fails indicating that the “RPC Server is unavailable”.

Well, if you see this message you probably check if that the RPC service is up and running on the server… running in cmd “net start rpcss”. But the command prompt answers you, “don’t worry dude, the service was already running”.

“Alright then…” you say, “Let’s try DCDIAG again”… and you get the same error like the first time…

And then you go like “Hmmmm… why do I keep getting the same “RPC Server is unavailable” error?”

And then I say “I know why dude!”… And then you “You do? Is there any way I can solve it?”…
“Of course, why I’ll be posting something that I don’t know the answer!”… and then…

OK, enough with the theatre…

This issue appears when the configurations between the different DNS servers are not compatible. It’s something like this: you have a correct configuration in a DNS server that forwards any requests that does not belong to his domain ; but in the second domain, the DNS server does not forward the requests that ask for the first domain… was it clear? Let’s do a picture then!

In this graphic, a contoso domain member it’s trying to get something from fabrikam, the DNS Server from contoso receive the request and see that it belongs to fabrikam and forwards the request to the correct DNS Server. But in the other side, a fabrikam user wants to get something from contoso but when it gets the requests, see that it’s not for fabrikam and it does not have anything that says that the request must be forward it to another DNS Server, so can’t solve the user’s request.

After naming “forward” several times you probably know where the problem is: The forwarders on your DNS servers are not set correctly. The most like problem is that having different domains in the same forest, the DNS servers from each domain don’t know were to direct the requests for all the other domains.

Let’s take one server to solve this problem: Access the DNS snap-in of your DNS Server, on “Properties” select the “Forwarders” option and select “New” in DNS Domain and add all the domains in your forest; and put the IP address to the DNS server holding that domain.

In this case, LEONARDO is DNS Server for CORPNET and I’m adding in the Forwarders configuration that any request for EXTRANET, my second domain in the forest, are been forwarded to its DNS Server. In EXTRANET the same configuration must be set, of course

Also there’s another way to solve this problem. You can add an EXTRANET zone in CORPNET Forward Lookup Zones that holds all of the DNS records for this domain. In this case you must also set, in EXTRANET DNS, the properties for this zone, to “Allow Zone Transfers”, letting another DNS server, CORPNET, to also have the records for this zone. But, in my opinion, is also a good idea to not over charge your DNS server with all kind of request, so if it’s not for his domain, forward to the correct DNS server for resolution.

If the error keeps appearing, then you should check the trust relationships between domains. And any other error message that DCDIAG shows in all DCs.

Cheers!

 

 

Scenario:

I have the domain contoso.com with only one DC (with DNS) and I wish to add another one in case something goes wrong.

- The first thing that you must have is, of course, the new server where you are going to install your second DC. It’s highly recommended that both servers are working with the latest updates, Windows Server 2003 R2 SP2. And the domain is raised into “Windows 2003” functional level (on this level there are some improvements in many things, including the replications between 2003 servers).

- Run the Administration Tool “Manage Your Server” in the new Windows 2003 and add the role “Active Directory” for this server.

 
Domain controller promotion wizard

- Configure the server as a DC for an existing domain and follow the instructions in the wizard. You’ll be asked for the credentials of privileged account to add a new server. The account must be a member of the “Domain Admins” group.

- After the promotion of the new DC is completed, visit again “Manage your Server” and add the role “DNS Server”, but don’t set any new zone on this server. When you configure it as a DNS server the primary server will replicate the zones with this new server.

- Each DC must be pointing to themselves as the first preferred DNS server and the secondary DNS must be the remaining DC.

First DC TCP/IP configuration

 
Second DC TCP/IP configuration

- At this time the DNS records must be replicated and in both servers you should have the same zones and records. Check the DNS snap-in for the new DC and check that the zones are identical in both DCs.

- IMPORTANT: Any special configuration of the first DNS server, i.e. “Forwarders” configurations or in “Zone Transfers”, are NOT replicated between servers, for obvious reasons. So if you are trying to make this new DC to act as a replacement when the first DC is down (that’s a failover environment), you have to set the same configurations manually.

- Global Catalog: You also have to add the role “Global Catalog” in the new server, to do this visit “Active Directory Sites and Services”, expand the site where the DC is located, since we are using all the DC in the same subnet, all of them must be in the same site (the DC is automatically located in this site when you assign him the IP address). Expand “Servers” and expand in the new server name, right click on “NTDS Settings” and click “Properties”, select the option “Global Catalog”.

 
Global Catalog option on NTDS Settings

Remember that in the forest must be at least one GC up and working at all moment.

Control and Tests

To check that the functionality for the new server and the replication is working properly you can do these tests:

· On the new DC, run cmd and type “ipconfig /registerdns” to ensure the creation of a record for name resolution.

· Install Windows Support Tools and run the DCDIAG tool as it follows: “dcdiag /test:registerindns /dnsdomain:contoso.com /v”. Basically what you are doing here is letting know that this is a valid DC for the domain.

· Open the “Active Directory and Computers” snap-in, on the “Domain Controllers” built-in ensure that both of the existing DCs are located there.

  
Domain Controllers in CORPNET.AD

· Open “Sites and Services” snap-in and check that all the servers within the forest are listed. Expand every each of them and in “NTDS Settings” (this section indicates with which servers will replicate each DC) the list in the right in every DC should be listing the remaining DCs. If anyone is missing you have to add it manually selecting “New Active Directory Connection”.

 
Replication

In this snap-in you can check the manual replication between servers. Right click in the listed servers in NTDS Settings and select the option “Replicate Now” you should get the message “Active Directory has replicated the connections”.

· Run “dcdiag” in command prompt and check that the entire test is passed successfully.

· Check the Event Viewer in all DCs and watch for any error description. If something out of the ordinary appears, you can check http://www.eventid.net and insert the Event ID number from the error that you found. The site will display you pretty much the same information that you have in the event description, but you also will find user comments about this error and how they solved it.

- After these tests are completely successfully, change the DHCP server (if you have it) configuration to start using both DNS servers. In the DHCP snap-in, expand the Scope and Scope Options. In the right you will find the entire configuration that is distributed with a common lease. Double-click in “DNS Servers” and add the IP of the new DC.

 
DHCP Configuration

You are all set now…

Cheers!!

 

“My DC is online, the TCP/IP it´s OK, the DNS service running but I still cannot make a valid connection with AD! “

This is a problem that can be present in many ways. The most common example is: you have your DC completely configure for Active Directory, the DNS server too, and you try to join a workstation to your domain and the following error appears:

An Active Directory Domain Controller for the domain [yourdomain.com] could not be contacted.
Ensure that the domain name is typed correctly
(…)

First of all, the obvious: Check that the connectivity is working fine… the DNS server and the DC both of them responds to PING requests. It’s most likely that if you cannot connect to the domain, the PING requests for the FQDN (such as: ping dcname.yourdomain.com or ping yourdomain.com) will not respond as well… but with the IP parameter should be working… if it’s not, then there’s definitely a connectivity problem, a bad TCP/IP configuration or a firewall within the way .

Well, let’s see, this is a problem that can really make you nuts trying to solve it.

Let’s assume that you have the correct configuration in your DC and workstations. If you have a DHCP server in you network, check that he is doing his job… giving the correct IP address for the workstations, the subnet mask, the DNS server and the other parameters that you are using.

DCDIAG really? Can that help me?

One of the possible reasons of your problem is that DC didn’t register himself in the DNS for let the AD know that he is a valid domain controller. To do that, use the DCDIAG tool (included in the Windows 2003 Support Tools) as it follows:

dcdiag /test:registerindns /dnsdomain:yourdomain.com /v

Where yourdomain.com is the complete FQDN of your domain

If everything goes ok, you will get a message like this:

Using NSLOOKUP

NSLOOKUP is a very helpful utility to test the name resolution in a DNS server. You’ll use this tool to check the SRV (service) records are in place for the correct functionality of Active Directory.
Type in the command line nslookup and press enter. You will probably find a message like this:

“*** Can’t find name server for the address : Non-existent domain”, don’t worry about it. This happens when you don’t have set any PTR (or reverse records) in your DNS server, to resolve IP address in names.

Carry on then, at nslookup (“>”) prompt type:

set q=srv press enter.

Then type: _ldap._tcp.dc._msdcs.yourdomain.com

Again, sometimes because you don’t have any PTR records you may find some “time out” messages, but there is nothing vital at this point.

If there is no problem with that, you will see the DNS server name and its IP address… if you don’t, you still have one thing to do.

That thing you never wanted to do… modifying a .dns file

The file that probably will save you is saved in: C:\WINDOWS\system32\config and with the name netlogon.dns.

You have to open this file with the notepad and take a look to it, but don’t get frightened! … You will see a bunch of lines that will probably don’t have much sense to you, but one of them we are looking for:

_ldap._tcp.yourdomain.com IN SRV 0 0 389 ldap_server_name
_ldap._tcp.dc._msdcs.yourdomain.com IN SRV 0 0 389 domain_controller_name

The LDAP server name should be the same for the DC server name. So if you are going to manually change this file, use them as the same.

I’m gonna publish some other documents for similar problems. They all are from situations like you lost your only DC and you get back on service an old backup that has a different configuration. Check them too.

Cheers everyone!