Unattend installations of AD Services

dcpromo /unattend:<path of the answer file>

Field values

Fields in the "[DCInstall]" section of the answer file specify the details of the installation or removal operation. The

following list provides the common fields that are used for each operation. The default values are used if the option is not

specified. The default values for these fields are described in the "Field definitions" section.

 For new forest installations, the following options apply:

[DCINSTALL]

InstallDNS=yes

NewDomain=forest

NewDomainDNSName=<The fully qualified Domain Name System (DNS) name>

DomainNetBiosName=<By default, the first label of the fully qualified DNS name>

SiteName=<Default-First-Site-Name>

ReplicaOrNewDomain=domain

ForestLevel=<The forest functional level number>

DomainLevel=<The domain functional level number>

DatabasePath="<The path of a folder on a local volume>"

LogPath="<The path of a folder on a local volume>"

RebootOnCompletion=yes

SYSVOLPath="<The path of a folder on a local volume>"

SafeModeAdminPassword=<The password for an offline administrator account>

 For child domain installations, the following options apply:

[DCINSTALL]

ParentDomainDNSName=<Fully qualified DNS name of parent domain>

UserName=<The administrative account in the parent domain>

UserDomain=<The name of the domain of the user account>

Password=<The password for the user account> Specify * to prompt the user for credentials during the

installation.

NewDomain=child

ChildName=<The single-label DNS name of the new domain>

SiteName=<The name of the AD DS site in which this domain controller will reside> This site must be created in

advance in the Dssites.msc snap-in.

DomainNetBiosName=<The first label of the fully qualified DNS name>

ReplicaOrNewDomain=domain
 DomainLevel=<The domain functional level number> This value cannot be less than the current value of the

forest functional level.

DatabasePath="<The path of a folder on a local volume>"

LogPath="<The path of a folder on a local volume>"

SYSVOLPath="<The path of a folder on a local volume>"

InstallDNS=yes

CreateDNSDelegation=yes

DNSDelegationUserName= <The account that has permissions to create a DNS delegation> The account that is

being used to install AD DS may differ from the account in the parent domain that has the permissions that are

required to create a DNS delegation. In this case, specify the account that can create the DNS delegation for this

parameter. Specify * to prompt the user for credentials during the installation.

DNSDelegationPassword= <The password for the account that is specified for DNSDelegationUserName> Specify

* to prompt the user for a password during the installation.

SafeModeAdminPassword=<The password for an offline administrator account>

RebootOnCompletion=yes

 For a new tree in existing forest installations, the following options apply:

[DCINSTALL]

UserName=<An administrative account in the parent domain>

UserDomain=<The name of the domain of the user account>

Password=<The password for the adminstrative account> Specify * to prompt the user for credentials during

the installation.

NewDomain=tree

NewDomainDNSName=<The fully qualified DNS name of the new domain>

SiteName=<The name of the AD DS site in which this domain controller will reside> This site must be created in

advance in the Dssites.msc snap-in.

DomainNetBiosName=<The first label of the fully qualified DNS name>

ReplicaOrNewDomain=domain

DomainLevel=<The domain functional level number>

DatabasePath="<The path of a folder on a local volume>"

LogPath="<The path of a folder on a local volume>"

SYSVOLPath="<The path of a folder on a local volume>"

InstallDNS=yes

CreateDNSDelegation=yes

DNSDelegationUserName= <The account that has permissions to create a DNS delegation> The account that is

being used to install AD DS may differ from the account in the parent domain that has the permissions that are

required to create a DNS delegation. In this case, specify the account that can create the DNS delegation for this

parameter. Specify * to prompt the user for credentials during the installation.

DNSDelegationPassword=<The password for the account that is specified for DNSDelegationUserName> Specify

* to prompt the user for a password during the installation.

 SafeModeAdminPassword=<The password for an offline administrator account>

RebootOnCompletion=yes

 For additional domain controller installations, the following options apply:

[DCINSTALL]

UserName=<The administrative account in the domain of the new domain controller>

UserDomain=<The name of the domain of the new domain controller>

Password=<The password for the UserName account>

SiteName=<The name of the AD DS site in which this domain controller will reside> This site must be created in

advance in the Dssites.msc snap-in.

ReplicaOrNewDomain=replica

DatabasePath="<The path of a folder on a local volume>"

LogPath="<The path of a folder on a local volume>"

SYSVOLPath="<The path of a folder on a local volume>"

InstallDNS=yes

ConfirmGC=yes

SafeModeAdminPassword=<The password for an offline administrator account>

RebootOnCompletion=yes

 For additional domain controller installations that use the Install From Media (IFM) method, the following options

apply:

[DCINSTALL]

UserName=<The administrative account in the domain of the new domain controller>

Password=<The password for the UserName account>

UserDomain=<The name of the domain of the UserName account>

DatabasePath="<The path of a folder on a local volume>"

LogPath="<The path of a folder on a local volume>"

SYSVOLPath="<The path of a folder on a local volume>"

SafeModeAdminPassword=<The password of an offline administrator account>

CriticalReplicationOnly=no

SiteName=<The name of the AD DS site in which this domain controller will reside> This site must be created in

advance in the Dssites.msc snap-in.

ReplicaOrNewDomain=replica

ReplicaDomainDNSName=<The fully qualified domain name (FQDN) of the domain in which you want to add an

additional domain controller>

ReplicationSourceDC=<An existing domain controller in the domain>

ReplicateFromMedia=yes

ReplicationSourcePath=<The local drive and the path of the backup>

RebootOnCompletion=yes

 For read-only domain controller (RODC) installations, the following options apply:
 [DCINSTALL]

UserName=<The administrative account in the domain of the new domain controller>

UserDomain=<The name of the domain of the user account>

PasswordReplicationDenied=<The names of the user, group, and computer accounts whose passwords are not

to be replicated to this RODC>

PasswordReplicationAllowed =<The names of the user, group, and computer accounts whose passwords can be

replicated to this RODC>

DelegatedAdmin=<The user or group account name that will install and administer the RODC>

SiteName=Default-First-Site-Name

CreateDNSDelegation=no

CriticalReplicationOnly=yes

Password=<The password for the UserName account>

ReplicaOrNewDomain=ReadOnlyReplica

ReplicaDomainDNSName=<The FQDN of the domain in which you want to add an additional domain controller>

DatabasePath= "<The path of a folder on a local volume>"

LogPath="<The path of a folder on a local volume>"

SYSVOLPath="<The path of a folder on a local volume>"

InstallDNS=yes

ConfirmGC=yes

RebootOnCompletion=yes

 For removal of AD DS, the following options apply:

[DCINSTALL]

UserName=<An administrative account in the domain>

UserDomain=<The domain name of the administrative account>

Password=<The password for the UserName account>

AdministratorPassword=<The local administrator password for the server>

RemoveApplicationPartitions=yes

RemoveDNSDelegation=yes

DNSDelegationUserName=<The DNS server administrative account for the DNS zone that contains the DNS

delegation>

DNSDelegationPassword=<The password for the DNSDelegationUserName account>

RebootOnCompletion=yes

 For removal of AD DS from the last domain controller in a domain, the following options apply:

[DCINSTALL]

UserName=<An administrative account in the parent domain>

UserDomain=<The domain name of the UserName account>

Password=<The password for the UserName account> Specify * to prompt the user for credentials during the

installation.
 IsLastDCInDomain=yes

AdministratorPassword=<The local administrator password for the server>

RemoveApplicationPartitions=If you want to remove the partitions, specify "yes" (no quotation marks) for this

entry. If you want to keep the partitions, this entry is optional.

RemoveDNSDelegation=yes

DNSDelegationUserName=<The DNS server administrative account for the DNS zone that contains the DNS

delegation>

DNSDelegationPassword=<The password for the DNS server administrative account>

RebootOnCompletion=yes

 For removal of the last domain controller in a forest, the following options apply:

[DCINSTALL]

UserName=<An administrative account in the parent domain>

UserDomain=<The domain name of the UserName account>

Password=<The password for the UserName account> Specify * to prompt the user for credentials during the

installation.

IsLastDCInDomain=yes

AdministratorPassword=<The local administrator password for the server>

RemoveApplicationPartitions=If you want to remove the partitions, specify "yes" (no quotation marks) for this

entry. If you want to keep the partitions, this entry is optional.

RemoveDNSDelegation=yes

DNSDelegationUserName=<The DNS server administrative account for the DNS zone that contains the DNS

delegation>

DNSDelegationPassword=<The password for the DNS server administrative account>

RebootOnCompletion=yes
 How to Install Windows Server 2008 Step by Step
Installing Windows Server 2008 is pretty straightforward and is very much like installing Windows Vista, but I thought I'd list
the necessary steps here for additional information. For those of you who have never installed Vista before, the entire installation
process is different than it used to be in previous Microsoft operating systems, and notably much easier to perform.

Using Vista's installation routine is a major benefit, especially for a server OS. Administrators can partition the system's hard
drives during setup. More importantly, they can install the necessary AHCI or RAID storage drivers from a CD/DVD or even a
USB thumb drive. Thus, error-prone floppies can finally be sent to the garbage bin.

Note: Windows Server 2008 can also be installed as a Server Core installation, which is a cut-down version of Windows without
the Windows Explorer GUI. Because you don’t have the Windows Explorer to provide the GUI interface that you are used to, you
configure everything through the command line interface or remotely using a Microsoft Management Console (MMC). The
Server Core can be used for dedicated machines with basic roles such as Domain controller/Active Directory Domain Services,
DNS Server, DHCP Server, file server, print server, Windows Media Server, IIS 7 web server and Windows Server Virtualization
virtual server. For Server Core installations please see my "Installing Windows Server 2008 Core" article.

To use Windows Server 2008 you need to meet the following hardware requirements: 

Component Requirement

Processor • Minimum: 1GHz (x86 processor) or 1.4GHz (x64 processor)

• Recommended: 2GHz or faster
Note: An Intel Itanium 2 processor is required for Windows Server 2008 for Itanium-
based Systems

Memory • Minimum: 512MB RAM

• Recommended: 2GB RAM or greater
• Maximum (32-bit systems): 4GB (Standard) or 64GB (Enterprise and Datacenter)
• Maximum (64-bit systems): 32GB (Standard) or 2TB (Enterprise, Datacenter and
Itanium-based Systems)

Available Disk • Minimum: 10GB

Space • Recommended: 40GB or greater
Note: Computers with more than 16GB of RAM will require more disk space for
paging, hibernation, and dump files

Drive DVD-ROM drive

Display and • Super VGA (800 x 600) or higher-resolution monitor

Peripherals • Keyboard
• Microsoft Mouse or compatible pointing device

Upgrade notes:

I will not discuss the upgrade process in this article, but for your general knowledge, the upgrade paths
available for Windows Server 2008 shown in the table below:

If you are currently running:  You can upgrade to:

Windows Server 2003 Standard Edition Full Installation of Windows Server 2008
(R2, Service Pack 1 or Service Pack 2) Standard Edition
 Full Installation of Windows Server 2008
Enterprise Edition

 
Windows Server 2003 Enterprise Edition Full Installation of Windows Server 2008
(R2, Service Pack 1 or Service Pack 2) Enterprise Edition
 
Windows Server 2003 Datacenter Edition Full Installation of Windows Server 2008
(R2, Service Pack 1 or Service Pack 2) Datacenter Edition
 

Follow this procedure to install Windows Server 2008:

1. Insert the appropriate Windows Server 2008 installation media into your DVD drive. If you don't have an installation DVD
for Windows Server 2008, you can download one for free from Microsoft's Windows 2008 Server Trial website.

2. Reboot the computer.

3. When prompted for an installation language and other regional options, make your selection and press Next.

4. Next, press Install Now to begin the installation process.

5. Product activation is now also identical with that found in Windows Vista. Enter your Product ID in the next window, and if
you want to automatically activate Windows the moment the installation finishes, click Next.

If you do not have the Product ID available right now, you can leave the box empty, and click Next. You will need to provide the
Product ID later, after the server installation is over. Press No.

6. Because you did not provide the correct ID, the installation process cannot determine what kind of Windows Server 2008
license you own, and therefore you will be prompted to select your correct version in the next screen, assuming you are telling
the truth and will provide the correct ID to prove your selection later on.
7. If you did provide the right Product ID, select the Full version of the right Windows version you're prompted, and click Next.

8. Read and accept the license terms by clicking to select the checkbox and pressing Next.

9. In the "Which type of installation do you want?" window, click the only available option – Custom (Advanced).
10. In the "Where do you want to install Windows?", if you're installing the server on a regular IDE hard disk, click to select
the first disk, usually Disk 0, and click Next.

If you're installing on a hard disk that's connected to a SCSI controller, click Load Driver and insert the media provided by the
controller's manufacturer.

If you're installing in a Virtual Machine environment, make sure you read the "Installing the Virtual SCSI Controller Driver for
Virtual Server 2005 on Windows Server 2008"

If you must, you can also click Drive Options and manually create a partition on the destination hard disk.

11. The installation now begins, and you can go and have lunch. Copying the setup files from the DVD to the hard drive only
takes about one minute. However, extracting and uncompressing the files takes a good deal longer. After 20 minutes, the
operating system is installed. The exact time it takes to install server core depends upon your hardware specifications. Faster disks
will perform much faster installs… Windows Server 2008 takes up approximately 10 GB of hard drive space.
The installation process will reboot your computer, so, if in step #10 you inserted a floppy disk (either real or virtual), make sure
you remove it before going to lunch, as you'll find the server hanged without the ability to boot (you can bypass this by
configuring the server to boot from a CD/DVD and then from the hard disk in the booting order on the server's BIOS)

12. Then the server reboots you'll be prompted with the new Windows Server 2008 type of login screen. Press
CTRL+ALT+DEL to log in.

13. Click on Other User.

14. The default Administrator is blank, so just type Administrator and press Enter.
15. You will be prompted to change the user's password. You have no choice but to press Ok.

16. In the password changing dialog box, leave the default password blank (duh, read step #15…), and enter a new, complex, at-
least-7-characters-long new password twice. A password like "topsecret" is not valid (it's not complex), but one like
"T0pSecreT!" sure is. Make sure you remember it.
17. Someone thought it would be cool to nag you once more, so now you'll be prompted to accept the fact that the password had
been changed. Press Ok.

18. Finally, the desktop appears and that's it, you're logged on and can begin working. You will be greeted by an assistant for the
initial server configuration, and after performing some initial configuration tasks, you will be able to start working.
 Windows Server 2008 ADPREP
Before you can introduce Windows Server 2008 domain controllers into existing Windows 2000 or Windows Server 2003
domains, you must prepare the forest and domains with the ADPREP utility. ADPREP.exe is a command-line tool that extends
the Active Directory schema, and updates permissions as necessary to prepare a forest and domain for a domain controller that
runs the Windows Server 2008 operating system.

Note: ADPREP was also available in Windows Server 2003 and Windows Server 2003 R2. In Windows Server 2008, ADPREP
follows the same logic and performs similar tasks to prepare for the upgrade to Windows Server 2003 or Windows Server 2003
R2. Please read my "Windows 2003 ADPREP" article for more information on that.

ADPREP.exe is a command-line tool that is available on the Windows Server 2008 installation disc in the \sources\adprep
folder.

When you run it, it must be run ADPREP from an elevated command prompt. To open an elevated command prompt, click Start,
right-click Command Prompt, and then click Run as administrator.

Where should I run ADPREP?

ADPREP /forestprep must be run on the Schema Master of a forest and under the credentials of someone in the Schema Admins
and Enterprise Admins groups.

ADPREP /domainprep must be run on the Infrastructure Master of a domain and under the credentials of someone in the
Domain Admins group.

Important: Since at the time of running ADPREP you still do not have any Windows Server 2008 Domain Controllers, it should
be made clear that these commands MUST be run on EXISTING Windows 2000 or Windows Server 2003 Domain Controllers.
That is why you MUST make sure you keep a copy of the 32-bit version of the Windows Server 2008 installation DVD. You
cannot use the 64-bit version of the installation media to run ADPREP on 32-bit versions of Windows 2000/2003. Because
Windows Server 2008 installation media is 64-bit by default, remember to request the 32-bit version when you get your copy. In
case you don't have the 32-bit version available, you can also use the evaluation version of Windows Server 2008 32-bit
installation media to run ADPREP, so just download the file from Microsoft's website, and use it to run ADPREP on your 32-bit
Windows 2000/2003 DCs.

What does ADPREP do?

Before running ADPREP, all Windows 2000 Active Directory Domain Controllers in the forest should be upgraded to Windows
2000 Service Pack 4 (SP4) or later.

ADPREP /forestprep command extends the schema with quite a few new classes and attributes. These new schema objects are
necessary for the new features supported by Windows Server 2008. You can view the schema extensions by looking at the .ldf
files in the \sources\adprep directory on the Windows Server 2008 DVD. These files contain LDIF entries for adding and
modifying new and existing classes and attributes.

ADPREP /domainprep creates new containers and objects, modifies ACLs on some objects, and changes the meaning of the
Everyone security principal.

Before you can run ADPREP /domainprep, you must be sure that the updates from /forestprep have replicated to all domain
controllers in the forest.

You can view detailed output of the ADPREP command by looking at the log files in the %Systemroot
%\system32\debug\adprep\logs directory. Each time ADPREP is executed, a new log file is generated that contains the actions
taken during that particular invocation.  The log files are named based on the time and date ADPREP was run.
Once you’ve run both /forestprep and /domainprep and allowed time for the changes to replicate to all domain controllers, you
can then start upgrading your domain controllers to Windows Server 2008 or installing new Windows Server 2008 domain
controllers.

Running ADPREP
In order to run ADPREP, insert the DVD media of Windows Server 2008 into the DVD drive of the appropriate Windows
2000/2003 DC, which, as noted above, should be the Schema Master of a forest.

Lamer note: You can use a network path or even copy the files locally to the server if you don't have a DVD drive on your DC…

If you're prompted to install Windows Server 2008, do NOT install it. Close the window instead.

Browse to the \sources\adprep directory.

Open a Command Prompt window (Click Start > Run > CMD > Enter), and drag the ADPREP.exe file to the Command
Prompt window.

Lamer note: If you can't drag 'n drop, you can simply type the path… duh…
In the Command Prompt window, type the following command:

In order to prevent accidental running of the command, you must press the "C" key on your keyboard, then press Enter.
Command will begin to load a bunch of LDIF files containing all the necessary changes to the existing AD and Schema. Process
will take a few moments.

When done, you'll be prompted. Make sure you let the existing Domain Controllers replicate all the changes throughout the entire
forest BEFORE proceeding to the next step.
Next, go to the Infrastructure Master of each domain that you wish to upgrade and insert the DVD media of Windows Server
2008 into the DVD drive. Repeat the instructions to open the Command Prompt window, and type:

Unlike the /forestprep action which takes some time, the /domainprep action is almost instantaneous.

Note: The existing Windows 2000/2003 domain MUST be in Native mode, as not Windows NT 4.0 BDCs are supported by
Windows Server 2008 DCs. Therefore, if that is not the case, you'll get this error:

Switch your domain to Native mode or above, then repeat the operation.
Again, make sure you let the existing Domain Controllers replicate all the changes throughout the domain BEFORE proceeding to
the next step.

Repeat the /forestprep action for each domain in the forest that requires new Windows Server 2008 Domain Controllers.

Windows 2000 Domain Notes

When upgrading Windows 2000 domains, an additional command must be run before installing the first Windows Server 2008
DC.

Go to the Infrastructure Master of each domain that you wish to upgrade and insert the DVD media of Windows Server 2008
into the DVD drive. Repeat the instructions to open the Command Prompt window, and type:
This command performs similar updates as domainprep. However, this command also provides updates that are necessary to
enable Resultant Set of Policy (RSOP) Planning Mode functionality. In Active Directory environments that run Microsoft
Windows® 2000, this command performs updates during off-peak hours. This minimizes replication traffic that is created in
those environments by updates to file system permissions and Active Directory permissions on existing Group Policy objects
(GPOs). This command is also available on Microsoft Windows Server 2003 with Service Pack 1 (SP1) or later.

Windows 2003 Domain and first RODC Notes

In Windows Server 2008, a new Domain Controller installation option is available, called Read Only domain Controller. I will
not go into detail about RODCs in this article (search my site for more information about RODCs), however, in order to enable
the installation of the first RODC in an existing Windows Server 2003 Active Directory forest, where you have already added at
least one Windows Server 2008 regular DC, you must run the following command:

This command updates permissions on application directory partitions to enable replication of the partitions to RODCs. This
operation runs remotely; it contacts the infrastructure master in each domain to update the permissions. You need to run this
command only once in the forest. You can run this command on any computer in the forest. You must be a member of the
Enterprise Admins group to run this command.

Installing Active Directory on Windows 2008 Server Core

In my previous articles (see list below) I have written about how, in Windows Server 2008,  Server Core installation does not
include the traditional full graphical user interface (GUI). Therefore, once you have configured the server, you can only manage it
locally at a command prompt, or remotely using a Terminal Server connection. Read more about Server Core on my
"Understanding Windows Server 2008 Server Core" article.

Server Core can host a few roles. See my "Managing Windows 2008 Server Core Server Roles" article for more info. One of
these roles can be the Active Directory Directory Services (AD DS) role, where the server will act as a Domain Controller for an
Active Directory domain. This Domain Controller (or DC for short) can be used as one of the following DC scenarios:

 The first DC in a new Active Directory Domain, inside a new Active Directory Forest
 An additional (replica) DC in an existing Active Directory Domain
 A Read Only DC (RODC) in an existing Active Directory Domain, in case you already have at least one regular DC
running Windows Server 2008 in that domain
 The first DC in a new Active Directory Domain (child domain), under an existing Active Directory Tree, inside an
existing Active Directory Forest
 The first DC in a new Active Directory Domain, as a new Active Directory Tree, inside an existing Active Directory
Forest

Now, one might wonder how would you go about managing that DC if it were to run on a GUI-less server core. Well, the answer
for that is based on 3 parts. The first part is to get your server core up and running. In order to do that, read my server core articles
under the Related Articles section below. To make life easier on you, I've also written about a GUI tool called CoreConfigurator –
read more about it on my "Easily Manage Windows Server 2008 Server Core Settings with CoreConfigurator" article.

The second part is the management of the specific Active Directory DS role that you're about to install on the core. That can be
easily done from one of your regular Windows Server 2008 DCs, or even from a workstation computer running Windows Vista.
Read more about it on my "Installing Remote Server Administrative Tools on Windows Vista" article.

The third part is the process of the installation of the Active Directory DS role. It is done through the Active Directory Domain
Services Installation Wizard (DCPROMO.exe). It performs the following tasks:

 Installs Active Directory Domain Services (AD DS) on Windows Server 2008-based workgroup servers and member
servers
Or, if you run it on a server that is already configured as a DC:

 Removes AD DS from Windows Server 2008-based domain controllers

As noted above, since server core does not have a GUI, you will need to manually configure the DCPROMO settings and run
them as an unattended process.

So, now let's go to the business of actually installing the role. In order to install Active Directory DS on your server core machine
you will need to perform the following tasks:

1. Configure an unattend text file, containing the instructions for the DCPROMO process
2. Configure the right server core settings + meet the DCPROMO requirements
3. Copy that file to the server core machine
4. Run the DCPROMO process with the unattend file
5. Reboot the computer

Let's begin...

Configure an unattend text file

First, let's create the unattend, or answer, file. The unattend file is an ASCII text file that provides automated user input for each
page of the Active Directory Domain Services Installation Wizard.

One method of creating the unattend file is by editing a sample file you've created before or obtained from other sources (like this
website). This is an example of such an Unattend file. In this example you will create an additional DC for a domain called
petrilab.local:

Another method is by creating it through the DCPROMO wizard that you've ran on a different server. Read "Creating an
Unattend Installation File for DCPROMO in Windows Server 2008" for more information.

Configure the right server core settings

After that you need to make sure the core machine is properly configured.

1. Perform any configuration setting that you require (tasks such as changing computer name, changing and configure IP
address, subnet mask, default gateway, DNS address, firewall settings, configuring remote desktop and so on).

2. After changing the required server configuration, make sure that for the task of creating it as a DC – you have the
following requirements in place:

 A partition formatted with NTFS (you should, it's a server…)

 A network interface card, configure properly with the right driver
 A network cable plugged in
  The right IP address, subnet mask, default gateway

And most importantly, do not forget:

 The right DNS setting, in most cases, pointing to an existing internal DNS in your corporate network

Copy the unattend file to the server core machine

Now you need to copy the unattend file from wherever you've stored it. You can run it from a network location but I prefer to
have it locally on the core machine. You can use the NET USE command on server core to map to a network path and copy the
file to the local drive. You can also use a regular server/workstation to graphically access the core's C$ drive (for example) and
copy the file to that location.

Run the DCPROMO process

Next you need to manually run DCPROMO. To run the Active Directory Domain Services Installation Wizard in unattended
mode, use the following command at a command prompt:

Reboot the machine

In order to reboot the server core machine type the following text in the command prompt and press Enter.

After the server comes back online you'll have yourself a new and shining DC running on a server core machine.

Running it all from one command line

Using an unattended file for DCPROMO is fine, and if you've prepared one handy it's quite easy. However, there's another
method.

DCPROMO will accept command line switches, and if provided correctly, it will use them to perform the required tasks. For
example, running the following command:

will run DCPROMO and add the server as a Global Catalog server to the petrilab.local domain. The Domain restore Mode
password will be set to P@ssw0rd1. You will be asked to enter the domain administrator password when the command is run.

The server will reboot itself as part of the install.

BTW, to see the construction of the command we can enter the following command. It will create a text file containing the
required information.
How to Install Microsoft Virtual Machine (VM) Additions on Windows
Server Core 2008
As you already know by now, in Windows Server 2008,  Server Core installation does not include the traditional full
graphical user interface (GUI). You can read more about Server Core on my "Understanding Windows Server 2008 Core" article.

Without going to much into detail, because of the lack of GUI, installing applications on server core might be more complex than
installing them on a regular server installation, not to mention the fact that they might not function at all. One of these
applications is the Microsoft Virtual Machine (VM) Additions that comes with Microsoft virtualization products such as Virtual
PC 2007 and Virtual Server 2005 R2 SP1. VM Additions greatly improve the guest's performance.

Virtual Machine Additions adds the following enhancements to a guest operating system:

 Improved mouse cursor tracking and control

 
 Greatly improved overall performance
 
 Virtual machine heartbeat generator
 
 Optional time synchronization with the clock of the physical computer

You can read more about it on my "Installing VM Additions on Windows Server 2008/Vista" article.

Now you might be asking yourself "Why would I want to install VM Additions on Server Core? It doesn't have a GUI to worry
about, so why bother?". Well, you see, the answer to that question is that although you're not likely to sit around the core
installation and play Solitaire on it, many performance issues will be solved simply by installing the VM Additions, and since
installing them doesn't cost money nor is it complicated, why not do it?

So now you're probably wondering if installing VM Additions is so easy, why did Daniel bother writing an article about it. True,
installing VM Additions on a server core is exactly the same as installing them on any regular operating system, except for the
fact that Auto-Run will not invoke the installer, and thus you must do so manually.

In order to install VM Additions you first need to mount the VMAdditions.iso file found in the C:\Program Files\Microsoft
Virtual Server\Virtual Machine Addition folder. This can be easily done by mounting the ISO file through VMRC Plus, or, if
you prefer, by using the Virtual Server 2005 web management console.

Note: If you don't know VMRC Plus, it's time that you did. Read more about it on my "Manage Virtual Server Machines with
VMRC Plus" article.

In VMRC Plus (which is my preferred method of managing VMs under Virtual Server 2005), right-click on the server core
virtual machine and select Settings.
In the Settings window, right-click the CD/DVD and select Attach Media Image File. Browse to the VMAdditions.iso file
found in the C:\Program Files\Microsoft Virtual Server\Virtual Machine Addition folder.
You can also use the VM Console itself and on the Core VM, select Media -> Load ISO Image.
Browse to the VMAdditions.iso file found in the C:\Program Files\Microsoft Virtual Server\Virtual Machine Addition
folder.
Back inside the VM, in the command prompt window, type D: (or any other drive letter that represents your CD/DVD drive).
Once there, go to the Windows folder by typing

Type Dir to see the folder's contents if you want. Note that the installation file is called Setup.exe.

The installation process will begin.

In the Virtual Machine Additions window click on Next.

The installation process will take a few seconds to run.

Once completed, click on Finish.

You need to reboot to complete the installation. Click Yes to reboot now, or, if you want to reboot later, type the following
command in the command prompt window:

Enjoy the better performance from your server core VM!

 Implementing Hyper-V in Windows Server 2008
When it comes to file and application servers, often times the server hardware is grossly underutilized. In fact, many servers
only use about ten percent of the hardware’s total capacity. For several years now, Microsoft and various third party companies
have offered server virtualization solutions that allow you to run multiple server instances on a single physical computer.

When Microsoft released Windows Server 2008, they introduced a new feature called Hyper-V. Hyper-V is a server virtualization
role that is designed to be the successor to Microsoft’s Virtual Server 2005. As you might expect though, Hyper-V uses
completely different installation and configuration methods than its predecessor did. In Part 1 of this series on Windows Server
2008 Virtualization, we learned about Planning for Windows Server 2008 Virtualization. In Part 2 in this series, I will show you
how to install the Hyper-V role on Windows Server 2008. In the next article in the series, I will show you how to actually create a
virtual server that can run in a Hyper-V environment.

Perform a Clean Installation

The first thing that I recommend doing is to perform a clean installation of Windows Server 2008. Server virtualization is
extremely resource intensive, far more so than most other server applications, so I recommend using a clean Windows installation
on a dedicated server.

Installing the Hyper-V Role

Now, log in using an account with local administrative privileges, and then open the Server manager. In case you aren’t familiar
with the Server Manager, it’s the new tool that acts as a centralized management utility for Windows Server 2008. You can access
it by entering the ServerManager.msc command at the server’s Run prompt.

When Server Manager opens, right click on the Roles container, and then choose the Add Roles command from the resulting
shortcut menu. Windows will now launch the Add Roles Wizard.

Click Next to bypass the wizard’s Welcome screen and then you should see a screen similar to the one shown in Figure A, asking
you which roles you would like to install. Select the Hyper-V check box, and then click Next.

Figure A
You must choose the Hyper-V Role.

At this point, you will see the screen that’s shown in Figure B. Basically, this screen just tells you that you may end up needing to
enable virtualization at the BIOS level prior to installing the Hyper-V roll. Some servers require this, and others don’t. The screen
also tells you that after installation is complete, you can use the Hyper-V Manager to create and configure your virtual machines.
The serene also contains a few links that you can use to access more information about the Hyper-V role.

Figure B

This screen allows you to access more information about the role that you are installing.

Click Next, and you will be taken to a screen similar to the one that’s shown in Figure C. As you can see in the figure, your
virtual machines require virtual networks in order for them to be able to communicate with other network hosts. Essentially, this
screen allows you to choose the physical network adapter that you want to bind the virtual network adapter to.
Figure C

You must bind the virtual network adapter to at least one physical network adapter.

You have the option of choosing multiple network adapters for load balancing, but you also have the option of using a single
physical network adapter for all of your virtual machines. When you have made your selection, click Next.

You should now see a screen confirming that you are about to install the Hyper-V role, and warning you that the server may
require a reboot after installing the role. Now, just click the Install button to install the role. The actual amount of time that it
takes to install the role varies depending on your server’s performance, but the entire process took about 20 seconds on my server.

When the installation process completes, click the Close button, and then click Yes when you are prompted to reboot the server. 
When the server reboots, log back into the server and the Server Manager should automatically load and resume the installation
process. After about a minute, you should see a message telling you that Hyper-V has installed successfully. Click Close to
complete the wizard.

Conclusion
In this article, I have shown you how to install the Hyper-V role. I will show you how to configure a virtual machine in the next
article in this series: Creating and Managing Virtual Servers with Windows 2008 Server & Hyper-V
 Creating and Managing Virtual Servers with Windows 2008 Server &
Hyper-V
In the two previous articles in this series (Planning for Windows Server 2008 Virtualization and Implementing Hyper Vision
in Windows Server 2008), I walked you through planning and installing Windows Server 2008 Hyper-V. In this article, I will
continue the discussion by showing you how to install a virtual operating system.

Installing a Virtual Operating System

Open Server Manager and then navigate through the console tree to Roles -> Hyper-V -> Microsoft Hyper-V Server. If this is
the first time that you have used Hyper-V, then you will be prompted to accept Hyper-V License Agreement.  Once you accept
the license agreement, the various Hyper-V options will be made available to you.

The first thing that you must do is to click on the Connect to Server link, located in the Actions pane. When you do, you will be
prompted to select the computer that you want to connect to. Choose the Local Computer option, and click OK. You will now
see the screen shown in Figure A.

Figure A

This is the main screen that you will use for managing virtual machines.

Creating a New Virtual Server

To create a new virtual server, click the New -> Virtual Machine options found in the Actions pane. When you do, Windows
will launch the New Virtual Machine Wizard. The wizard’s initial screen explains that you can click Next to begin customizing a
virtual machine, but that you also have the option of clicking Finish right now to create a virtual machine that uses the default
values. For the purposes of this article, I will create a custom virtual machine so that you can see the options that are available to
you.

With that said, click Next and you will be prompted to enter a name and a location for the virtual machine that you are creating. I
recommend using a descriptive name. The location is up to you, but if your server contains a striped RAID array, then that is a
good location to choose for performance reasons.

Click Next and you will be prompted to enter the amount of memory that is to be assigned to the new virtual machine. By default,
new virtual machines are assigned 512 MB of RAM, but that isn’t really enough if you plan on running Windows Vista or
Windows Server 2008. I would recommend 1 GB for Vista and 2 GB for Windows Server 2008 installations.

Click Next, and the wizard will prompt you to choose which network adapter you want to use for the machine’s virtual network
connection. As you may recall, when you installed Hyper-V, you were given the opportunity to select one or more network
adapters to be used by virtual machines. This option allows you to pick from the network adapters that you previously selected.
The idea is that you can use a different network adapter on each virtual machine if you want, so that no single network adapter
becomes over burdened.
When you have made your selection, click Next, and you will be prompted to choose the virtual hard drive that you want the
machine to use, as shown in Figure B. As you can see in the figure, you can either create a new virtual hard drive, or you can use
an existing one. Since there aren’t any existing virtual hard drives right now, we will have to create a new one. Windows defaults
to creating a virtual hard drive that’s 127 MB in size, but you can create a drive of up to 2 TB if you want.

Figure B

You must specify the size of your new virtual hard drive.

Click next, and you will be prompted to install an operating system on the new virtual machine. You have the option of installing
an operating system later on, but you can also choose to install from a CD (or an .ISO file), a boot floppy, or from an installation
server, as shown in Figure C.

Figure C
You can choose to install an operating system now.

When you’ve made your choice, click Next. You will now see a summary of the options that you have created. If you have
chosen to go ahead and install an operating system, then insert the operating system media, select the option to start the virtual
machine, and click Finish. Windows will now launch the virtual machine and begin installing the operating system, as shown in
Figure D.

Figure D

Windows will launch the new virtual machine and begin installing the guest operating system. And with that, we are done!

Conclusion
In this final article in this 3 part series, I have shown you how to create a custom virtual machine with Windows Server 2008
Hyper-V. If you haven't read the two previous articles in this series, please see Planning for Windows Server 2008 Virtualization
and Implementing Hyper Vision in Windows Server 2008
 Planning for Windows Server 2008 Virtualization
The concept of server virtualization has been around for quite a few years now, but it seems to just now really be taking off. 
The basic idea behind server virtualization is that many servers tend to be grossly underused.  It is not uncommon for a server to
only use about 10% of its hardware resources.  Virtualization allows a single physical server to run multiple guest operating
systems as a way of making more efficient use of the hardware.

Virtualization in Windows Server 2008

In Windows Server 2008, Microsoft includes a virtualization technology called Hyper-V. The biggest advantage that Hyper-V
offers over its predecessor (Virtual Server 2005) is that it offers full 64-bit support.  In fact, only 64-bit versions of Windows
Server 2008 support Hyper-V. Hyper-V is capable of running both 32-bit and 64-bit guest operating systems.

Although it is fairly easy to deploy Hyper-V and the guest operating systems that run on it, you're going to need to do some
planning beforehand in order to make sure that your server is up to the job.  Although servers tend to be underutilized, utilization
can go way up when you start running multiple operating systems.  As such, hardware planning is critical.

Hardware Planning for Hyper-V

I have already mentioned the 64-bit requirement, but Hyper-V also requires virtualization support from the underlying hardware. 
The reason for this is that most virtualization technologies work by piggybacking the guest operating systems on top of the host
operating system.  Although this technique works, it does have one serious flaw.  Problems with the host operating system can
directly affect the guest operating systems. For example, a buggy device driver for a network card could cause networking to fail
for all of the guest operating systems running on the server.

Hyper-V is constructed differently though. Although it still depends on the host operating system to a degree, each guest
operating system is also allowed to interact directly with the hardware. This not only helps to eliminate some of the potential 
single points of failure, but it also helps to reduce the amount of processing that must be done in order to host a guest operating
system. As I mentioned though, the hardware must support virtualization at the BIOS level.

Now that I've talked a little bit about how Hyper-V works, I want to discuss some of the other hardware requirements. There
aren't any firm CPU requirements beyond the 64-bit requirement that I am aware of, but Hyper-V is designed to allow you to
assign processor cores to various guest operating systems. Each guest operating system supports up to four CPU cores.

The memory requirements associated with Hyper-V vary widely depending on the virtual machines that you plan on running.  As
a general rule, plan on dedicating 2 GB of memory to the host operating system.  You also have to have sufficient memory to
support each guest operating system.  For example, if you're running three virtual instances of Windows Server 2008, each
requiring 2 GB of memory, then the total amount of memory required by the server will be 8 GB.

There aren't any firm requirements as to the amount of hard disk space that you have to have, but there are some limits that you
need to be aware of. Each guest operating system runs on a virtual hard drive, that is essentially just a file that works similarly to a
page file.  Each virtual hard drive must be at least 4 GB in size, but you can allocate up to 2 TB.

I would recommend installing the host operating system onto the server's boot drive, and then storing the guest operating systems
on a raid array for performance reasons.

The last thing I want to quickly mention is virtual machine management. Windows Server 2008 comes with everything you need
to manage the virtual machines that are running on the server.  However, if you have multiple machines that are each hosting
multiple virtual servers, then you may need a more powerful management tool than what is provided.  In such situations,
Microsoft recommends using System Center Virtual Machine Manager.  This is not an absolute requirement, but it will allow you
to manage large numbers of virtual servers more efficiently.

Conclusion
In this article, I have explained that Hyper-V is a powerful server virtualization solution. As you might expect of such a
demanding solution, Hyper-V has some unique hardware requirements that must be addressed prior to deploying your virtual
server environment. Continue reading more on this topic in Part 2 of this series on Windows Server 2008 Virtualization,
Implementing Hyper-V in Windows Server 2008 and Part 3, Creating and Managing Virtual Servers with Windows 2008 Server
& Hyper-V.
 DHCP Server Migration Made Easy in Windows Server 2008
If you have ever had to move a DHCP Server from one physical server to another, you know that the process isn’t exactly fun or
intuitive if the servers are running Windows Server 2003. Fortunately, when Microsoft created Windows Server 2008, they
completely redesigned the administrative interface, and in doing so, also made DHCP much easier to migrate. In this article, I will
show you how it’s done.

Migration in Windows Server 2003

Since this article is supposed to be about Windows Server 2008, I don’t want to talk too much about Windows Server 2003. Even
so, I do want to give you a quick overview of the migration process that was used in that version of Windows so that you can
better appreciate what I am about to show you.

To migrate a Windows 2003 DHCP Server, the first thing that you must do is to stop, and then disable the DHCP service. Of
course this means that clients will not be able to use the DHCP server to obtain IP addresses until the process is complete.  You
must then copy the server’s \%systemroot%\system32\DHCP folder to a safe location that you can use later on. After doing so,
you should remove this folder from the original server.

Next, you will have to do some work through the Registry Editor. As always, when you are working with the Registry Editor, you
should make a backup first, because making an incorrect change can destroy Windows. With that said, navigate through the
Registry Editor to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Configuration. Now,
choose the Save Key command from the editor’s Registry menu, and export the registry key to a safe location. When you are
done, you can uninstall the Add / Remove Windows Components Wizard to uninstall the DHCP server component.

Restoring a DHCP Server Backup in Windows Server 2003

Before you can restore your DHCP server backup, you must install the DHCP server component onto the new server, but after
doing so, you must stop and temporarily disable the DHCP service. Now, check the backup directory that you created earlier for a
file named system.mdb. If this file exists, rename it to system.src. You may now copy all of the files from the backup directory
to the new server’s %systemroot%\system32\DHCP folder.

Now you have to restore the backup copy of the registry that you created earlier. To do so, open the Registry Editor and navigate
through the registry tree to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Configuration. Choose the Restore
command from the editor’s Registry menu, and then restore the registry backup file that you created earlier.  When you are done,
close the Registry Editor, reboot the machine, and then enable and start the DHCP service.

Migration in Windows Server 2008

As you can see, moving the DHCP service from one server to another in Windows Server 2003 was a real pain. Fortunately, the
process is a lot easier in Windows Server 2008. Begin the process by opening the DHCP Manager, found on the server’s
Administrative Tools menu. When the console opens, right click on the server name, and then choose the Backup command from
the resulting shortcut menu, as shown in Figure A.
Figure A

Right click on the server’s name, and choose the Backup command from the resulting shortcut menu.

When you do, Windows will prompt you to enter a location for the backup file that you are creating. After entering a location,
click OK, and the backup file will be created.

Restoring a DHCP Backup in Windows Server 2008

Microsoft makes restoring a backup just as easy. To do so, just open the DHCP management console, right click on the server that
you want to restore the backup to, and choose the Restore command from the resulting shortcut menu. You can see the Restore
option shown in Figure A. Now, just specify the location of the backup that you want to restore, and click OK. Windows will now
ask you if it is OK to stop and restart the DHCP Server service, as shown in Figure B. Click Yes, and the restore will begin. When
the process completes, the DHCP Server service should automatically restart with the new settings.

Figure B

You must restart the DHCP Server service in order for the restore operation to work correctly.

Conclusion
In this article, I have shown you how to migrate a DHCP Server configuration from one server to another. Keep in mind that
regardless of whether you are performing this procedure in Windows Server 2003 or Windows Server 2008, you must disable any
DHCP server that contains a conflicting scope prior to performing a restoration.
 Creating a Group Policy Central Store for Windows Vista and Server
2008
One of the issues that sometimes made managing group policies difficult in Windows XP and in Windows Server 2003 was
the non centralized nature of the group policy template files. For example, Microsoft offers downloadable templates that allow
you to manage Microsoft Office via group policy. Even so, these templates are not automatically available from every domain
controller.

In Windows Vista and Windows Server 2008, Microsoft decided to make life easier for network administrators by introducing the
concept of centralized group policy storage. This storage repository, known as a central store, can be created in domains
containing Windows Server 2003 and / or Windows Server 2008 domain controllers. Even though Windows Server 2003 does not
technically support centralized group policy storage, Windows Vista does, and this allows you to store the central store on
Windows Server 2003 domain controllers if necessary, but manage the central store through Windows Vista.

How Does a Central Store Work?

As you may have gathered from the previous paragraph, there is really nothing special about the central store itself. It is nothing
more than a folder on a server. The reason why a central store can work the way that it does is because of the way that the store is
used by Windows Vista and Windows Server 2008.

When an administrator attempts to create or edit a group policy template, Windows checks the domain controller to which it is
connected for the existence of a central store. If a central store exists, then Windows will use that central store by default.
Otherwise, local copies of the template files are used.

Creating a Central Store

Creating a central store is actually a rather simple process. The first thing that you will have to do is to log onto a computer that is
running either Windows Vista or Windows Server 2008. If you have one particular machine that has all of your group policy
template files installed on it, then that machine is a good candidate.

The next thing that you must do is to open Windows Explorer, and then go into the C:\Windows folder. Locate the
PolicyDefinitions folder, right click on it, and then choose the Copy command from the shortcut menu. This will copy the folder
and its contents to the Windows clipboard.

The next step in the process is to map a network drive letter to the sysvol folder on a domain controller. The full path that you will
need to access on the domain controller is c:\Windows\SYSVOL\domain\Policies. Finally, copy the PolicyDefinitions folder to
the \Windows\SYSVOL\domain\Policies folder on the domain controller. You can see what this looks like in Figure A.
Figure A

Copy the PolicyDefinitions folder to the domain controller’s \Windows\Sysvol\Domain\Policies folder.

Testing Your Central Store

In order to gain the maximum benefit from the central store that you have created, I recommend that you periodically run tests to
make sure that the central store is actually being used. Fortunately, testing a your central store is even  easier to do than creating
the central store was. To do so, open the Group Policy Management console. Now, navigate through the console tree to Forest |
Domains | your domain | Group Policy Objects | Default Domain Controller Policy. Upon selecting this policy container, the
pane on the right side of the console should display a series of tabs. Go to the Settings tab, and look at the Administrative
Templates section. It should confirm that the policy definitions (the ADMX files) have been retrieved from the central store.

One thing that you must keep in mind about this technique is that you may occasionally run into situations in which the Settings
tab for a particular group policy template does not even contain an Administrative Templates section, let alone tell you that the
template was retrieved from the central store. The reason why this occasionally happens is that the Administrative Templates
section is only displayed if the group policy object contains at least one setting.

Conclusion
As you can imagine, keeping group policy templates in a central location can be a significant management issue for companies.
However, Windows Server 2008’s (and Windows Vista’s) ability to create a central store greatly simplified the process of
keeping track of the various group policy objects that are in use within your company.
 How to Extend a Disk Partition in Windows Vista and Server 2008
Microsoft operating systems, starting from Windows NT 4.0, Windows 2000, Windows XP, and now Windows Vista and
Windows Server 2008, have always had a built-in method of extending or expanding a partition that was configured on the
computer's physical hard disks. While shrinking partitions was not possible internally, and usually required usage of 3rd-Party
tools, expanding partitions was relatively easy, but did have its limitations. Now, unlike previous Microsoft operating systems,
Windows Vista and Windows Server 2008 allow for an easy, out-of-the-box, method of expanding those partitions and making
them larger, while reliving us of these previous limitations.

This is made possible by using the Extend feature in Disk Management, or in the DISKPART command line executable. When
you extend a partition, all data on the existing partition will NOT be erased, but it's better to be safe than sorry, therefore I always
recommend using a good backup procedure to back up your data, just in case.

Extending a partition in Windows Server 2008 is similar to the process in Windows Vista. I've used screenshots of Windows
Vista, except the ones related to Server Manager in Windows Server 2008. The rest of the procedure is the same.

Extending a partition by using the GUI

1. Like in most administrative tasks, you must logged on as an Administrator.

2. In Windows Vista, go to Control Panel --> System and Maintenance > Administrative Tools, or on the My
Computer context menu. Select Computer Management. In Vista, if you are prompted for an administrator password
or confirmation, type the password or provide confirmation.

3. In Windows Server 2008 you need to go to Server Manager, found in the Administrative Tools folder or on the My
Computer context menu.

4. Next, scroll down till you get to the Storage section, and in it go to the Disk Management console.

5. Select the disk you want to extend, for example Drive C.

Note: Extending any volume is fine as long as you have additional unallocated free space on that same physical hard
disk . Note that you can also extend the partition beyond the physical disk it is located on. This is useful when you run
out of space on that physical hard disk, and have brought in a new physical hard disk that you wish to use. However,
unlike using that new disk as a totally new partition by itself, this disk (or part of it) becomes a part of a partition located
on the first disk. While useful in some cases, this scenario might cause fault tolerance issues, because this extended
partition is NOT fault tolerant, and if something happens to one physical disk, all the data on that extended partition
becomes unavailable, and data loss can occur. In any case, such an extended partition can contain an unlimited number
of logical drives.

6. Right-click the disk and select Extend Volume.

 Windows Server 2008 it looks like this:

7. Click Next.
  

8. Windows Vista tell you how much space can be added to the existing partition. You can manually enter the amount of
space you want to add by changing the "Select the amount of space in MB" values. However note that you cannot enter a
higher value than the value already present. As noted above, if you have additional physical hard disks that have
unallocated free space, you can add that space up and further extend the partition to span multiple disks. Again, be
warned, this configuration is NOT fault tolerant. In case one of the disks malfunctions, you will lose your data.

9. The process will finish quite quickly, and a reboot is NOT required.
Extending a partition by using the command line
Extending a partition or volume can be done via the CLI, or command line interface. This works in both Vista and Windows
Server 2008. In order to do that perform the following steps:

1. Click Start and type CMD, then press Enter.

2. In the command prompt type

 
3. Select the right disk drive and partition to work on. Typically this should be disk 0 and partition 1, but YMMV.

Note: You may want to perform a LIST operation to view your existing disks and partitions BEFORE attempting to
expand the wrong one. Needless to say, if you don't have any space you can use on the same disk, you will NOT be able
to extend the partition any further. So no real harm can be done here.

 
4. When the right disk and partitions were selected, perform the EXTEND command. If you don't specify the size to extend
by, then the command will extend the partition by using all of the contiguous space available on that disk.

The above command will extend the partition by 500 MB.

The above command will extend the partition by using all of the contiguous space available on that disk.

And with that, we are all done

 Creating security alerts of abnormal user actions on Windows servers
using Microsoft System Center Operation Manager 2007 and ObserveIT
System and software downtime frequently mean lost revenues, lowered employee productivity and reduced customer
satisfaction. Despite the fact that companies are investing in high-availability systems and performance monitoring solutions for
data centers, many are failing to follow best practice procedures to avoid human errors.

While some very limited capabilities exist within the built-in Windows Auditing mechanism, they are limited to a very basic set
of actions, such as shutting down a system or deleting a file. Even if configured properly, these resulting events are cryptic and
hard to understand, quickly filling the Windows Event Viewer and giving only a limited understanding of what the user has done
during that period.

Imagine being able to receive alerts whenever a user performs an action such as deleting a file, opening a specific network share,
using the Registry Editor to change a key or value, opening an RDP connection to a specific server, or even using Internet
Explorer to navigate to a specific page in the company’s intranet website. Existing Windows Auditing cannot even begin to
deliver this capability. Imagine being able to distinguish between various users, all logging on as “Administrator” to your servers,
and knowing the exact name of the person logging on. Furthermore, imagine being able to visually replay the entire user session
whenever such an alert is received, thus visually seeing what the user did, where else they performed the same action, and what
the context of their action was. ObserveIT for Servers can do just that.

About ObserveIT
ObserveIT for Servers is a client/server software application that monitors, audits and records all activities performed by people
on an enterprises servers. The indexed, searchable, visual database allows those activities to be replayed to see exactly what is
happening on the monitored servers.

When using ObserveIT, all user sessions are captured and recorded. Whenever a user logs on to the server, either locally or by
using RDP/VNC/Damware/NetOp or other means, a user session is created, and any application opened by the user in that session
is fully recorded. ObserveIT captures the screen seen by the user, and by combining multiple screenshots into one stream, a video
is created.

In addition to capturing the screen image for each user action, ObserveIT for Servers extracts information about the state of the
operating system and the application being used, which allows ObserveIT for Servers to precisely identify what the user is doing
in any given moment. This metadata is analyzed and encoded in a standardized format that is stored in the Database Server.
Because this information is stored along with the metadata describing what is seen on the screen, you can perform very powerful
searches across your entire enterprise.
Another feature of ObserveIT is its capability to also create textual log files for monitoring purposes. These files are stored on the
server’s hard disk, and can be parsed by 3rd-party tools such as Microsoft System Center Operation Manager 2007, generating
events or alerts based upon information written in them.

Read more about ObserveIT in the following link:

Record and Replay Terminal, Citrix and console window sessions

(http://www.observeit-sys.com)

About Microsoft System Center Operation Manager 2007

Microsoft System Center Operation Manager (SCOM) 2007 is a unified IT management tool scaled to the needs of mid to
enterprise-sized businesses. Microsoft System Center Operations manager 2007 contains some great tools that allow you to
monitor conditions that can occur on monitored servers or workstations. By using SCOM 2007 to parse the textual log files
created by ObserveIT, we can easily create a Unit Monitor that will query these log file for specific string of text, and will set the
health state based on the match. By carefully selecting the correct string, the monitor can be triggered by a pre-defined textual
string, which will set the health state of the monitored server to either warning or critical state. We can then further extend these
capabilities by generating E-mail, SMS or Instant Messenger alerts, immediately notifying us about a specific server’s change of
state.

In this guide, we will demonstrate the process of creating a new monitor in SCOM 2007, and use the log files generated by
ObserveIT to identify actions performed by users, or applications that were used on any server monitored by ObserveIT.

Creating a new monitor

Please follow these steps in order to create a Unit Monitor, based on ObserveIT’s monitoring log files:

On a server that is installed with System Center Operation Manager, log on with an account that is a member of either Operations
Manager Administrators or Operations Manager Authors.

Open the Operations Console from the Start > Programs > System Center Operations Manager 2007 menu. In the
management console, click and expand the Authoring button, expand Management Pack Objects, and then click Monitors.

Click the Scope button. In the Scope Management Pack Objects by target(s) dialog box, in the Look for text box, type “Windows
Computer”. Select the Windows Computer target check box, and then click OK.
In the Monitors pane, expand Windows Computer > Entity Health. Right-click Security, and select Create a Monitor > Unit
Monitor.

Note: You can select a different target for the new monitor, based upon your requirements. You can also make changes to the
target during the monitor’s creation process, and afterwards.

In the Create Monitor Wizard, on the Select a Monitor Type page, expand Log Files > Text Log > Simple Event Detection.
Click Manual Reset, and then click on the Next button.
Note: You can select a different type of event, such as an Event Reset type, or Timer Reset. The Manual Reset type is triggered
when an event happens, but the reset is performed manually.

Note: In the above step, you can either select a Management Pack from the Select destination management pack list or create a
new unsealed Management Pack by clicking New. If you select to create a new Management Pack, give it an appropriate name
such as “ObserveITApplicationServer Management Pack” or similar.

On the General Properties page, in the Name box, type a name for the unit monitor, such as “Remote Access to 192.168.200.33”.
You can also type a description. In the Parent monitor list, click the appropriate parent monitor. Make sure that “Monitor is
enabled” is selected, and then click on the Next button.
On the Application Log Data Source page (for the First Generic Log), under Define the application log data source, in the
Description text box, type a path to where the log files are located. When using ObserveIT, you need to type the following path:

C:\Program Files\ObserveIT\NotificationService\LogFiles\1

In the Pattern text box, type a pattern string to select log files. In this case use “*.log” (without the quotes). If applicable, select
UTF8.

Note: In order to learn how to configure ObserveIT to record textual log files please consult with the product documentation.

Click on the Next button.

On the Build Event Expression page click Insert and then enter the following:

 Parameter Name = “Params/Param[1]” (without the quotes)

 Operator = "Matches Wildcards"
 Value = an expression to be searched for, for example, "*Remote Desktop Connection,192.168.200.33*"

Click on the Next button.

Note: You can obtain the required textual value by looking at one of the log files generated by ObserveIT. These files are located
in the following folder path:

C:\Program Files\ObserveIT\NotificationService\LogFiles\1

When you open one of these files, you’ll see that each recorded action is listed in a separate line containing the following
information:

FirstScreenshotTime, SessionId, ServerName, DomainName, LoginName, UserName, ApplicationName, WindowTitle

By looking at that information, you can easily see information such as this (actual data will vary, depending on your recorded
data):

 Server73,Mydomain.local,Administrator,gaby,Windows Explorer,\\192.168.200.73\c$
 Server33,Mydomain.local,Administrator,daniel,Remote Desktop Connection,192.168.200.33 - Remote Desktop
 Server12,Mydomain.local,Administrator,avi,Registry Editor,Registry Editor
 Server33,Mydomain.local,Administrator,daniel,Run a DLL as an App,Date and Time Properties
 Server80,Mydomain.local,Administrator,james,Windows Command Processor,C:\WINDOWS\system32\cmd.exe

And so on. Use whatever parameter you need.

Next, on the Configure Health page, for the Event Raised line, set the Health State type to “Warning” (or other, based upon your
requirements). Click on the Next button.
On the Configure Alerts page, use the default settings or select the Generate alerts for this monitor check box to set custom alert
properties, and then click on the Create button.
Note: In order to make future changes to this monitor, right-click it and select Properties.

The Monitor properties page will be displayed, allowing you to view or make changes to the monitor settings.
Back in the System Center Operation Manager main console, click on the Monitoring button. You can view computer status
messages by clicking on the Computers item on the left-hand pane.
You can also view any active alerts by clicking on the Active Alerts item on the left-hand pane.

A third method to view the alert is by using the Health Explorer for the specific server.

This concludes the process of creating a new monitor based upon the log files generated by ObserveIT. By using System Center
Operation Manager 2007 to monitor these log files, you can easily generate alerts and create events based upon actions performed
by users, or applications that were used on any server monitored by ObserveIT.
Managing Windows 2008 Server Core through RDP
As described in my previous articles, Windows Server 2008 has an interesting option to install it with a minimal graphical
user interface (or GUI for short). This method of installation is called "Server Core", and it allows an administrator to only install
the minimum binaries required to run a specific server role (currently, there are 9 possible Server Core roles). You can read more
about it on my "Understanding Windows Server 2008 Server Core" article.

Although Server Core has no real GUI (except a few tools such as Task Manager), we still need to access it locally in order to run
configuration and diagnostic commands on it. Some of these commands are accessible via remote MMC snap-ins, run from
remote management workstations or servers. However, some commands need to be run only on the local Command Prompt,
causing us to need to physically have access to the Server Core server.

This can be avoided by enabling the machine running Server Core to allow us to remotely connect to it by using the Remote
Desktop Protocol client, also known as mstsc. But before we can use it to connect to the machine, we need to make sure the
following issues have been dealt with. These requirements are:

 Configuring an IP address
 Configuring a server name
 Configuring an administrator's password
 Configured the server's firewall

You should, but are not required to, also join the server to your domain.

Next, in order to properly configure Server Core to allow ICMP replies, follow these steps:

To manage a server running a Server Core installation by using a terminal server client
1. On the server running a Server Core installation, type the following command at a command prompt:

This enables the Remote Desktop for Administration mode to accept connections.

BTW, in order to view your current settings you can type:

If you see "1" in the script output, that means that RDP connections are denied. If you see a "0", they will be allowed.

Note: If you are running the Terminal Services client on a previous version of Windows, you must turn off the higher
security level that is set by default in Windows Server 2008. To do this, type the following command at the command
prompt:
To enable remote management from an RDP connection through the firewall
1. To enable remote management from any MMC snap-in, type the following:

To open an RDP session with the Server Core machine

1. On the remote management computer, click Start > Run, type mstsc, and then click OK.
 
2. In Computer, enter the name of the server running a Server Core installation, and click Connect.

 
3. Log on using an administrator account.

 
4. When the command prompt appears, you can manage the computer using the Windows command-line tools.

Note that while you're logged on to the server, the original server console session is locked out.

 
5. When you have finished remotely managing the computer, type logoff in the command prompt to end your Terminal
Server session.

Summary
Windows Server 2008 Server Core installations, like any other servers, require remote management. In order to allow for that, the
server's Firewall and registry settings need to be changed. This article showed you how to do that.
 Planning a DFS Architecture, Part 1
When it comes to configuring file servers, many administrators choose to use a distributed file system  (DFS) rather than a
traditional standalone share point, because of the redundancy that DFS provides. Although DFS can greatly improve the
performance and availability of the data stored on your network, these benefits come at a price. There are several different ways
of setting up a DFS, and there are pros and cons of each method. This means that if you are considering implementing DFS for
the first time, then you are going to need to do some planning first. In this article series, I will explain what you need to know
about the various DFS options so that you can figure out which type of DFS is right for your organization.

A Quick Vocabulary Lesson

Before I get into the actual discussion of the planning process, there are some basic vocabulary terms that I
need to go over, just to make sure that we are all on the same page.

Term Explanation
A DFS Namespace is just a central namespace through which users can see a unified view of the shared folders
DFS Namespace
that are included in the DFS.
This is simply the server that hosts the DFS Namespace.
DFS Namespace
DFS Namespace Root The DFS root is the top level of the DFS namespace. The namespace root and the DFS
Server
namespace use the same name.
A DFS folder is simply a folder that is presented to a client within the DFS namespace, but below the DFS root. A
DFS Folder DFS folder can exist on the same server as is hosting the DFS root, but it doesn’t have to. DFS folders commonly
represent file system resources located on other servers.
A DFS tree is a reference to the DFS hierarchy. The tree starts with the DFS root, and contains all of the DFS
DFS Tree
folders that have been defined within the root.

A Standalone vs. A Domain Based Namespace

Now that I have given you a crash course in some of the more common DFS related terminology, let’s get started with the
planning process. The first thing that you are going to have to take into account when planning your DFS architecture is whether
you want to use a standalone DFS namespace, or a domain based DFS namespace.

Standalone Namespaces
Standalone namespaces tend to have a lot more limitations than domain based namespaces do. For starters, you can only host one
standalone namespace per server.  The server’s namespace matches the name of the server that hosts the root target.

As you would probably expect, a standalone namespace can only host a single root target, but you can include multiple DFS
folders within the root.

Like other DFS implementations, standalone namespaces do allow you to use multiple folder targets for fault tolerance purposes.
In case you are not familiar with folder targets, the basic idea is that each folder target typically hosts a replica of the data that’s
associated with a DFS folder. Using multiple folder targets allows you to achieve a degree of fault tolerance, and offers better
performance than if the data were only stored in a single location.

The problem with using multiple folder targets in a standalone namespace is that the targets must be manually synchronized
unless all of the servers that are hosting the target folders belong to a common Active Directory domain. Often though, standalone
namespaces are used in organizations that do not have an Active Directory in place, because as the name implies, a standalone
namespace will work in a standalone environment.

Domain-Based Namespaces
As you would probably expect, domain based namespaces require all servers to be members of an Active Directory domain.
These types of environments support automatic synchronization of DFS targets. The namespace root namespace is based on a
combination of the server’s NetBIOS name and a root name, and is listed in the DNS.
In a domain environment, a server is capable of hosting multiple DFS roots.

Conclusion
In this article, I have explained that one of the key decisions that you will have to make when planning a DFS architecture is
whether to use a standalone namespace, or a domain-based namespace. In Part 2 of this series, I will discuss how you can plan for
DFS replication.

Planning a DFS Architecture, Part 2

In the first part of this article series, I talked about the differences between a stand-alone DFS namespace and a domain based
DFS namespace.  The next thing I want to discuss is the replication topology that will be used by your DFS servers.

Why Replicate?
When I have introduced the concept of DFS to clients in the past, one of the first questions that they always ask me is why in the
world they need multiple DFS servers.  Technically, you don't have to have multiple DFS servers, but there are some advantages
to using multiple replica servers.  For starters, using multiple replicas provides you with a degree of scalability.  Rather than
having every user in your organization access their files from the same server, you can distribute the user workload across
multiple DFS replicas rather than over burdening a single server.

Another reason for having multiple DFS replicas is because doing so provides you with a degree of fault tolerance.  For example,
suppose that you need to install a service pack onto your servers.  Most of the time when you install a service pack for Windows,
the installation process requires you to reboot the server when you're done.  Normally, rebooting a server is disruptive to the users
who are accessing files on that server.  If you know that you're going to be doing maintenance on one of your servers though, you
can remove the server from the DFS namespace, and perform your maintenance without disrupting the users.  When you're done,
you can designate the server to act as a part of the namespace once again.

DFS can also provide fault tolerance from the standpoint of protecting you against network link failures.  For example, suppose
that your company has a branch office that is connected to the main office by means of a WAN link.  Normally, if the WAN link
were to fail then users in the branch office would lose access to any of the servers in the main office.  If you place a DFS replica
in the branch office though, then the users in the branch office can continue to access their files even during a WAN link failure. 
When the link is eventually reconnected, any modifications to files in either office will be synchronized with the other server.

Replication Topology
Windows Server 2008 supports a couple of different types of replication topologies for DFS servers.  Each of these topologies
have their good points and their bad points. If you are having trouble deciding which replication topology is right for your
organization, then you should give serious consideration to using the same DFS replication topology as you're using for your
Active Directory infrastructure.

The Hub and Spoke Topology

One of the most popular replication topologies is the hub and spoke topology, shown in Figure A. The hub and spoke topology
involves placing the initial master in the middle of the topology.  Each replica performs two way replication with the initial
master, but does not replicate with any of the other replicas.  This type of topology tends to be very efficient, but the problem with
it is that if the initial master were to fail, then all replication would cease to function until it came back online.
Figure A
This is what the hub and spoke topology looks like.

The Full Mesh Topology

Another commonly used replication topology is the full mesh topology. This topology, shown in Figure B, allows every replica to
replicate with every other replica.  The advantage of using this topology is that replication will still continue to function even if a
server drops off-line.  Of course the disadvantage to using this method is that it can result in an excessive amount of replication
traffic.
Figure B
The full mesh topology provides replication connectivity between every replica.

No Topology?
When you configure a replication group in Windows Server 2008, one of the topology options that Windows allows you to
choose from is No Topology.  As strange as it might sounds to not define a replication topology, there is actually a really good
reason for using this option.  The No Topology option allows you to create a replication group without defining a replication
topology.  This allows you to create your own custom replication topology later on.

Conclusion
As you can see, the replication topology plays an important part in the overall DFS architecture.  In Part Three of the series, I will
talk about some best practices for planning your DFS architecture.

Planning a DFS Architecture, Part 3

Note:This article is a follow up to Planning a DFS Architecture Part One and Part Two.

Although Windows Server 2008 improves upon DFS technology, DFS has been around for quite a while, and I have learned quite
a bit over the years about planning for DFS replication.  I'm not talking about the replication topology itself, although that is
important.  When I'm talking about are the little things that make the difference between replication performing well, and DFS
running amuck.  In this article, I want to wrap up the series by sharing with you some best practices for DFS replication.

Backup Strategy
Just because the files stored on a DFS tree are being replicated to other servers does not mean that you don't have to back them
up.  Having a DFS replicas on other servers helps to protect the data against a catastrophic hard drive failure, but does nothing to
protect against data corruption.  If a file were to become corrupted, the corruption would likely be replicated to the other targets.

Because the data should be identical on each DFS replica, you can usually get away with only backing up one of the replicas.  But
one important thing that you need to keep in mind about the backup process though, is that it is important that you configure your
backup software not to update the archive bit.  The reason for this is that file replication is triggered by a file version change, or a
modified date and time stamp.  As such, there is a chance that updating the archive bit could potentially trigger a mass
replication.  This doesn't happen in every case though (or at least as it for me anyway), so you may want to experiment to see if
the archive bit has any effect on your environment.

Disk Space
This one may seem obvious, but I have seen cases in which the drive containing the staging folder is either ridiculously small, or
low on space.  The drive containing the staging folder has to have enough free space to accommodate the replication process. 
After all, it will act as a temporary repository for replicated data that is being sent or received.

The DFS Root

There are several considerations that you should make when planning your DFS root.  I recommend starting with an empty DFS
root so that you can avoid replicating any data at the root level.  The DFS root should only contain folders that are managed by
DFS. 

I also recommend that you avoid replicating data between DFS namespace root folders.  The reason for this is that in doing so
Windows will try to replicate not only the root, but also the target folders within it.  While this may not sound like such a bad
thing, keep in mind that the target folders are already replicating independently of the root in most cases.  Setting up replication at
the root level does not provide a level of replication redundancy.

Decide Whether or Not Replication is Appropriate

Although DFS replication can help you distribute the client workload between multiple file servers, and provides you with a level
fault tolerance using DFS replication is not always desirable.  For example, imagine an environment in which users are constantly
making changes to data.  In such an environment, every update to a file would change the files version number, which would
trigger DFS replication.  If an excessive number of updates are being made then it could trigger a replication storm.

Replication storms are avoidable, because Windows Server 2008 allows you to limit the amount of bandwidth that is consumed
by the replication process.  The problem with limited bandwidth though, is that if DFS replication has insufficient bandwidth than
replicas may not be immediately synchronized, which can lead to version conflicts.

Typically the best candidates for DFS replication or environments in which the users read a lot of data from the file servers, but
do not make a lot of changes.  In these types of environments, the replication work load is minimal because replication only needs
to occur when updates occur.

If your users do constantly update files then you might consider setting a replication schedule that performs the majority of the
replication operations during off-peak hours.  Once again though, this can lead to version conflicts if two separate instances of a
file are each updated before replication can take place.  The point is though, that before you decide on a replication strategy you
really need to give some serious thought as to whether or not the strategy that you have chosen makes sense for your individual
company's needs.

Conclusion
In this article, I have talked about some things that you can do to ensure that DFS replication occurs smoothly, and without being
disruptive to your network.  Keep in mind though, that these are just best practices and that there are other issues that could
potentially be disruptive to the DFS replication process.
 Raising Windows Server 2008 Active Directory Domain and Forest
Functional Levels
When the first Windows Server 2008–based Domain Controller is deployed in a domain or forest, the domain or forest
operates by default at the lowest functional level that is possible in that environment, meaning Windows 2000 Native Mode. This
allows you to take advantage of the default Active Directory features while running versions of Windows earlier than Windows
Server 2008. When you raise the functional level of a domain or forest, a set of advanced features becomes available.

Make sure you read my "Understanding Windows Server 2008 Active Directory Domain and Forest Functional Levels" article for
more info about domain and forest function levels.

Note: In the Windows Server 2008 version of DCPROMO, when you install a new domain in a new forest, you are prompted for
the function level of your choice. Therefore, it may very well be that a brand new installation of Active Directory will not hold the
"default" domain or forest function levels.
Raising Domain Function Levels

To activate new domain features that available in Windows Server 2008, all domain controllers in the
domain must be running Windows Server 2008. After this requirement is met, the administrator can raise
the domain functional level to Windows Server 2008.

Important

Raising the domain functional levels to Windows Server 2008 is a nonreversible task and
prohibits the addition of Windows 2000–based or Windows Server 2003–based Domain
Controllers to the environment. Any existing Windows 2000–based or Windows Server 2003–
based Domain Controllers in the environment will no longer function, and in fact, the upgrading
wizard will not allow you to continue with the operation. Before raising functional levels to take
advantage of advanced Windows Server 2008 features, ensure that you will never need to install
domain controllers running Windows 2000-based or Windows Server 2003–based Domain
Controllers in your environment.

Membership in Domain Admins, Enterprise Admins, or equivalent, is the minimum required to complete this procedure.

In order to raise the domain functional level:

1. Log on the PDC Emulator of the domain with domain administrator credentials.

Note: The PDC Emulator is usually the first DC in the domain.

2. Open Active Directory Users and Computers by clicking Start > All Programs > Administrative Tools, and then click
Active Directory Users and Computers (you can also perform this action from the Active Directory Domains and
Trusts snap-in).

3. In the console tree, right-click the domain node and then click Raise Domain Functional Level.

4. Under Select an available domain functional level, do one of the following:

Click Windows Server 2003, and then click Raise to raise the domain functional level to Windows Server 2003.
 or

Click Windows Server 2008, and then click Raise to raise the domain functional level to Windows Server 2008.

5. Read the warning message, and if you wish to perform the action, click Ok.
 6. You will receive an acknowledgement message telling you that the operation was completed successfully. Click Ok.

7. You can check the function level by performing step 3 again and viewing the current function level.

Note: The current domain functional level appears under Current domain functional level in the Raise Domain Functional Level
dialog box. The level increase is performed on the PDC Emulator FSMO and requires the domain administrator.

Raising Forest Function Levels

To activate new forest features that available in Windows Server 2008, all domain function levels in the forest must be running in
Windows Server 2008 mode. After this requirement is met, the administrator can raise the forest functional level to Windows
Server 2008.

Note that domains that are set to the domain functional level of Windows Server 2003 will automatically be
raised to Windows Server 2008 at the same time that the forest functional level is raised to Windows Server
2008.
 Important

Raising the forest functional levels to Windows Server 2008 is a nonreversible task and prohibits
the addition of Windows 2000–based or Windows Server 2003–based Domain Controllers to any
of the domains in the environment. Any existing Windows 2000–based or Windows Server
2003–based Domain Controllers in the environment will no longer function, and in fact, the
upgrading wizard will not allow you to continue with the operation. Before raising functional
levels to take advantage of advanced Windows Server 2008 features, ensure that you will never
need to install domain controllers running Windows 2000-based or Windows Server 2003–based
Domain Controllers in your environment.

Membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure.

In order to raise the forest functional level:

1. Log on to the PDC Emulator of the forest root domain with a user account that is a member of the Enterprise
Administrators group.

2. Open Active Directory Domains and Trusts by clicking Start > All Programs > Administrative Tools, and then click
Active Directory Domains and Trusts.
3. In the console tree, right-click Active Directory Domains and Trusts, and then click Raise Forest Functional Level.

4. Under Select an available forest functional level, do one of the following:

Click Windows Server 2003, and then click Raise to raise the forest functional level to Windows Server 2003.

or

Click Windows Server 2008, and then click Raise to raise the forest functional level to Windows Server 2008.
5. Read the warning message, and if you wish to perform the action, click Ok.
 6. You will receive an acknowledgement message telling you that the operation was completed successfully. Click Ok.

7. You can check the function level by performing step 3 again and viewing the current function level.

Note: To raise the forest functional level to Windows Server 2008, you must upgrade (or demote) all existing Windows 2000 or
Windows Server 2003 Domain Controllers in your forest.

If you cannot raise the forest functional level, you can click Save As in the Raise Forest Functional Level dialog box to save a log
file that specifies which domain controllers in the forest still must be upgraded from older operating systems.