Today's topic is DHCP! There are three ways to get a DHCP assigned address to a client:
1) Place a DHCP server on every subnet
2) Enable BOOTP in the router(s)
3) Place a DHCP relay agent on every subnet. The relay agent picks up a client's multicast request for an IP address and then unicasts that to the DHCP server...which unicasts a response to the relay agent and then the relay agent broadcasts that IP address to the client.

If you have a DHCP server and a relay agent on the same subnet, how do you know that the server will respond first? DHCP relay agent settings can be found in RRAS, and there's a setting called "Boot threshold" which lets you tell the agent to wait several seconds to see if a DHCP server will respond.

A "split scope" is a way to create fault-tolerance for DHCP. On subnets "A" and "B", you use both a DHCP server and a DHCP relay agent. Each DHCP server can assign up to 80% of its IP addresses and the server in the other subnet holds the other 20% (the percentage is flexible). This way, if one DHCP server dies, the associated relay agent can forward requests to the other server and receive a valid address for the original subnet.

To paraphrase, a DHCPDiscover broadcast says "Hi, my MAC address is blah-blah-blah and I used to have IP address blah-blah-blah. Are there any DHCP servers available to re-assign this address to me?". It receives an IP and subnet. Then it says "Thanks, I'm also looking for a default gateway and a DNS server - do you have that info?". Here's a really good article on this topic.

Two other methods of fault-tolerance for DHCP are to cluster your DHCP servers or to use the "alternate configuration" in Windows XP.

Random note:
In a big organization, it makes sense to keep the "root domain" of your forest empty (w/ only the Administrator account active - and assigned a good password) to protect the Enterprise Admins and Schema Admins group from misuse.


Delegating DNS

Why would you delegate a DNS zone? If a DNS server is being overwhelmed by traffic, it would make sense to delegate a portion of its namespace to another server; if a DNS server is separated from important "clients" (e.g. Exchange servers, or many workstations) over a slow WAN link (as a way of moving the most important (popular) DNS server closer to its base); or if you just need to shift some of the administrative work to somebody else. Hopefully I'll be able to grasp the the concepts being tested on in 70-297, but in real life, I think I still feel very fuzzy on why/how the whole DNS delegation thing exists/works.

When I created a new zone on my test DNS server, I found that unqualified hostnames failed in nslookup. Using group policy (Computer\Admin\Network\DNS) I added an entry to the DNS suffix search order for the zone that had previously failed the nslookup. After fixing a subnet mask on my test workstation (oops) and rebooting (to apply the machine-level group policy), it worked!


More research 2

Reviewed WINS concepts. On a single subnet, you don't need a WINS server. If you have multiple subnets (broadcast domains) and you have a program that requires WINS lookups, then you need a WINS server.

DNS...I'm comfortable with primary zones, ADI, forwarding, and recursion. Secondary zones are read-only copies of a primary server. In Server 2003 they don't seem to have any value. They can not be integrated into Active Directory. If you have a DNS server that needs to know about DNS servers in other forests, you can use a stub zone to avoid zone transfer traffic. It seems that secondary zones used to be handy for fault tolerance and load balancing, however that's a non-issue with ADI zones. According to informit.com, a BIND server can receive a secondary copy of an ADI zone.

It just occurred to me this evening that the default "ClientApps" share on Server 2003 is probably intended for applications published to clients via group policy in their Add/Remove Programs applet.


More research

I tried 70-297 on the 15th & flopped again! Today, I'm doing some study on related topics.

Server 2003 (Standard) minimum system requirements are a 133MHz x86 CPU, 128MB of RAM, and 2.0 GB of available HD space. Server 2003 supports three processor architectures: x86 32-bit, x86 64-bit, and Itanium. This means that Server 2003 does NOT run on RISC processors.

To bone up on RADIUS, I followed instructions to install IAS and configure RRAS to use it. It worked! I ran IAS and RRAS on the same server.

Operations masters - it seems I'm weak on these. They used to be called FSMO (fiz-mo) for Flexible Single Master Operation. The concept of Active Directory is a "multi-master" one overall, but there are some roles that only a single DC handles. Two of these are at the forest level: schema master and domain naming master. Three others are at the per-domain level: RID master (sort of the "master domain controller" - it allocates domain RIDs to the DCs for use in SIDs); Infrastructure Master (only important in multidomain environments - in which case it shouldn't be on a GC server); and the PDC Emulator, which handles password changes and account lock-outs. It's also the authoritative time source in a domain.

I think if I bandwidth isn't an issue, every DC in a small domain should be a GC.

For a short-term disaster recovery simulation, you only need a PDCe available. However, if you restore a DC from backup, it will invalidate its RID pool and need access to a RID master to replenish it for new object creation. See here and here.

When you install a Server 2003 box in a Windows 2000 forest, you have to update the 2000 AD schema for the new features in 2003's version of Active Directory. You do this by running adprep /forestprep on your forest's schema master & adprep /domainprep on each domain's infrastructure master.

In other news, SP1 for Vista was released on the 18th.

Unable to disjoin domain

Several weeks ago a workstation was experiencing really slow logon/off times. When I tried to disjoin it from the domain I was told "The following error occurred attempting to unjoin the domain: the specified module could not be found". Now what? It turned out that w32time.dll was missing from the c:\windows\system32 directory. Because it was missing, the Net Logon service couldn't run. The Net Logon service is essential for interacting with a domain.


Google Apps

I tried out free email hosting via Google Apps recently. The steps to do so are:

Create a Google Apps account.
Follow instructions to change MX records for your domain (via CPanel).
Follow instructions to change custom webmail URL (via support ticket with web host - CPanel doesn't support this).
Log into each webmail account and enable POP or IMAP access.
Follow instructions to configure your mail client (e.g. Outlook Express)
- You login to pop.gmail.com:995 as username@yourdomain.com

I think this will provide good spam filtering for free - and might therefore be useful for nonprofits and small businesses who don't want to purchase Outlook 2003 for their users. Outlook 2003 has an excellent built-in spam filter, updated monthly by Microsoft via Microsoft Update.


Defragment Exchange

Here's a short batch file to defragment Exchange 2000/2003 information stores:

@echo off
echo Verify that you've backed up and dismounted the Exchange Store!
echo Press Ctrl + C to cancel...
cd "C:\Program Files\Exchsrvr\BIN"
eseutil /d ..\mdbdata\priv1.edb

Local user profiles

Last week, a client requested that their stand-alone workstations be joined to their domain for better password management. To minimize disruption to the users, I used ForensiT's User Profile Wizard to join systems to the domain and re-assign their local profile to the new domain SID. It works beautifully! The only thing it doesn't do is transfer the contents of Protected Storage. I used NirSoft's Protected Storage PassView to copy saved passwords into an Excel spreadsheet for printing.


Local Admin

To add a domain group to the local admins group on all your workstations, fire up a group policy and edit the computer startup scripts. Here are two scripts I've tested:

1) Batch file:
NET LOCALGROUP Administrators /ADD "YourDomain\YourDomainGroup"

2) VBScript:
On Error Resume Next
MyDomainName = "InsertYourDomainName"
MyDomainGroup = "InsertYourDomainGroup"

Set x = WScript.CreateObject("WScript.Shell")

Set Local_Admins=getobject("WinNT://" & ComputerName & "/Administrators,group")
Local_Admins.add ("WinNT://" & MyDomainName & "/" & MyDomainGroup & ",group")

Computer startup scripts run with practically unlimited local permission; logon scripts rely on the current user's permission.



This evening I tried out the Active Directory Migration Tool 3.0, migrating a WinXP workstation from the “silver” domain (the source) to the “gold” domain (the target).

After installation, you open the ADMT as an MMC snap-in on the target domain controller. Your target domain must be in domain native mode. User and computer accounts get migrated in separate steps; then you remotely run an “agent” on the workstations that you’re migrating to join them to the new domain and reset all the necessary file/registry permissions.

In order for this agent to run, your user account in the target domain must have local admin rights on the workstations. Automating the process may be the topic of another post. I did it manually by adding \\gold\Domain Admins to \\silver\Trusted-Admins and then adding the new "Trusted Admins" (a domain local) group to the local admins group on the workstation.

I couldn’t add \\gold\Domain Admins to \\silver\Domain Admins because both groups are global. Remember that global groups are great travelers, but poor hosts. Also found that I couldn’t place an individual user account from one domain in another domain’s group.

If you don’t have local admin rights to the workstations, the ADMT agent will report “access is denied” to the ADMIN$ share. The workstations also need need to have the same primary DNS server as the target domain controller(s).

By the way, during the course of this exercise I raised my forest functional level and learned that the Enterprise Admins group only exists on domain controllers in the “root domain” of a forest. You have to be in that group to make any schema changes (e.g. modifying the forest).

By default, the ADMT does not migrate user passwords; instead is sets the migrated user accounts to “change password at next login”.

After the ADMT agent runs, it reboots the workstation & viola! You’re finished! This is so cool.


Domain tinkering

Powered on SERVER2 and ran dcpromo, but couldn't demote it to a stand-alone server because Active Directory "knew" that there was still another DC out there. So I tried demoting it to a member server, but Active Directory insisted that it must be able to contact another DC in that case...so I powered on SERVER1. After demoting SERVER2 to a member server and rebooting, I ran dcpromo again to install Active Directory as a new domain in the existing forest. This didn't work at first because DNS lookups (for the new domain) on SERVER1 timed out. To fix, I created a primary zone on SERVER1 for the new domain and that allowed me to proceed with installing Active Directory on SERVER2 w/ SERVER1 as its DNS server.

Powered on a virtual workstation (XP1) and joined the second domain. After rebooting, XP1 saw every domain in the forest - meaning DOMAIN1, DOMAIN2, and XP1. A quick Google search determined that this list is not editable, but that you can set a default domain for a PC and then hide the domain list.

Windows workstations cache domain credentials for up to 10 offline logins. To change/disable this, edit a group policy: Computer > Windows > Security > Local > Interactive logon: Number...

After a slow initial login on XP1, I checked the event log and found complaints that the domain controller was inaccessible. Creating reverse DNS entries appeared to resolve this (though maybe it just needed more time).

Lastly, I assigned a batch file login script to XP1 via group policy, but noted that my PAUSE command was ignored.