Guess who didn’t get a ticket? There’s absolutely no way I will ever be able to purchase a ticket through my corporation if the windows is down to the hour. No way. I was going to be lucky to pull a purchase within 48 hours.
Apple needs to expand this conference and offer paid developer accounts a first right of refusal.
One common discussion here at the day job can be summed up with a single statement:
“Why do my Macs keep falling off the Active Directory domain?”
I have a Mac Pro here at the day job that is bound to Active Directory. It’s a really large Active Directory with multiple sites and subnets. As a result, there are different domain controllers in those multiple Active Directory sites. Hey, it’s Active Directory, so the more machines the merrier, right?
After a few days of using the Mac Pro, I would often notice that logins from screen savers or from loginWindow would take longer than they should. That was usually a symptom of what every Mac user fears…
…you’ve fallen off the domain again.
There can be multiple reasons for falling off the domain. There’s a lot of data out there about how Macs do not like to renew their machine account passwords. Sometimes it has something to do with kerberos. Sometimes it has something to do with the moon.
In my case, I notice that when it happens to this Mac Pro:
1/21/11 11:49:58 AM com.apple.launchd[1] (org.samba.winbindd) Throttling respawn: Will start in 10 seconds1/21/11 11:50:08 AM com.apple.launchd[1] (org.samba.winbindd[1006]) Exited with exit code: 1
In the past I had a ritual. The ritual involves a force unbind and rebind of the machine to the directory. This would work for a while but it was only a matter of hours or days before it happened again. Finally I went to an extreme and reformatted the machine in hope that it would shake something loose.
Within 48 hours it happened again.
I often have to use a VPN to connect this Mac to a different network to perform some administration. In the Active Directory world this means I connect to a whole new set of domain controllers that are located in another Active Directory site. These AD sites are usually carved out by subnet and firewalled. Therefore if you connect to another AD site and cannot communicate with your old domain controllers for some reason you might drop off the domain.
I noticed that when I was connected to the VPN, DirectoryService seemed to work okie. The winbindd restarts stopped and the domain would start reporting correctly. I disconnected the VPN and watched the console log. There was a log about the network change notification, which was expected… then DirectoryService appeared to try to communicate with the Active Directory. It seemed to work, but if you look in the Directory application you’d discover that it’s fallen off the domain once again.
Connect up to the VPN – see the network change event… voila, everything works again.
Aha. So the Mac wasn’t detecting the change in Active Directory site properly. Interesting.
I conferred with another fellow here that works on the standard load for Macintosh systems in the environment. He mentioned that I should take a look and see what was written in the file:
/Library/Preferences/DirectoryService/ActiveDirectoryDynamicData.plist
…under the node “AD Domain Node List.”
We took a look and discovered that the domain controllers for the site on the VPN network were listed there. When I disconnected from the VPN, the file was not rewritten to include the domain controllers for the regular network as it should. Therefore, when the Mac tried to communicate with the domain controllers it was looking in this file and trying to connect to the domain controllers on the VPN AD site. That’s the wrong answer.
The theory? Well, it would appear that during some network change events the ActiveDirectoryDynamicData.plist file is regenerated properly with the domain controllers for the new AD site. However something is making it stick. After disconnecting from the VPN or returning to the home network this file is not regenerated properly.
To resolve, I did the following… after returning to the home network or disconnecting from the VPN and experiencing a failure with communication to Active Directory, you need to tell DirectoryService to regenerate the file:
cd /Library/Preferences/DirectoryService sudo mv ActiveDirectoryDynamicData.plist ActiveDirectoryDynamicData.plist.old sudo killall DirectoryService
Note that you’ll have to be an administrator of the machine and use your password for the first sudo command. But you knew that, right?
After a few seconds you should see DirectoryService try to talk to the domain and update the machine password in the console log. Not long after that you should see a new ActiveDirectoryDynamicData.plist file. Chances are good this new “AD Domain Node List” will contain domain controllers for the site/subnet in which you’re now located.
If you’re crafty and have this problem often, you might want to script up something that will automatically shove this file aside and restart DirectoryService on a network change event. It appears that DirectoryService does not always rebuild this file on a network change event by itself.
I hope this helps someone out there. Leave a comment if you have other tips for keeping a Mac alive on an Active Directory network.
AFP548.com has posted part 2 of their interesting guide on implementing z-push on Snow Leopard Server to fool your ActiveSync devices into thinking they’re communicating with an Exchange Server. I want to try this very badly, but limited resources prevent that at the current time.
If you’ve gotten this working and can speak about the experience, we’d love to hear from you!
Apple has introduced a new beta for MobileMe. The press announcement didn’t say much more than, “Hooray, there’s a new interface and it looks like the iPad!” That’s about all the press said as well. But there’s something so much more behind the scenes as usual.
If you have updated your Mac to 10.6.4, open up your iCal application. Go to Preferences/Accounts and try to add a new account. If you notice there, you can now add “MobileMe” as a new account type. Clicking this allows you to put in the MobileMe user credentials.
iCal MobileMe Account Setup box in 10.6.4
But if you’re paying attention, you’ll see that the initial sync gives you an error:
iCal MobileMe Error Box
Notice the name of the operation? ”CalDAVAccountRefreshQueueableOperation.” That’s CalDAV, folks. That’s the same calendaring server implementation in Snow Leopard server.
To make this actually work and not receive the error, you have to log into the MobileMe website, get into the calendar icon and click “request an invite” for the beta. Without being in the beta, you won’t be rolled over to the CalDAV implementation.
Why is this important? Apple is one of the major players in the calendaring standards consortium “CalConnect.” One of the proposed standards that CalConnect is driving today is the use of CalDAV as a standard. Apple’s implementation of CalDAV is even open source.
Now they’re talking the talk and walking the walk. There’s a FAQ on the beta here and it does give a little more detail on the CalDAV implementation.
But there’s something else.
I love conspiracy theories when it results in good news. While this beta is good news, there’s even better news. Buried in the FAQ is this little tidbit:
Support for using the beta with Microsoft Outlook is coming soon.
There is more information at the link here. To get this working in Microsoft Outlook, you have to install the MobileMe Control Panel for Windows. Effectively, this means Apple is bringing CalDAV support to Outlook.
…and that, my friends, is the real story. Apple is providing an alternative to Exchange for Outlook users. The next logical step would be extending this CalDAV connector to Snow Leopard Server for Outlook users as well.
I’ve said it before and I’ll say it again. Apple has a knife with Microsoft’s name on the blade.
With all of the love the Macbook Pros have been getting recently, it was only a matter of time before the fanboys start clamoring for updates on the other pieces of hardware too. So, here we are, three days later and we thought we’d light the torches.
I was thinking aloud in a somewhat unrelated conversation about how nice it would be if Apple were to update the Xserve line soon. Since we have a clue about their thinking for processors, how long do you think it will be before we have updates on the Mac Pro and Xserve?
Better yet, what processors do you think they’ll have? Earlier in March, TUAW passed along the rumor that the Mac Pro was slated to receive the i7-980 processor (“Gulftown“) with six cores. Since the Mac Pro is typically dual processor, that would be 12 processor cores. Ouch.
It depresses me greatly that the press rarely gets excited about updates to the Xserve line. Those 1-U rack mountable servers pack some serious horsepower. What type of processors do you think the Xserves will sport?
We’ll have some fantastic information on Xserve configurations coming soon on our shows. We’ll probably wait until the platform gets updated before we cover the actual hardware, or we’ll find that podcast obsolete pretty fast.
So what do you think? Give us your thoughts on updates for the Mac Pro and Xserve lines. Start… now!
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=a12e62a3-2705-410f-a7f3-fdce6929b2fe)
|
Copyright © 2010-2012 The Cat Convention. This website is a production of Red Abstract, Inc.
|
 |
Blabber back