Enabling sleep/hibernation mode on a server with the Hyper-V role enabled

Posted on By Mark Wilson

One of the problems with running Hyper-V on the notebook PC that I use for work is a lack of hibernation/sleep support. Mark Harrison has posted a partial solution which allows him to hibernate/sleep until he starts running virtual machines:

By setting the Hypervisor/Virtual Machine Support Driver to manual startup (editing the Start key at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\hvboot to a value of 3), Mark found that Hyper-V can be left installed but not running, then net start hvboot can be used when Hyper-V is required. From this point on, sleep/hibernation will be unavailable (until the computer is restarted).

Unfortunately the main VM I run is the one with the (32-bit only) VPN connection to work that I use to access all of my corporate applications (which I need to access on a daily basis) so this solution doesn’t help me much, but I thought it might be useful to others.

Fluff stops play

Posted on By Mark Wilson

I think I heard the other day that Apple has sold something like 5 million 3G iPhones since launch. That’s a drop in the ocean compared with the number of devices that manufacturers like Nokia sell but nevertheless quite a bit chunk of the smartphone market. Unfortunately it also seems that the quality control has slipped in order to get so many devices out (based on the problems that some of my friends have had) and the v2.x software is certainly not as solid as the v1.x (even without applications installed).

Bearing that in mind I was disappointed, but not entirely surprised, to find that my the microphone in my iPhone headset was not working last week. I wasn’t sure if the problem was with the headset or the phone itself but I booked an appointment with a “Genius” at my local Apple Store to see if the problem could be identified. Sure enough, it was – and it was probably the least taxing of all the problems that particular genius had to solve today… some fluff inside the headphone socket, preventing the headset jack from making a proper connection. Once cleaned out everything was working fine. So, if you are experiencing similar problems, take out a can of compressed air and save yourself a trip to the Apple Store.

Active Directory design considerations: part 6 (domain controller placement and site design)

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 placement of Active Directory domain controllers and the associated site links.

Domain controller (DC) placement can have a huge impact on user experience (e.g. the impact on logon times) but generally the choices are for placement on hub sites or at satellite (branch) locations and these should each be considered on a case-by-case basis, looking at the network and application requirements.

It’s worth mentioning that available network bandwidth has generally increased considerably since early Active Directory deployments were designed and this will allow for consolidation of the overall number of domain controllers in many cases.

With regards to global catalog (GC) servers, there are very few reasons not to make all domain controllers global catalog servers. Indeed, in a single-domain forest, all domain controllers are effectively GCs. In particular, multi-domain forests using user principle names (UPNs) for logon should consider making each DC a GC.

Read-only domain controllers (RODCs) are new in Windows Server 2008 and provide read-only access to Active Directory. Many people (myself included) have compared this functionality with Windows NT backup domain controllers (BDCs) but that’s not a true comparison as no passwords are stored locally and an RODC cannot be promoted to a full DC. The introduction of RODC functionality is really a security feature to mitigate against the theft of a DC on a high-risk site (e.g. a branch location without a physically secure computer room) and is not really intended for DMZ access to AD. RODCs can reduce replication, as they only replicate inbound traffic; however where users travel between several remote sites they can increase logon traffic as the users details may not be available on the RODC.

The decision as to whether to deploy an RODC or a full DC will depend on:

  • Application requirements (e.g. does the application need to write to the directory).
  • Site topology (e.g. site link bridging turned off – see below).
  • Password replication policy (no account caching will lead to increased WAN/hub DC traffic).

Further details may be found in Microsoft’s RODC planning and deployment guide.

AD site design is closely linked to DC placement and there are two basic models:

  1. A logical site for every physical location, assigning subnets for each physical location to the corresponding site.
  2. A logical site for every physical location that has one or more DCs, assigning subnets for physical locations to the most appropriate site (based on the underlying network).

Both approaches work well; however with the first option, DNS site coverage must be considered (i.e. ensure that that appropriate name server records are in place). With the second option, clients are automatically referred. It’s also worth considering other applications (e.g. DFSR) and if there is no DC on site then option 1 may make more sense.

Site links should map to the underlying physical network with appropriate costs and replication schedules applied. According to Microsoft, one common mistake is to assign all sites to the DEFAULTIPSITELINK – effectively using a single link for replication and preventing the application of appropriate costs for least-cost routing.

Also, the option to bridge all site links is on my default and, although this is appropriate on a fully routable network (i.e. one where all DCs can communicate freely) it is not recommended for branch offices (due to the overheads associated with the intersite messaging transport and calculating site links) and can be disabled using repadmin /siteoptions (which still allows DFSR to calculate site link costs).

Custom site link bridges may be used where a network is not fully routable (e.g. if firewalls restrict communication between DCs).

The AD replication topology is automatically managed by the knowledge consistency checker (KCC) based on the site link design, automatically creating the connection objects that are required for replication. The KCC-generated topology is used for AD and sysvol replication using the file replication service (FRS); however in Windows Server 2008 sysvol is replicated using DFSR, once the domain functional level is at Windows Server 2008. This increases scalability (removing inefficiencies around FRS version vector joins). For new Windows Server 2008 native domains, replication of sysvol via DFSR is automatic but for upgraded domains there is a migration process to follow.

In the next post in this series, I’ll take a look at the design considerations for domain controller configuration.