Latest Entries »


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.

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.

Hello world!


Hi there!  This is my first blog post.  Though several of you have asked where my blog is, I can’t promise there will be anything interested to say.  Sometimes you may see things posted here that even I don’t understand.  I’ll try to spell out acronyms and if I leave you hanging, please comment so I can clear that up.  Otherwise, happy reading!