Archive for July, 2007

Directory Experts Conference goes Europe

After a couple years NetPro – the organizer of the Directory Experts Conference – has decided to bring the Directory Experts Conference back to Europe. It will be September 24th to 26th in Brussels, Belgium.

Click on the banner for more info:

dec2007_eu.jpg

See also the press-announcement.

I had a look at their agenda and it looks awesome!

Steve

Virtual Server or Virtual PC?

The Windows Virtualization Team blog has a very good post on the subject: Virtual Server or Virtual PC?.

It’s really worth reading it. Indeed, though both are compatible, there are some points requiring attention.

Steve

Windows Server 2008 Component Posters – Download Available

These two posters, originally published in the July 2007 issue of TechNet Magazine, provide a strong visual tool to aide in the understanding of various features and components of Windows Server 2008.

One poster focuses exclusively on powerful new Active Directory technologies, while the other provides a technical look at a variety of new features available in Windows Server 2008 (such as Server Core, Network Access Protection, and more).

Get both posters here.

Thanks to Keith Combs for posting this.

Steve

Launch Date Announced for Windows Server 2008, Visual Studio 2008 and SQL Server 2008

As per today’s press release, Microsoft announced that “Windows Server®2008, Visual Studio® 2008 and Microsoft SQL Server™ 2008 will launch together at an event in Los Angeles on Feb. 27, 2008, kicking off hundreds of launch events around the world”.

Steve

Windows Server 2008 – Read-Only Domain Controller – Administration and misc.

OK,  so now, we have our first Read-Only Domain Controller (RODC) installed: SRO-LH-03.

Let us see what we can do with it ;) .

First, some information that I rate important:

  • To implement RODC in your environment you do not need all DCs on Longhorn. You need to have your domain and forest at the Windows Server 2003 mode, and the DC running the PDC-Emulator needs to run on a full version of Longhorn.
  • As far as currently known there’s no support for multiple RODCs in a single location (they are unable to replicate between each other, each of them would replicate with the hub office).

Then, let’s connect to SRO-LH-03 (our RODC) and have a look at the ADUC (Active Directory Users and Computers) MMC snap-in. The Active Directory database is read-only. Well, first surprise, even when logged on locally, the snap-in points to SRO-LH-01, which is a writeable domcin controller:

ro-dc_15.png

As I really want to open the AD from SRO-LH-03, I forced the snap-in to connect to SRO-LH-03. Very nice, the tool is showing that the server is a RODC (have a look in the DC Type column):

ro-dc_16.png

I selected SRO-LH-03 and got the following message popping up, which is fine:

ro-dc_17.png

Now the ADUC snap-in shows up and points to SRO-LH-03. If we expand the Domain Controllers container, we can see the three current domain controllers. Again SRO-LH-03 is marked as Read-Only:

ro-dc00.png

To prove that the AD database on SRO-LH-03 is well read-only, I am not event able to create a new user account as the option is not even present. This is the situation when pointing to SRO-LH-03 (RODC):

 ro-dc01.png

and when pointing to SRO-LH-01 (writeable DC):

ro-dc02.png

OK, so that was to verify the read-only state of the Active Directory database on SRO-LH-03. 

Now, if we look at the properties of the SRO-LH-03 computer object in AD, there is a completely new tab, Password Replication Policy, and an enhanced one, Managed By:

ro-dc04.png

First, the Managed By tab. This is where we can specify which (normally) non-administrative user or group can perform the actual on-site installation of the RODC (see my previous post for some information on the staged installation of the RODC):

ro-dc05.png

Let’s put my regular (= non-admin) account as manager of the SRO-LH-03 RODC:

ro-dc06.png

The tab Password Replication Policy is brand new. It enables the administrators to

  • specify the users/groups/computers of which the password may or may not be replicated to the RODC (remember that by default, no password is being cached, the only exception being the computer account of the RODC itself and a special krbtgt account):

ro-dc07.png

  • display the list of accounts whose passwords are stored on the in-question RODC (there is even an Export function):

ro-dc08.png

  • display the list of accounts that have been authenticated to this RODC (there is also the export functionality):

ro-dc09.png

  • prepopulate passwords of certain accounts to the in-question RODC; the idea being that you would pre-cache the password on the RODC of the site where the user belong for instance. Let’s say that I want to pre-populate the password of my regular account to the SRO-LH-03 RODC (of course, my account must be included in the allowed list of passwords that can cached on this RODC):

ro-dc10.png

ro-dc11.png

ro-dc12.png

Now you could ask yourself “What’s behind all these functionalities?”. Well, it is all about SECURITY. Remember that I said that RODC are perfectly suitable for branch deployment. The idea is that the RODC contains a full copy of the Active Directory database but in read only mode. Any write operation will be redirected to a writeable domain controller. So if the security of the server in the branch is compromised, it will not jeopardize the whole corporate AD.

Now even if the RODC would be hacked somehow, and if defined so (remember that by default, there is no password caching at all – you have to explicitly turn it on and specify for which accounts), it would only contain the password of the accounts of this site and not the passwords of all the accounts and certainly not the password of the administrative accounts, as these are excluded from password-caching. Should the RODC be tampered with, then you could easily retrieve the list of users for which the password was cached on this particular system (see above) and simply reset the password.

Having dealt with a largely-distributed domain controller base in the past, I am really excited by this RODC feature as it could have solved a lot of my nightmares.

Steve

Windows Server 2008 – Read-Only Domain Controller – Installation

In this post, we will see how to install a replica read-only domain controller to an existing Active Directory domain.

You will see that from an installation perpective, the process does not differ much from a standard domain controller installation.

The name of the domain is still SRO-LH.local.

I have installed a new server, SRO-LH-03 and run the command dcpromo.exe.

The first thing the process does is to check whether the ADDS binaries are installed on the server:

ro-dc.png

As this is is a brand new system, neither the ADDS role not the binaries are installed. So, this is taken care of:

ro-dc_1.png

Welcome screen of the ADDS Installation Wizard:

ro-dc_2.png

Yes, we want to add a new domain controller to an existing domain:

ro-dc_3.png

We have to specify the name of the domain in which we want to install the additional domain controller:

ro-dc_4.png

At this moment in time, I am logged on as a local administrator of the server and have therefore no right to perform the ADDS installation. For this reason, I specify some alternate credentials, i.e. the domain’s administrator credentials, by clicking on the Set… button:

ro-dc_5.png 

Confirmation:

ro-dc_6.png

Then, we need to confirm the domain for this additional domain controller:

ro-dc_7.png

We also need to define in which Active Directory site the new domain controller will be put:

ro-dc_8.png

On this page, we explicitly specify that we want to make the server a RODC:

ro-dc_9.png

As per Microsoft Technet article, you can perform an installation of an RODC in which the installation is completed in two stages by different individuals.

  1. The first stage of the installation, which requires domain administrative credentials, creates an account for the RODC in AD DS.
  2. The second stage of the installation attaches the actual server that will be the RODC in a remote location, such as a branch office, to the account that was previously created for it. You can delegate the ability to attach the server to a nonadministrative group or user, which is a feature I find pretty neat from the deployment perspective.

During this first stage, the wizard records all data about the RODC that will be stored in the distributed Active Directory database, such as its domain controller account name and the site in which it will be placed. This stage must be performed by a member of the Domain Admins group. The administrator who creates the RODC account can also specify at that time which users or groups can complete the next stage of the installation.

The next stage of the installation can be performed in the branch office by any user or group who was delegated the right to complete the installation when the account was created. This stage does not require any membership in built-in groups, such as the Domain Admins group. If the user who creates the RODC account does not specify any delegate to complete the installation (and administer the RODC), only a member of the Domain Admins or Enterprise Admins groups can complete the installation.

During the second stage, the wizard installs AD DS on the server that will become the RODC and attaches the server to the domain account that was previously created for it. This stage typically occurs in the branch office where the RODC is deployed. During this stage, all AD DS data that resides locally, such as the database, log files, and so on, is created on the RODC itself.

At this point of the installation process, we can specify any group or user who will later be able to install and manage the RODC. As we are not in such deployment scenario, we leave the field empty:

ro-dc_10.png

The next step is about specifying the folders for the AD database, the log files and the SYStem VOLume:

ro-dc_11.png 

Then, we specify the Directory Services Restore Mode (DSRM) password for the Domain Controller:

ro-dc_12.png

The wizard offers to review all the options selected and even provides a way to export the settings to an answer file for future re-use:

ro-dc_13.png

Finally, the actual installation and replication process starts. You also have the possibility to decide whether you want the server to reboot automatically at the end:

ro-dc_14.png

This concludes the installation of the RODC in itself.

Steve

iPhone Review by Engadget

As you might know, I am also an Apple-freak.

I have been reading a lot of reviews about Apple’s iPhone. But the one I liked the most for its completeness is to be found on Engadget.

Steve

Windows Server 2008 – Read-Only Domain Controller

Michael has a very nice post on the RODC role available in Windows Server 2008. The post provides usefull information on the features of RODC.

Steve

Windows Server 2008 Core – Active Directory Domain Services

One of the things we can do with our newly installed machine is to promote it to a domain controller for the domain SRO-LH.local.

As the machine is running Server Core, we’ll have to do it the hard way… via command-line. Indeed the interactive version of dcpromo.exe is not available in the Server Core edition of Windows Server 2008.

In order to do this, we need to prepare an answer file that will contain all information required for the dcpromo process.

To get information on the syntax of the answer file, I used a Windows Server 2003 installation CD (as the information is not available on the Windows Server 2008 Beta 3 installation media).

In the folder D:\support\tools, locate and expand the file deploy.cab:

rodc_6.png

Within the deploy.cab file, open the ref.chm file and browse to the Unattend.txt section of the help file. That’s where you can find all the information needed. Look especially at the [DCInstall] part:

rodc_7.png

Thanks to this, I was able to produce my own unattend.txt file (the password in the last entry has been removed for obvious reasons):

rodc_8.png

Then, back on the server, we just need to launch the dcpromo command by specifying the location of the unattend.txt file (the R: drive is mapped to SRO-LH-01 where I prepared the answer file):

rodc.png

Then the installation proceeds:

rodc_3.png

rodc_4.png

At the end of the process, the server reboots automatically (except if specified not to do so in the answer file).

Steve

Windows Server 2008 Core – Installation and Initial Configuration

In this post, I will focus on the Core version of Windows Server 2008.

More particularly, we will see:

  • the installation of the OS
  • the activation of the OS
  • the renaming of the server
  • how to set a password on the local Administrator account
  • how to join the server to a domain

I recommend you reading the Server Core Installation Option of Windows Server “Longhorn” Step-By-Step Guide for detailed information on how to setup/configure Windows Server Core. You can find the document here.

OK, so now let’s start. First of all the installation. As usual, the process is quite straightforward. Boot from the DVD, select the keyboard type

server-core.png

Click Install now:

server-core_1.png

Select the Server Core edition of Windows Server 2008:

server-core_2.png 

Accept the license agreement:

server-core_3.png

As we are doing a fresh install, let’s go for the custom type:

server-core_4.png

Then we select the partition on which we want to install Server Core:

server-core_5.png

The installation is ongoing:

server-core_6.png

When the installation is over, we are welcomed by the usual screen:

server-core_7.png

Important to know: the local administrator account has no password set after the Server Core installation.

So for the first logon, we just need to specify the Administrator account without password:

server-core_8.png

After the logon, we are greeted by the command prompt:

server-core_9.png

Now that the OS is installed, we need to activate the license. To do so, first make sure that the server is connected to Internet, as the activation process requires connectivity to Microsoft Activation servers.

Then, we can invoke the slmgr.vbs script (more info here):

server-core_10.png

We even receive a confirmation pop-up:

server-core_11.png

During the installation of Server Core, the setup assigns some random computer name to the server. In my case, the name of the server was LH-BE9610E35DZJ, not really funny ;) . So I decided to change this to something more inline with my naming convention.

I used the command netdom renamecomputer in order to rename my server to SRO-LH-02 (SRO-LH-01 being my DC, DNS and DHCP server).

server-core_12.png

Now, let’s (try to) secure our server a bit by setting a password on the local administrator account. To do this, we can use the command net user administrator *:

server-core_13.png

The following step is to configure the network settings. When installed, Server Core is configured to use DHCP. The current DHCP-assigned IP address of the server is 192.168.200.102 (the DHCP server leases address from 192.168.200.100 to 200).

Let’s change this so that we have:

  • static IP address: 192.168.200.2
  • subnet mask: 255.255.255.0
  • default gateway: none
  • DNS server: 102.168.200.1 (we aboslutely need the DNS resolution as we will later on join the server to our domain)

First, we need to determine the index of the network card. To do this, we use the command netsh interface ipv4 show interfaces. In our example, we can see that the Local Area Connection is on Index 2.

Then we use the appropriate netsh command to set the static IP address, subnet mask and default gateway:

server-core_15.png

A little check with ipconfig:

server-core_16.png

Setting the DNS server on the interface requires the use of another netsh command:

server-core_17.png

Finally, let us join the server to our SRO-LH.local Active Directory. The command netdom join allows us to do so:

server-core_18.png

After the reboot, we are finished so far.

Steve


Blog Stats

  • 39,758 hits

 

July 2007
M T W T F S S
« Jun   Sep »
 1
2345678
9101112131415
16171819202122
23242526272829
3031