Microsoft Virtualization: part 1 (introduction)

Posted on By Mark Wilson

Sitting at Microsoft’s London offices waiting for this evening’s Microsoft Virtualization User Group (MVUG) event to start reminded me that I still haven’t written up my notes on the various technologies that make up Microsoft’s virtualisation portfolio. It’s been three months since I spent a couple of days in Reading learning about this, and tonight was a great recap – along with some news (some of which I can’t write about just yet – wait for PDC is all I can say! – and some of which I can).

A few weeks back, I highlighted in my post on virtualisation as an infrastructure architecture consideration that Microsoft’s virtualisation strategy is much broader than just server virtualisation, or virtual desktop infrastructure and introduced the following diagram, based on one which appears in many Microsoft slidedecks:

Microsoft view of virtualisation

At the heart of the strategy is System Center and, whereas VMware will highlight a number of technical weaknesses in the Microsoft products (some of which are of little consequence in reality), this is where Microsoft’s strength lies – especially with System Center Virtual Machine Manager (SCVMM) 2008 just about to be released (more on that soon) – as management is absolutely critical to successful implementation of a virtualisation strategy.

Over the next few days I’ll discuss the various components included in this diagram and highlight some of the key points about the various streams: server; desktop; application; and presentation virtualisation – as well as how they are all brought together in System Center.

Active Directory design considerations: part 8 (summary and further information)

Posted on By Mark Wilson

Over the last few days, I’ve written a series of posts about design considerations for Microsoft Active Directory (AD), based on the MCS Talks: Enterprise Infrastructure series of webcasts. Just to summarise, the posts so far have been:

  1. Introduction.
  2. Forest and domain design.
  3. Organisational Units.
  4. Group policy objects.
  5. Security groups.
  6. Domain controller placement and site design.
  7. Domain controller configuration and DNS.

Just to finish the series it’s worth noting that implementing Active Directory is an iterative process. As business and technical application requirements change, so might the optimum directory configuration, particularly after major infrastructure changes such as a network upgrade.

The MCS Talks series is still running (and there are additional resources to compliment the second session on core infrastructure). I also have some notes from the third and fourth sessions on messaging and security that are ready to share so, if you’re finding this information useful, make sure you have subscribed to the RSS feed!

Active Directory design considerations: part 7 (domain controller configuration and DNS)

Posted on By Mark Wilson

Continuing the series of posts about design considerations for Microsoft Active Directory (AD), based around the MCS Talks: Enterprise Architecture series of webcasts, this post discusses the design considerations for Active Directory domain controller configuration and DNS, which is critical to any Active Directory deployment.

Whilst the CPU specification for each server running as a domain controller will affect query performance, so can the disk configuration. Active Directory’s disk usage is mostly reads and the few writes are written to transaction logs before being committed to the database. For this reason, the separation of the logs (mostly written) from the database files (mostly read) can improve disk throughput.

Unlike for Exchange Server (where the decision to separate transaction logs from database files is mostly for resilience) with AD’s multi-master replication model providing resilience, the separation of logs and database files on a domain controller is about performance.

Having said that, in the same way that network improvements have allowed for domain controller consolidation, the move to a 64-bit version of Windows Server allows a larger addressable memory space and may even allow the entire AD database to be cached in RAM.

One critical piece of advice relating to domain controllers is when they are running in a virtualised environment. Microsoft recommends that DCs are never snapshotted (even RODCs), due to the potential to re-introduce out of date changes into AD if that snapshot is restored at a later date. Also, DCs should be configured to synchronise their time with the PDC emulator (the default) and not with the virtualisation host.

As I mentioned previously, DNS is critical to the correct operation of Active Directory and, which other DNS servers may be used, Microsoft recommends the use of AD-integrated DNS where possible as this provides a distributed, highly available DNS (effectively, DNS is as available as AD is). This can cause a political debate in some organisations, particularly where there is a heterogeneous network and the non-Windows computers do not use Active Directory. It is possible to configure Windows computers to use Windows DNS (AD integrated) and non-Windows computers to use another DNS implementation but this gets messy where shared subnets are involved (reverse lookup zones will be incomplete). For this reason, wherever possible, consolidation into a single organisational DNS should be considered.

Due to the overhead of managing root hints, Microsoft also recommends the use of the forwarding model and Windows Server 2003 introduced conditional forwarding, which is particularly useful where there are multiple forests, each of which is authoritative for its own zone. Windows Server 2008 improves conditional forwarding by storing conditional forwarding information in AD, rather than on each server (which created additional management overhead) although the standard forwarding is still defined on a per-server basis.