Archive for August, 2010

I often get requests for instructions for this project.  It has been around for quite a while, but it always gets a fun response!  Here are instructions for the project as well as a video.

The video notes that I used some supplies from a kit club I am part of at The Scrapbook Junkie. They offer a monthly kit subscription with a new kit available on the last day of the month.  The store is in Webster, Texas, but I’m sure she’d be happy to mail the kits to you each month if you wished to subscribe to her club.

Here are the written instructions for the Fabulous Folding Photo Holder.

See Below for video:


This follows previous posts about our Mac integration in our Domain.  If you have not read them, we chose the Dual Directory method (sometimes called Magic Triangle) to integrate our Macs into our existing Windows network. It takes the Macs a long time to find the network and doesn’t always find the user’s home folder.   Kevin has done some network captures using Wireshark and has learned a few things that we have tried. (He has found this book on Wireshark to be most useful.)

First, we’ve experimented with disabling spanning-tree protocol for our client ports and seen about a 20 second improvement from Mac gong sound to ‘other’ showing up the login options (indicating that it knows there is a network). This had a negligible affect on windows clients. Note: on Dell Gigabit switches this is enabling Fast Link on a client port.  We learned that from this blog post.

Secondly, his captures of a Mac booting up and attaching to the network are very interesting. Before the Mac has even sent out a DHCP request is doing multicast DNS queries with an APIPA address to find the Mac domain controller (open LDAP server). Even after it has its IP address it continues to try and use MDNS.

The next moves and nagging questions :

  • investigate having an intelligent MDNS service that proxies the inside DNS
  • investigate if IPv6 DNS might be necessary as we see a lot of IPv6 MDNS requests even from iPhones on the wireless
  • IP Helper– could IP Helper settings on the switches assist with DHCP and cut out time or MDNS in someway?
  • Is it still just an issue with .local domain that OSX might insist belong only to MDNS?

Kevin will continue to analyze the data and has bounced some of this off of his friends Lester and Eric.

If you have experienced this issue, please comment and share what you have learned!

Paul Rhodes found this article, but we would like to do some more research before going this route.  The problem we see here is for our laptop users having multicast issues when they are offsite.

One of the reasons I really like my job is that there are such innovative approaches to helping End Users get their work done.  I think from the technical side of things we can sometimes struggle with the solutions being simple for the End User.  RemoteApps are a wonderful way to fill our need for our database to perform better for the User as well as management and maintenance by our Database Administrator.

A challenge that was becoming an increasing issue with ACS as a RemoteApp is the confusion it would cause staff and volunteers when they would move to a different computer.  The first time you login to a Remote App, you get a screen with a lot of words on it about trusting the security of the server you are trying to connect to.  After that you get another screen that wants your network credentials–which truly confuses the User!  Then, if they don’t tell it to save the network credentials (which we are okay with on site), they have to do it all again the next time they launch the application.  Paul Salvo, one of my volunteers was happy to look to resolve this issue.  Vista and Windows 7 were pretty easy to resolve, and we could push the changes through Group Policy.  Our XP clients required a registry change which we pushed using a filter in Group Policy (Thanks to the guys in the CITRT IRC Chat room who helped me figure out how we needed to push that only to XP machines).  This solution also works if your site has Users working regularly in Remote Desktop servers on your site.

All Windows Clients GPO:

This policy instructs the clients to trust a list of servers for pass-through authentication.  We applied this to the computers in our Group Policy:

  • Computer Configuration
    Administrative Templates
    Credential Delegation
    Allow Delegating Default Credentials with NTLM = Enabled
    Set to TERMSRV/<FQDN of server>
    Set to TERMSRV/<server hostname>
  • We added all of the Remote Desktop Servers we wanted to trust with pass-through.  We created entries with the FQDN and entries with the server’s short name.  We’ve heard that this is recommended.

Windows XP GPO:

  • You really need SP3 and to have the latest RDC on the client machine We used this KB file for that information.

Here is the Registry we imported into Group Policy:

  • HKEY_LOCAL_MACHINEKey path SYSTEM\CurrentControlSet\Control\SecurityProviders
    Name: SecurityProviders
    Value Type: REG_SZ

    msapsspc.dll, schannel.dll, digest.dll, msnsspc.dll, credssp.dll

    Key path SYSTEM\CurrentControlSet\Control\Lsa
    Name: Security Packages
    Value type: REG_MULTI_SZ

Then we created a WMI Filter for XP Machines so that the Registry change only applied to XP Machines.  It wasn’t necessary to apply it to Vista or Windows 7, and I’ve learned to be careful when editing the Registry.

  • Namespace:  root\CIMV2
    Query:  Select * from Win32_OperatingSystem where Version = “5.1.2600”

What this didn’t fix:

Now users double-click the ACS Icon (RemoteApp), they see that it is starting a RemoteApp, then they get the login screen for ACS.  They are mostly happy with the above changes.

The first time a user uses the RemoteApp, they still get this screen.  We think it has to do with the domain not having a Certificate Authority.  We haven’t decided if it is worth all of the extra work.  I imagine we will pursue this in the future, but right now I have my team working on other things.  Basically, the User is instructed to check the box and click Connect.

When Windows Server 2008 was released they added this great feature in Remote Desktop Services (formerly Terminal Services) that allows you to use Remote Desktop Services to run behind an application or via web access.  The idea is that the end user just launches the application, which is really a connection back to a Remote Desktop Server.

Here is what made us look into this in the first place:

A couple of years ago we were launching CheckPoint (ACS People Suite’s check-in application) to all of our children’s and students’ areas.  The challenge was that we needed to run ACS over our Wifi network because the machines had to be portable.  The challenge we have is that ACS runs as fast as its slowest computer, due to file locking in a flat database and Wifi isn’t that fast to begin with.  We needed to be able to check-in hundreds of people in in 15 minutes.  Around that time, I went to a class taught by Ken Hicks at the ACS Convention where he talked about using Terminal Services to run ACS when you have a slow network.  Right then I SMSed my key volunteers and one replied that he knew how this should be done, which we started working on that weekend.

We upgraded our database server to Server 2008 and published a RemoteApp installer package and installed on all of the check-in workstations and it works like a charm!  I won’t post the install details here, because Jason M. Lee and Cisco Ospina have done a great job of that in their blogs and are both much smarter than I am.  The sweet thing about installing a little MSI package on a user’s computer is that it looks exactly like the application, instead of a little RDC icon and they don’t have to worry about the extra window of a Remote Desktop session (which does get confusing to some end users)!

Recent Server Upgrade:

Recently, we’ve upgraded our ACS server and migrated it to a VM (Virtual Machine) and it runs even better. A new challenge hit me as I was thinking about deployment.  What do you do with the old install on a workstation when you have a new one to push?

  1. The RemoteApp install has to be done per User.  I had a workaround for XP and Vista, but it really needs to be done Per User for it to function properly.
  2. The package is the same name, so it would be hard for the user to know which icon is the old one.

We are currently in the process of pushing the new installer package through Group Policy.  I learned that I can rename the RemoteApp package installer and the Icon (once installed).  For clarification, I indicated the server hostname in the installer and icon name.  This will make it easier to tell which ACS People Suite icon is the one the user needs to use.

To make those changes,

  1. Go into the Server Manager>Roles>RemoteApp Manager.
  2. If you have already added the Application to the manager,
    right-click and select Properties.
  3. The top field is what the Icon will show on the User’s desktop.
  4. The Alias field shows what the name of the .msi file will be.
  5. You can also do this at the time you add the Application with
    the wizard.  There is a Properties button in there to look for.

Publishing Quickbooks

We are growing in such a way that we needed Quickbooks to be more accessible to our staff and volunteers.  Some of the financial team needed to be able to share the application as well as have multiple people work on the Fixed Assets which live on one user’s local machine.  To resolve this, I installed it on a Remote Desktop Server.  Now all Quickbooks users have access to the Fixed Assets.  There are still some quirks to work out because Quickbooks likes more security holes open that typically a Remote Desktop Server doesn’t like.  The downside is that Quickbooks doesn’t support this version using this method.  I think they support the latest version.

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.