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: