Problem solve Get help with specific problems with your technologies, process and projects.

DCs at sea: Configuring mobile Active Directory domain infrastructures

It’s common for admins to deal with mobile users, but what if the domain itself moves? See how basic AD principles always apply -- no matter what the situation is.

Every Active Directory administrator deals with mobile users and the challenge of controlling moving targets, but...

what about mobile domains? I recently worked with some interesting environments like these that, while unusual, show how flexible Active Directory truly is. As we look at the following case studies, keep in mind that Active Directory operates efficiently by following basic principles -- no matter what the circumstances might be.

Case Study #1

Company A (for reasons unknown) occasionally ships an entire domain infrastructure to a remote location for a period of time, then ships it back and plugs it into the local LAN. The domain is part of a multi-domain forest. Using delegated DNS, Company A includes domain controllers (DC), global catalogs, servers, clients, etc. -- basically a nice package that that’s just ripped out of the domain for a period of time.

While quite out of the ordinary, this can be done (whether it’s the best thing to do is another story). Still, there are several things to watch out for with this configuration, such as:

  • Network applications -- Everything has to be self-contained, so don’t install applications from a network share outside the domain.
  • Network shares -- Obviously, all shares must be in the domain. It’s also possible to create Distributed File System (DFS) shares that replicate data in the domain. Keeping a DFS server and DC at the company HQ site allows the remote server to sync back up when it reconnects to the LAN. This helps with disaster recovery, but there must be restrictions set on the HQ server so users can’t modify data there. If users modify a document on the HQ server and the remote server while the domain is disconnected from the LAN, someone will lose his or her work. This configuration is shown in Figure 1 below and described further under “Options” and in Case Study 2.
  • Cross-domain authentication -- If universal groups are used and multiple domains are in the forest, a global catalog (two for redundancy) should be employed in the domain.
  • Lingering objects -- This is fertile ground for creating lingering objects, but the solution is pretty simple: set the tombstone lifetime to a value greater than the longest time the domain will be separated from the network, plus 30 days or so. If the transportation people go on strike you can always adjust the lifetime to a higher value, up to a maximum of 365 days. Note that if you adjust the tombstone lifetime with the domain separated from the LAN, you will also need to adjust it on the mobile domain controllers individually.
  • Complaints back home -- Yes, there will be complaints in the event logs of the DCs on the LAN (you can’t just rip a whole domain out of the picture and have everyone be happy). One way to deal with this is to filter the event logs, but not even Windows Server 2008 lets you configure filters on the event logs to hide complaints from these remote DCs. There may be third-party tools that can do this, but be careful; you don’t want to filter critical events for your LAN DCs.

There are other options to consider as well. To me, the most obvious choice would be to create the mobile domain as a separate forest and have a trust between the two forests. Replication would not care, the mobile domain would be autonomous and you would get the benefits of sharing resources with the servers back home. Sure, there could be conditions where this might not work, but it’s worth considering.

Another idea might be to leave a DC from the remote domain in the LAN. This would not lessen the complaints in the Domain Services event log and lingering object danger would still be present, but it would hold the domain’s place in the forest as sort of a “reverse lag site” configuration. If the transport gets blown up, at least you’d have a DC holding the domain info to build from.

Case Study #2

Company B is a maritime company with a fleet of ships operating from various ports. In this case, the domain controllers are on shore at the home office and only clients reside on the ship. The company has a three-tier network:

  1. When the ship is in port, they are connected to a LAN.
  2. When the ship leaves port, they use UMTS (Universal Mobile Telecommunications System), a 3G mobile network. UMTS gives them connectivity for a certain distance out of port.
  3. When they travel beyond UMTS, there is no network connectivity

Take away the info about the ship and the three network tiers and it’s really just the usual challenge of dealing with remote users. In this case, a problem occurred when the ship went beyond the UMTS range and clients experienced 45 minute logons. There was no delay when the network cable was unplugged.

It turns out the clients had home drives in their profiles mapped to shares on the servers on shore as well as DFS shares. The big challenge with this configuration was that there were no server or DC resources on the ship.

With a bit of research I found that there are a number of companies that specialize in creating Active Directory environments like this for cargo ships, cruise ships, etc. Military organizations use these configurations as well. One company I found called iDirect even offers a network of satellite links for continuous broadband access at sea.

The typical configuration is that each ship has its own domain held together by a forest root at corporate headquarters (similar to Case Study #1). I didn’t see a lot of details, but they likely had a DC for each domain at the corporate site as shown in Figure 1.

Figure 1. Remote domain infrastructures
The Remote domain infrastructures

This really isn’t much different than having a multiple-domain forest on the ground with DCs for each domain in multiple geographies. A DFS server at the corporate site for each domain with a replication group that includes the ship’s DFS server would work as an online backup as well. This makes each ship autonomous, and sharing data could be accomplished by copying data back to the domain servers on shore when in port (unidirectional). This would allow backups from a single source on shore in case a disaster occurred on the ship (flooding, fire, etc.).

Configuring Active Directory domain structures for a mobile domain is really no different than doing so for a fixed-base domain or forest. It’s all about dealing with network connectivity between the clients and the DCs, as well as between the mobile and fixed domains. Look at profiles, shares, applications, replication and authentication to determine how the clients will work when separated from the rest of the forest. Don’t forget about disaster recovery either -- keeping a DC from the mobile domain back home will save you a lot of clean up and repair later on.

You can follow on Twitter @WindowsTT.

Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.

Dig Deeper on Microsoft Active Directory Design and Administration