Some DNS Tips

Several times in just the past week I've had to deal with DNS entries that have made things a touch more painful than they should have been so I thought it might be time for me to jot down a few notes on how DNS should be configured to save IS people's sanity!

First up the DNS servers themselves. You should always have a primary and secondary which generally, speaking are two different DNS servers at your ISP's location. If two are not available you should consider switching ISP's. Personally, I use three. Two from my ISP and one from OpenDNS. This way, should the ISP change for any reason and/or should access be denied to the ISP's DNS servers I've got a third, totally separate service available to me.

Next up, A records. These should always point to the IP address of the server in question and they should always use the hostname of the server. Sure, this can lead to some unfriendly names but it's really handy to know the proper hostname of the server. If you want to use something 'pretty' then use CNames. When you create the A record make sure the PTR record is also created in the reverse look up zone. This way, when you are trying to work out what physical server a CName is all you have to do is a reverse lookup against the IP address.

MX Records should also have two internal/DMZ based mail servers which they can deliver to and a third at the ISP which can retry delivery to your internal servers at a later date.

These are simple tips and they (or variants of them) can be found as best practice advice for standard DNS configurations.

Legacy Systems and a very handy SQL comparrison Tool

On Friday, I had the "pleasure" of having to get a legacy system up and running.
This system was originally introduced to allow users in the business to manage group membership for projects they had ownership of. The idea was that it would cut down user calls to the service desk by about 10% and allow the project managers themselves to get a speedier turn around for new starters.
Sounds fine in theory and in the world of NT4 it wasn't a problem. Move on to the world of Active Directory and things are a little different. The legacy system (Bindview v4.6) has been superceded about 5 times over but we can't just install the latest version. Trust me on this, the latest version is fine but there are many design decisions and compromises as well as several rejections for upgrading the system from a few years back that have all combined to lead to the current problem.

The actual problem was an interesting one. The system was complaining whenever anyone tried to edit a group. A restore of the back end SQL database fixed the problem until the next domain sync occurred when the database would corrupt itself again.

Obviously, the sync was pulling something from the domain that it didn't like.
For the first attempt at a fix I fired up SQL Trace which records every single SQL statement that goes to a selected database. The neat thing about Trace is that it's possible to point the trace results to a SQL database itself and then filter it to get rid of stuff you know isn't going to help - such as SQL agent tasks and so on.
Trace left me with a multi-variable SQL script spanning over 4,000 lines and quite difficult to read or even test so I decided that the next best thing was to restore the working database to new a database name and then find a tool to compare every object on the bindview user table to see what was different between the restore and the one that synced with the domain and promptly broke.

AdeptSQL was the third tool I tried and whilst it has a very simplistic point and click interface it's incredibly powerful for comparing two SQL databases. Once the comparison is done you get two side-by-side windows which represent the two databases. Changes are highlighted by colour - Red for deletions, Blue for new and black for no changes.
This left me with a 2,000 list of changes, deletions and amendments in the database.
AdeptSQL also lets you filter things out and by using these features I eventually tracked the problem down to the description field of two user accounts.
These accounts had spurious characters in them which Bindview being rather old and totally ASCII prompt fell over on. Removing these and waiting for a resync solved the problem.

Whilst AdeptSQL helped me solve that particular problem there is still the problem of this legacy system updating Active Directory whilst not being active directory aware which leads to some other fun and games with the display name versus the SAMAccount name but more on that in a later article.

Issues upgrading Domain Schema to 2003

So I'm probably a little behind in upgrading my home networks domain schema to support Windows 2003 but better late than never!
The process itself was smooth enough once I'd corrected some problems on the machine but the upgrade logs were not the most helpful troubleshooting aid I've come across.
One particular error had me stumped for a few days:

"Error code: 0x57 Error message: The parameter is incorrect.."

No indication of which parameter it was but as it occurred when checking security descriptors and many blog articles refer to missing security ACL's on GPO's I had a look at those and sure enough, Enterprise admins was missing some rights so I fixed those up and....... the same problem. At this point I'd admit to a lot of head scratching. The event logs didn't shed much light until I realised that the security event logs were not accessible. Sure enough, somehow the ACL's on the security event logs had lost all their rights. Resetting these and then rebooting allowed the process to complete perfectly.

FSMO Confusion in multiple domains

When I teach classes on Active Directory I will cover various domain models including the empty root domain model, this model has several security,delegation and political based benefits that I will cover in a future article suffice to say it uses two domains and the child domain is the production domain and the empty root just contains certain FSMO roles and forest-wide groups.

When I teach this model I will always ask the class to tell me how many FSMO roles there are and if the class is awake I will generally get the correct answer of five. I will then point to the empty root domain model and ask the class where the 8 FSMO roles should be placed, invariably I will get a look of confusion because there are only five.....

What a lot people forget is the minimum number of FSMO roles you can have in a domain is three and the maximum is five. Lets look at that empty root domain again - The empty root is just a windows domain that just happens to be the first in the domain to be created and as such will hold five FSMO roles. The roles are Schema Master, Domain Naming Master, PDC Emulator, RID Master and Infrastructure Master. The first two are forest wide so will only ever exist in one domain of the tree whereas the other three are domain wide and will exist in each and every domain created and this seems to be where the confusion comes in.
Your very first domain (the empty root in this example) will have FIVE FSMO roles, the child domain will hold THREE. Five+three equals eight which explains how you can have eight FSMO roles across two domains.

Creating a Default User Profile

One of the things that annoys me about windows is the Default User profile. This is the profile that a new user who logs onto a machine (or server will get).
The way it works on NT, 2000, XP and 2003 is pretty much the same.
Under the documents and settings folder on 2000, XP and 2003 are a series of folders for each person that logs on to the machine.

Hidden in here is also a profile called 'Default User' and whatever is in here gets copied to the logon name of any NEW person that logs on.

Microsoft provide a somewhat tortuous way of customising this profile by creating an additional local user which is fine unless you have already spent time customising the profile you have logged on as.

Facing this situation yesterday I realised that the easiest fix is to just log off the machine which unloads the user profile and then you can copy the existing profile over the top of default user and so have a working default user profile in seconds..... Permissions might need to be adjusted as need be but it was a quick and painless way to take an existing and cofigured profile and make it a default.

The power of the human mind........ to fail.

The human brain is an amazing computer. It can store almost infinite quantities of data, it has near instant recollection to enable you to recognise people, places and perform the essential day to day actitives of breathing.

So why does it let us down in the middle of a crisis when you need to have that vital bit of information or when you remember seeing a tech note on the very problem you are fixing but can't recall the technical notes reference number.

The answer is simply to do with the way the human mind has evolved, Our technological prowess has evolved quicker than the brains ability to deal with this new landscape. When we, as a specics, were huddled in caves a crisis required the 'fight or flight' response and today when you have a crisis in the office that same reaction kicks in and all of a sudden you have trouble recalling technical details yet when the crisis passes you will be doing something else when the brain, still working on the problem in the background, will kick in.
The military actually have special training programmes to allow test pilots and others under extreme pressure to continue to think rationally. It is a very special SKILL.

so, why do we all have problems saying 'I don't know' and recording those oh so useful technical notes when we have the chance?

In the IS industry there seems to be a huge amount of pride in relying on ones memory to get people through a bad day. Checklists and procedures only seem to come into force for the day to day working practices - I have yet to see a company have an emergency procedures checklist.

3,000 test users

Do you ever have need of a few hundred to a few thousand random names to populate your Active Directory in order to test something?

This is the requirement I had a few weeks back so I dug out about 3,000 random names from the 1901 census and threw them into a csv file that can be read by the addusers tool.

My names.csv file can be downloaded by clicking on the blog article link or by clicking here.

To get the users into active directory copy both adduseres.exe and names.csv to the root of your C: drive and then type in:

addusers /c c:\names.csv

addusers /? will give you a list of other options where you can set parameters for passwords and the like.

Display FSMO role holders

Imagine the scene - You are consultant and have been asked to fix an Active Directory issue - One of the first things you need to find out is where all the FSMO roles live. You could go digging around in Active Directory Computers and Users, Domains and Trusts and Schema Master (remembering to register SCHMMGMT.DLL) or you could just run the script below.

Copy the script in the box below, save it as 'fmso-role-holders.vbs' then run it via cscript fmso-role-holders.vbs

Set objRootDSE = GetObject("LDAP://rootDSE")

Set objSchema = GetObject ("LDAP://" & objRootDSE.Get("schemaNamingContext"))
strSchemaMaster = objSchema.Get("fSMORoleOwner")
Set objNtds = GetObject("LDAP://" & strSchemaMaster)
Set objComputer = GetObject(objNtds.Parent)
wscript.Echo "Forest-wide Schema Master FSMO: " & objComputer.Name

Set objNtds = Nothing
Set objComputer = Nothing

Set objPartitions = GetObject("LDAP://CN=Partitions," & objRootDSE.Get("configurationNamingContext"))
strDomainNamingMaster = objPartitions.Get("fSMORoleOwner")
Set objNtds = GetObject("LDAP://" & strDomainNamingMaster)
Set objComputer = GetObject(objNtds.Parent)
wscript.Echo "Forest-wide Domain Naming Master FSMO: " & objComputer.Name

Set objDomain = GetObject ("LDAP://" & objRootDSE.Get("defaultNamingContext"))
strPdcEmulator = objDomain.Get("fSMORoleOwner")
Set objNtds = GetObject("LDAP://" & strPdcEmulator)
Set objComputer = GetObject(objNtds.Parent)
wscript.Echo "Domain's PDC Emulator FSMO: " & objComputer.Name

Set objRidManager = GetObject("LDAP://CN=RID Manager$,CN=System," & objRootDSE.Get("defaultNamingContext"))
strRidMaster = objRidManager.Get("fSMORoleOwner")
Set objNtds = GetObject("LDAP://" & strRidMaster)
Set objComputer = GetObject(objNtds.Parent)
wscript.Echo "Domain's RID Master FSMO: " & objComputer.Name

Set objInfrastructure = GetObject("LDAP://CN=Infrastructure," & objRootDSE.Get("defaultNamingContext"))
strInfrastructureMaster = objInfrastructure.Get("fSMORoleOwner")
Set objNtds = GetObject("LDAP://" & strInfrastructureMaster)
Set objComputer = GetObject(objNtds.Parent)
wscript.Echo "Domain's Infrastructure Master FSMO: " & objComputer.Name

Migration of DHCP database

On my home 'production' network I have a single Active Directory server that runs DNS and DHCP. Whilst not fault tolerant it does the job and for a network that can afford the downtime should the domain controller die its a workable solution.

Recently, this server has been running incredibly slowly. Its actually taking 8 minutes to boot.
As this server has been giving sterling service for a couple of years I decided it was probably time to replace the server with something a little faster and a lot cleaner.

Building the replacement domain controller was simple enough, An autobuild of Windows 2000 server then DCPROMO it to be a domain controller.
The FSMO roles transfered over no problems as did the DNS.

DHCP proved to be slightly more problematic.

All DHCP records are held in a database file under %systemroot%\system32\dhcp - Copying this database to the new server didn't work so it was time to hit Technet's knowledge base.

http://support.microsoft.com/?id=325473


The knowledge base pointed me in the direction of a tool called DHCPEXIM which despite the clunky interface is actually very easy to use. Just highlight the scope(s) you want migrate and click on Export.

On your new DHCP server run DHCPEXIM, select import and point it to the file you just exported. It will display a list of the scopes it knows about and bring them all into your DHCP server.

Note that your DHCP server can already have scopes configured but if you try to import a scope and that scope already exists on your server then the import will fail.

This was tested out on Windows 2000 server to Windows 2000 server but the docs say it should work on NT4 and Windows 2003 as well.

VMWare offer free P2V conversion tool

I have a windows 2000 domain controller that I want to clone and put into my test network so I can rehearse an upgrade from Exchange 2000 to Exchange 2007 and to test out the Active Directory upgrade from 2000 to 2003. At first I looked at a couple of DR type options. The standard System State backup via NTBackup will restore into VMWare but because it restores a chuck of hardware related information as well the VMWare machine reboots then blue screens - not good. I'm sure there is a way round this with sysprep or with backing up that data separately but my experiments lead to a constantly rebooting server. I also found out that DCPROMO /ADV only works for Windows 2003.

Another option is to join the VM to the live network and DCPromo it as another domain controller, Snapshot, DCPROMO it down then restore the snapshot. This would work but I've heard of problems with errant entries in DNS when this approach is used.

After some head scratching I found a free tool on VMWare's site that does Physical to Virtual conversion (P2V) and it's free for single machines to VMWare workstation or VMWare server. If you want to convert to ESX server or convert a bunch of machines then you need a licence.
I've installed the software onto my Domain controller and I'll have a go and running the conversion this week and report back on how good or bad the process is.

Common Question - How do I move the hibernation file?

Simple answer - You can't.

Longer answer - When the PC boots NTLDR knows where it's boot volume is. On that boot volume resides hiberfil.sys - The operating system will take a look at the file and if it's valid and active then the system will use restore the machine to it's hibernated state. If the hibernation file is not active then a normal boot process will occur.

Many people think that a registry hack will allow them to move the hibernation file to another volume but this is not possible because the registry is not loaded at the time NTLDR does the check for the location of the boot volume and the check for valid, active hiberfil.sys - the registry is not loaded and so the hibernation file must be located on the boot volume.

Working with TCP/IP Networks

In my previous blog article I gave a couple of troubleshooting tips on DHCP. I also mentioned that I would show a trick for working out TCP/IP subnets.

There are MANY subnet calculators out there and they are very useful for planning and designing a TCP/IP infrastructure but sometimes you may just want to know how to work out if two machines are on the same subnet.

Take the following IP Address and subnet mask:

172.17.1.15
255.255.0.0

From the above example it's nice and easy to see that the network the IP address lives on is 172.17.0.0 - The dividing line between network and host is obvious and clean.

Now try the same with the following:

172.17.14.12
255.255.252.0

Which network does the IP reside on?
The answer is 172.17.12.0

This can be worked out nice and simply by launching calc in scientific mode and performing an AND operation on the value where the subnet is NOT 255 and NOT 0.

Take these three examples:

172.17.30.99/20
172.17.31.221/20
172.17.32.1/20

What's the subnet mask?
255.255.SOMETHING.0

As 255 uses 8 bits for the subnet mask we can work out that it's 255.255 and the something has 4 bits left over. 11110000 equals 128+64+32+16 which is 240 so the subnet mask is:
255.255.240.0

Now perform the AND function on the 224 octet and you get:
30 AND 240 = 16
31 AND 240 = 16
32 AND 240 = 32

These show that the first two IP address are on the 172.17.16.0 and that the last one is on the 172.17.32.0.0 network. The last IP addres will need a gateway in order to talk back to the first two.

This tip is really meant for the sort of situations where you have problems with two machines talking to each other. It's a 'sanity check' that lets you see if both machines are on the same or different VLANs.

If you want something that can give you a whole lot more then you can download a really nice free subnet calculator from solar winds.