Tag Archive: Dual Directory



This is the second blog post discussing the change from a .local Domain to another namespace in order to better support the Mac clients in our Domain.

 Planning for the new Domain

The initial decision to move forward with the Domain change was easy compared to what was next.  The next challenge was how and when based on our people resources, major church-wide events, and launching of our 3rd campus.  As far as the life of Clear Creek goes, there are not any very “slow” times in which a project like this would be easy.  The next consideration was the when and how to do this to get the most of our volunteer resources and asking Solerant (IT Contractor).  This is important because while I have some technical skills, I’m really more of a project or resource manager.

  • We decided to deploy on October 9 & 10 because we could start after church services on Sunday and several of our volunteer team could also be present to help on Monday because they had Columbus Day off.
  • We also decided that migrating the Microsoft Exchange Server (E-mail) was going to probably be the most challenging part of the migration and pose the most problems.  I thought that Solerant would be best to do this because they already handle many Microsoft Exchange upgrades each year and that they could handle the added complications that went with a Cross-Domain migration of Exchange.
  • I polled the staff to see if making a huge change like this would seriously impair ministry.  I did my best to explain that everything was going to change, but I don’t know if there is really a way to explain just how much was going to change.  I tried to think of “what the worst case scenario” implications would be to best prepare them.

Once I made the case with my boss and laid out the basic plan we moved forward.  The team normally meets on Monday nights, but over the next few weeks we also met an additional night in order to account for everything that would need to be done.  Sunday the 9th would be the day that the most manpower was needed, so I wanted us to be ready to roll since that was going to be a long day.

Thankfully, in our infrastructure we have an Equallogic SAN and Virtual environment using VMWare.  If we had not had this environment, it would have cost a whole lot more to change our domain at the size we are now. I think we had to add five virtual machines to complete the migration.

Creating a New Domain

The first thing we did was create a new Domain.  We “spun up” a new server in our virtual environment and made it the new Domain Controller.  We then needed to create a “trust” between the new domain and the existing domain.  In order to do that we had to remove the .org from the existing domain’s forward lookup DNS records and setup forwarders to the new Domain’s server.

Extending the Active Directory Schema

This time around, we decided that maybe the Magic Triangle was causing too much delay for the Macs to find resources and that maybe extending the Schema in AD was a better option.  We used Apple’s white paper to change 40 attributes necessary to support Macs in the Domain.  To me, this sounds like a lot, but now I understand that this isn’t in the big picture world of a Domain.

Valuable links:  Apple’s KB and a good blog post, but note that the Dynamic UID problem is not true anymore with a recent patched OSX.  This is how to modify the schema, and the thing we need to do still for applying WGM policies to computer list.

Mimic Necessary Foundation Services

So now we had a domain consisting of a single machine that could talk to the other domain and we could find resources between them.  Now we begin making duplicates of resources that we won’t migrate

  • We created a certificate authority with Web certificate component
  • Network Policy Server (NPS) in order to prepare the way to move our existing Wifi system.
  • We cloned the Print Server and added it to the new Domain which saved huge amount of time with adding drivers and creating shares.
  • Evaluated/Exported all of our Group Policy Objects (GPO) to determine which ones needed to come over, which ones weren’t working, and how we could simplify.
  • Evaluated our Active Directory structure since we had a lot of legacy structure that was not clear, possibly structure from Small Business Server a long time ago.
  • Decided that we would eliminate whatever XP support we could and get the rest of our machines to Windows 7 where possible.  We are currently down to 3 machines with Windows XP with plans to get them out and 5 Vista computers which we will be able to image very soon.
  • Created a new Windows 7 VM and installed the Active Directory Migration Tool (ADMT) from Microsoft on another virtual server joined to new domain.
  • Decided we would migrate Microsoft Exchange as the last step since they were unable to do it beforehand and I only had a short window for my volunteers to help.  In hindsight, it would have probably been best to migrate Exchange FIRST, so that we could migrate the users with their Exchange attributes.
  • We wiped our physical Domain controller and loaded it with Server 2008r2 to match all of our other servers the week before the migration.
  • The morning of our migration, demoted another Domain controller in our .local domain so that we could keep the new Domain pointing to similar DNS to avoid problems with more devices.
  • We made sure we had a second virtual Domain controller on our other Virtual Host server so that we would be prepared if we had any power issues.  We agreed that it would not be a good idea to move a domain controller from one domain to another. It never seems like those things demote properly in my experience. This added a little bit of extra work with re-creating the DHCP server, the options, and his subnets.
  • Joined some test machines as clean, new clients to the new domain including a some Macs: Lion Mini, a Snow Leopard mini, and a Lion Server Mini.  We wanted to get things right with Lion from the start.

What would end user experience during migration?

Since I was not able to quickly find information online about what a user would expect when all of this occurred, I put myself in their shoes in order to make this go for them as smoothly as possible.  My team was busy working on the major aspects of the migration, but they really aren’t wired to think about how the regular person who just wants their computer to do its job might experience with EVERYTHING changing.  I started off with what I know…which is when you add a computer to a domain, there is no user profile.  My assumption became that if you took the same computer from one domain and moved it to another, they would likely have a brand new profile and not see the same desktop as they did the last time they logged in.

  • For most users, this would mean that they would essentially not have anything in “My Documents” or any of their personal settings or see anything they kept on their desktop.
  • Laptops and Macs were going to need extra attention.  The people who use those computers have very specific needs so more is on their specific local machines and thought it would be important to migrate their user data.  We needed tools or scripts for both platforms.  We chose ProfWiz for Windows machines and used these magic commands for Macs.
  • I also knew that because of email, they would essentially be operating as two users – one for email from the existing domain and their other account in the new domain.   I also realized that the regular user was not going to see the distinction.
  • How do I communicate with everyone in a way that doesn’t alienate or frustrate?  I decided to prepare via staff wide email and personal conversations to make sure things were clear to key people.  Then I chose to pick a person in various ministry areas that I could contact to update with the latest information should email be down or we had any major problems.  I could call or text them where to find instructions for them to forward to the people in their area.

How I prepared everyone for the migration

  • I sent out emails to staff asking them to make sure all of their documents were living on our network drives.  We’ve done a pretty good job of having users understand where to store their data.  We choose not to redirect profiles since there has been benefit for many users to put some data on their local computer that can be discarded.
  • People also forget the small things like how to set a default printer or how to export and import their browsing Favorites.  I sent instructions for both in emails ahead of the migration and made sure key people knew how to do those things or print them out so they could help each other.
  • I also sent out instructions to remind users how to report problems by using Solerant’s ticket system or to leave me voicemail message.
  • I made sure that laptop users verified that their data was on the network and for Mac users we made sure they had a full backup in case we had a problem and were not able to help them as quickly as we could.  I’m all for having a backup of your backup.
  • The users also needed to know that they would need to use Webmail (OWA) or email from their cell phones on Monday, until we completed the migration of mail.
  • I made sure I thought about all those “what if’s” on things failing.  My goal?  Have a backup plan to support the end user so they can get their job done no matter what.  We can’t afford for them to not be able to get their job done, nor can we afford to lose credibility with the users because the change was so painful.
  • There isn’t a whole lot on the actual Domain creation and migration that I can do, so I made sure my spreadsheet for all of the servers with their roles was updated and questioned how each one of them would be affected during this change.
  • I created a map of where every machine was physically located and cleaned up the current Active Directory to remove any computers and users that were no longer in service.
  • There were a few other obscure things to remind the team of, making sure the SSO for our RemoteApps were accounted for, KMS setup in the new domain, making sure any references to the Fully Qualified Domain Names (FQDN) references to the old Domain were accounted for as well.
  • During our tests we noticed that our current Domain policy was actually working in that it removed any local user privileges with local administrator rights and made them “guest” users while in the Domain.  To bypass this, I had to make sure my team had good instructions moving from computer to computer on the day of our migration.
  • I also made our Resources team (DVD/CD production of messages) and our Database Reporting Team aware. Both of those teams do not have a staff person in the office during the week, so I needed them to think about how this would affect them and be willing to test to avoid technical issues when they meet or when Sunday comes.

Implementation:

How long did it take?

This is rather tricky to answer, but since I have several people with a little amount of time, I believe it went as well as could be expected with some parts better than others.  It took about three calendar weeks to prepare, one day to move all of the users and computers, and three days to get email moved.  Again, hindsight says we should have moved email first and I still cannot guarantee you that it will be easier.

Moving users and computers

This was a very long day.  We had a good lunch and started after the last church service.  By this time we had made sure we had all of our new infrastructure in place.  I’d already re-imaged some user’s computers during the morning services.  My thought here was that since they were going to have to essentially start over, I may as well give them Windows 7 as well so they don’t have to start over twice within a few months.  There were only a handful of machines I was unable to take care of due to the software or hardware they were running.

  • Six of my volunteers (and me) helped on Sunday and which was kind of tedious process, but these guys were very good.  We worked from 1:30 pm until around 11:00 p.m
  • To start, I had three people working on servers/user migration and the other three working on clients.  It seemed I was more useful answering questions, but I did get to move a few clients.
  • One of those guys made sure we migrated our NOD32 (antivirus) so that clients would see the new server.
  • We also verified DNS for some other servers that were not in the Domain so they would work well after we were done.
  • We moved Ruckus (our Wifi system) pointers to the new Domain NPS (Network Policy Server).
  • We used the ADMT tool to migrate users, had them keep the same Security Identifier (SID), and migrated the password.  The latter created angst with my security-minded volunteers, but I really needed to protect the end user here to prevent distress.  After they migrated the users, I went through each user account and unchecked the box that requires them to change the password and removed the login script since we now push the drive mappings via Group Policy.  I have to say this GPO is fast and beautiful compared to a login script!
  • We moved some servers and workstations using the ADMT tool, but in hindsight I’m not sure that was a good idea for the phone or Remote Desktop Servers.
  • We used ADMT to migrate the file server.  I believe it was very important to move this server this way because it migrated permissions and security groups as well.  Some of folders appear to have had a hiccup and did not duplicate properly, but fixing permissions for a few directories was not as bad as having to start over.   We also consolidated some of our drive mappings to make it easier for our Mac users since they have to browse differently to get to the same shares we make appear magically for the Windows users.
  • Our Church Management system is ACS and we run it via Microsoft’s RemoteApp Remote Desktop Services option  from a Server 2008r2 server.  I created new RemoteApp packages for People Suite and Financials so they could be applied via GPO.
  • Once the servers were done, two of the volunteers started on laptop users, most of which had left their laptops in their offices (our request) to allow us to help them before Monday.  We used a tool called profwiz to migrate user profiles on Windows machines and some magic commands on the Macs to move their profiles.  I wish there was plenty of time to do this for every user, but we just had too many computers.

When we finished, we called it a night.  We had to convert some data LUN’s overnight so that we could completely move to new Veeam backup software (designed for virtual environments).  We left that running while we slept.

Final Blog Post in this series will cover:

Domain Migration:  Challenges & Successes

OSX 10.6 – Network Timeout


In a previous post, I mentioned that when we upgraded some Mac clients to Snow Leopard (10.6), we experienced issues with new and existing machines not being able to connect to the network.

The Symptoms:

  • Existing machines would not be able to login and see their network shares or not be able to login at all.
  • New machines would not be able to login to the network after adding them to the domain and rebooting.

The issue became slightly better after an OSX software update a few weeks later, but we were still noticing that machines were not always connecting properly during login, and it was not a problem that occurred each time.  When we checked in the Open Directory Utility (System Preferences>Accounts>Login Options>Network Account Server> Open Directory Utility) would see a “red light” with the Active Directory on the Mac client machine.

It appears that Macs uses both Active Directory and DNS to find what it needs at login.  One of my volunteers (Kevin) suspects that it is a Kerberos issue and that it could also be trying to login with SSL connections first and goes to clear text, which counts against the timer.  He wants to do a network capture when we experience this, but that is one challenge we run into working with volunteers who have a day job.

Two workarounds:

  • Have users shutdown their computers each night.  If you have the login options show “List of Users”, then when they power up in the morning have them wait until they see “Other” show up.
  • Edit the MDNS value in a .plist file in each Mac client to give it more time to find what it needs in DNS (steps will be posted below).  We also put this in our Image that we deploy so that each machine has this edited file. Paul Rhodes, one of my volunteers found this workaround.
  1. Launch Terminal
  2. Type: cd /system/library/systemconfiguration/ipmonitor.bundle/contents/ (hit enter)
  3. Type: sudo pico info.plist (hit enter)
  4. Change the MDNS value from 2 to 5  (at the end of the document, then move the curser to change the value)
  5. Save and Close (ctrl+O, ctrl+X)
  6. To verify change:  tail info.plist

We hope this is not a permanent change.  We aren’t happy with how long it takes a Mac to find the network.  Apple Enterprise support told Jason Lee that this is just how Macs interact in a Windows Domain.

**Please feel free to contact me if you need more information or if you have found a better solution.  I’m not highly technical, but know who to point you to that can better answer questions.


In May of 2009, we began the process of adding Macs to our Active Directory in order to give our Technical and Creative Arts people the ability to view our network shares and have more of the same privileges that users in our Windows network enjoy.

There are several ways you can accomplish this:

  • Extend the Active Directory Schema
  • Use a 3rd party product like ADmitMac or Likewise
  • The “Magic Triangle” or what Apple prefers to call the “Dual Directory” method.

My team and I discussed the various methods and I also discussed them with some other churches who integrated their Macs and we decided to use the third “Dual Directory” option (Dual Directory=Active Directory (Windows)+Open Directory (Mac).  We used a combination of both links to PDFs in Jason M Lee’s blog to accomplish this (thanks Jason!).

Here is why we chose this option:

  • Both the paid and volunteer IT Staff at our church is part time, so we need to keep as much as possible with best practices.  This eliminated the option for extending the Active Directory Schema.
  • By the time we paid for a 3rd party product for existing church-owned Macs, we could have spent the same amount on a Mac Server.  If we had gone with a 3rd party product, it would have needed to have been software that could have provided support, since our limited staffing resources would make it difficult to troubleshoot.
  • Technical Arts wants to eventually go with a Final Cut Server, so having an existing Open Directory would likely make that an easier move in the future.
  • We also wanted to push software updates, antivirus updates to the Mac clients.

Each church I spoke with had varying reasons for the method they chose.  Some are using the 3rd party product and their reasons make sense.  I didn’t find a church that chose to extend the Schema, which makes me nervous because it could potentially add some problems we might not be able to solve.

How the project went:

We used a Leopard Server and a couple of iMacs running Leopard to start.  We agreed with the Technical Arts people that we would only use Intel Macs in the Domain to keep things simple and that users should not have local admin rights since it is a lot easier to accidentally pull a Mac off the network than it is with a Windows machine.

On the server end, I think we needed our Active Directory to be at the 2008 level, but I can’t remember if that is 100% true, it seems that Microsoft made some modifications that made the process better with a 2008 Domain.

My team went through both of Jason’s links and were able to have our first Mac client in our domain in two Wednesday nights (my volunteers serve on Wednesday evenings).

We encountered our first hiccup about two weeks after our integration began because our Technical Arts Director began upgrading Macs to Snow Leopard.  That broke any Mac already on the Domain and prevented us from successfully adding new Macs to the domain until Apple released a software update several weeks later.