Tag Archive: Open Directory


Domain Migration


This is the first of a series of lengthy blog posts on our recent Domain migration.

About 2 ½ years ago Clear Creek Community church began integrating Macs into our Domain to provide the Arts team with our network resources to attempt to make them equal clients to our resources. The goal was to make our IT resources on mission.

Historical reference and mission orientation

To understand why we did this would require us to go back to the whole church mission and strategy:

  • Lead unchurched people to become fully devoted followers of Christ.
  • Provide multiple campuses of our church body from the Beltway to the Beach and from the Bay to Brazoria County.

My job is to constantly focus on how to accomplish our mission and function like one church body by providing the best technology support to those who directly accomplish the mission.

Clear Creek has grown at a rapid pace which is fantastic for the mission! But, it becomes more challenging to provide for the needs of the staff and volunteers who accomplish our mission.  People need to get their job done in a short amount of time. This is true for everyone in any type of work in general but we feel it more strongly since the majority of our staff are part time or gifted volunteers with a heart for the mission. This growth also highlights how important it is for the team to be unified and cohesive. I strongly felt the need for the Technical and Creative Arts teams to be able to bring their resources together into the same cohesive integration and organization rather than leaving them outside to fend and manage for themselves.

It would be a change in operations for them but I could see how it would help make the team more cohesive and integrated on mission. They also liked the idea of organization and integration. The people hurdle done the technology hurdle remains. Computers just do what they told (no matter what we think when they seemingly misbehave) so we just need to tell them what to do…

Integrating Windows and Apples

Plenty of organizations have integrated the Apple Mac OS X systems into their corporate environment with success, just as many have attempted and failed. My volunteer base is not full of people who know how to support a mixed network. It’s not a very common task. Most business environments choose for the user what tools they get to use.  For us, like many small or large environments, it still makes sense for most users to use a Windows machine because of the business type tools we have chosen to do the work.  Music and video professionals still prefer Macs to get their work done in the best possible way.  Therefore, the arts teams had both a Windows machine and a Mac, which I’ve always felt was a waste of resources.  There had to be a better way to help them.

The push-back in most IT shops, including churches is that Macs are too expensive and support for them takes longer since they aren’t designed for business/work environments.  We also get the push-back from users who prefer the Apple over Windows, because that is what they are comfortable with.   I mention this, because once you begin adding Macs to your network, more people are going to want them.  This will be a balance:  providing the tools people want or need with the boundaries of good stewardship, without alienating the end user because they think we are mean.

There is no “Best Practices” really when you support multiple operating systems.  You can accomplish this by one of three methods:  3rd party per client product, Dual Directory method, or extending the schema in Microsoft’s Active Directory.  It really takes analysis of the tools and the structure of the organization and a lot of trial and error.  We have taken note of where many churches have jumped around with multiple 3rd party tools or completely removed Macs from their domain altogether.  We still think we can find a way to make the Mac user’s machines happy and live well among us.

We first integrated our Macs within our domain using the Dual Directory method, otherwise known as the Magic Triangle.  We do subscribe to a Mac Enterprise users group where we have learned how many schools and businesses handle Macs, and they use one of those three ways.

We ran into issues immediately when Snow Leopard came out.  This added issues for Macs on our network and caused them to take forever to login and connect to resources.  It was even more painful if you had a laptop and logged in outside of our network.  This wasn’t too bad for just a few Mac users, since most of them were desktops and the mobile users were willing to put up with these shortcomings.

Then we had some other key users switch to a Mac and it became evident that this problem was going to be worse.  So a year into our integration, we researched and learned that the problem could be because our internal Domain was a .local namespace.  Push came to shove so I brought up the discussion of getting rid of the split DNS.  We agreed at that time that while that sounded like a good idea, there was really no way to know whether or not this would make things significantly better for Mac users, nor provide any benefit to the Windows users.  Since our network has grown to 100+ PC’s, 20+ servers, 18+ Macs, we dropped the idea.

What is the issue with .local and Mac OS X?

This is a challenge to explain but this is the answer that finally made sense to me.  It turned out I really just needed a good picture of how a Mac functions.  Think of it this way…A Mac is designed “to just work” which is wonderful if you are an end user living on an island of your own Mac.  You turn on your Mac and since it’s “name” always ends in .local, it goes and looks for anything with that name in it to be friends with in case you want to share iTunes or anything else with them.

This isn’t so great in a mixed network with a .local namespace. A domain can’t belong to two masters; it can’t be the fun iTunes Library sharing environment and the DNS served business environment.

When you login to a .local domain that uses the Dual Directory method, The Mac does what it knows how to do and uses Multicast DNS to ask all the machines around it if YOU are the one that knows what it is supposed to do…and it doesn’t seem to really listen since there is too many things for it to check through.  Then, once it finds the Domain, it will login.  It takes about 3 minutes for this to happen on site and about 5 minutes or more away from our network, in order to see your desktop and be ready for you to work.

Time to change

It became clear that moving away from the .local namespace was important.  We still couldn’t actually say what this would buy for us since making this change was going to affect every device, every server, and every USER.  The last was my biggest concern.  Was it worth disrupting EVERY user to make the world for Macs better?  We decided it was worth it to try to help those Mac users before we get any larger and before we get to the point that we serve our church across multiple campuses with the same resources.  Currently, we have multiple campuses, but we office out of the same location.

In the recent past the benefits did not seem to outweigh the risks but this year we gained some new dedicated volunteers:  one that supports a mixed environment like us and another one that has the same Windows infrastructure in his work environment as we do. With the solid foundation suddenly so much improved it was time to push the issue again.  My questions were:

  • Why does having split DNS with a .local namespace present such an issue and is it always going to be an issue?
  • What does this do now that Lion has been released which has its own connectivity issues with Windows and there isn’t a supportable way to downgrade newer machines to Snow Leopard to manage our growing need for Macs?

Now, with a Lion breathing down our necks, the benefits outran the risks.

The next blog posts will cover:

Advertisements

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.