Why to Keep Software Up to Date


There are a number of additional components available for purchase from various organizations that claim to help you manage your Active Directory environment. I must admit, many of them look quite intriguing, however, I find it hard to do a justification for such tools when many of them could be developed in house for the same cost or less. That being said, I’ve been working on a web based Active Directory Management tool for the past few weeks.

The reason for this is that there is an outstanding issue with a number of administrative workstations we have. Our organization was not on the cutting edge when it came to doing software updates to things like Novell Zenworks: As a result we were still using Zenworks 2 when Zenworks 10 came out. This created all sorts of issues because the product had so dramatically changed over the years. Rather than the components being integrated with the Novell Client, Novell decided to make a separate Zenworks agent that is also installed on the machine. This allowed for the use of Zenworks in an environment that had no Novell clients installed with the use of a middle tier server. The issue was, however, that a number of components, specifically Dynamic Local User, did not work once we installed newer Novell Clients beginning with 4.91. The “Workstation Manager” component was removed, and the Zenworks 2 Dynamic Local User packages stopped working.

We discovered, however, that if we installed a 4.90 client, then used the client’s built in upgrade functionality to 4.91 that we maintained enough functionality for Dynamic Local User to function. Other Zenworks pieces required us to create a batch file to replace some DLLs with older versions so delivered applications would work (and that was troublesome in itself). All of these back-door kludges took a toll over the long run though: We could no longer depend on Zenworks 2 for delivered applications and its Dynamic Local User features were crippled and only partially functioning.

Fast forward a few years after all of this went into place. After our Windows NT to Windows 2000 upgrade, I installed the Windows Administration Tools (adminpak.msi) for Windows XP. Everything seemed peachy, until I noticed certain things did not work. When attempting to reset a password, for example, an ambiguous error “File not found” would occur. This was very strange since a very careful examination of Process Monitor showed conclusively that there were no files that were not found when this command executed! We eventually put in a case with Novell. After a few months of their engineers looking at it they could not find a way to reverse the problem. Removing the client, reinstalling, removing the newer client and installing the old one then uninstalling – nothing worked. You name it we tried it. It was at that point I decided the only way to fix the problem was to re-install Windows completely (and not just a repair install, because that did not work).

Being as we have a number of administrators who have no desire (or time) to reformat their machines to preform the most basic task of resetting a password, and rather than have everyone terminal into a server and pay licensing for that, we decided that I would make a web based application.

Based on .NET 3.5, I began using System.DirectoryServices.AccountManagement for basic things like password resets, user account provisioning, and computer accounts. Now the application is growing and I’ve resorted to using just System.DirectoryServices for a number of tasks that aren’t available in AM.

The lesson to be learned from all of this is that it is important to keep each and every component in your environment up to date. Part of the reasons Zenworks fell so far behind was political – other projects became higher priorities due to the squeaky wheel, and part of it was fear of change and the unknown among some people who would have to support it. But the fact of the matter is that hundreds of hours of troubleshooting time (possibly thousands, if you could how we could have leveraged it on other projects) went into fixing the issues with Zenworks 2, rather than just upgrading.

People have looked at me as if I were a crazy man for recommending Windows Server 2008 as much as I have. Don’t get me wrong – Server 2003 is fantastic – but 2008 builds on a solid foundation that will set us on the path for quite possibly the next decade. Why would we, who usually transition slowly, go to 2003 rather than 2008 first, knowing that 2003 will be out of support in just a few short years? That is inviting additional work. Server 2008 has proven robust and dependable in the short time we’ve used it and until I am given reason not to trust it, I will continue to recommend a transition to Server 2008.

Leave a Reply