WORKSHOPS

Centralized Control Of A Common Desktop

by Kiran Movva

You knew you should have stayed in bed today. The newspaper wasn't delivered on time. You walk into your office, the monitor is full of Post-Its from your users and the message light on your phone was blinking furiously. Users are complaining that NetManage's 3270 application for mainframe access is not working. They're getting a lightning symbol at the bottom of their screen. Where can you turn?

After a week of troubleshooting the network, network drivers and the application, you've finally realized that it's a conflict with CTL3DV2.DLL. You had just installed Symantec's Norton Administrator for Networks 1.5 the week before. The software distribution agent executed for all users via the RUN line in SYSTEM.INI was automatically loading an older CTL3DV2 DLL it found in the Window's working directory. NetManage's 3270 program required a newer one, producing an odd symptom of lost host connectivity.

Does this sound familiar to you? One way to reduce the potential conflicts that can occur on a desktop is to establish and enforce a common desktop for all your users. We'll examine the issues behind having a common desktop and some of the techniques you can use to accomplish just that.

The Good News About Common Desktops Very often, a newly installed application will replace modules on your system--sometimes with newer modules and sometimes with older ones. This replacement can cause conflicts between your applications. These conflicts may even show up based on the order in which you execute applications. Since common DLLs may still be resident in memory after you exit an application, the next application executed simply will make calls to the required DLL in memory. A common desktop can assist you in maintaining a standard list of modules and the correct revision that works with all other "certified" applications.

Another area that can lead to problems is users who make changes to their systems. They may occur due to a user-installed application or deliberate editing of system configuration files. Tools that can be part of the common desktop can track changes and allow an administrator to back out any changes that led to the instability.

Since most LANs nowadays serve centralized applications, locally installed applications have a great potential to break the entire functionality of the desktop. A common source of integrated DLLs maintained by the LAN Administrator does not preclude the user from installing a local application, which may place a conflicting DLL in the Windows System directory. If this DLL is found first (after a search of the application's launch and working directories), it can cause a pote ntial conflict with your network applications. Compliance auditing can be made part of the common desktop tool set to enforce correct revision levels on the desktop.

What's the Bad News? Development and maintenance of a common desktop can be tedious. It requires a coordinated control of desktop changes. Deployment of new applications will be slow because the LAN administrator has to "certify" and integrate applications into a common set of DLLs and other modules. The integration of a newer application includes careful testing of older applications to make sure new modules have not broken anything that was working. You get the picture?

Another area of concern is user buy-in: If your users don't like it, they'll never use it. We've found a number of things to help you get user buy-in. Managing users' expectations of how new services will look, and what wi ll be provided is central to the success of such efforts. First, it's important to gather input from your users on th e design of the common desktop, after all they will be using it day in and day out. Do yourself a favor: Let your users pick the look and feel of the desktop they'll use.

Second, be sure to audit all applications that reside on the server and, where possible, on your users' desktops. You'll save hours of troubleshooting when conflicts arise. Third, decide whether you'll format users' hard drives and install the common desktop or you'll integrate the common desktop into their existing desktops. It's far easier to perform clean installs, although to get the required buy-in is more difficult.

Along with your users, you will need to decide which of the applications will reside on the server and which will be local. You even may decide which applications can be eliminated due to lack of licenses, lack of business need and so on. Now that you have an idea of the common desktop you'd like to design and the applications your users want, it's time to build a pilot desktop.

How Do I Do It? You need to decide if you want to base your desktop architecture on Windows off the network (Networked Windows), or locally installed Windows (Local Windows). To weigh the alternatives, take a look at "The Pros and Cons of Local and Networked Windows" below. If you're using Windows95, you can utilize System Policies and tools such as Symantec's Norton Menu or McAffee's NetTools to achieve the same level of desktop control as with Networked Windows.

Once you've decided on the location of Windows, you can begin building the desktop. For each application you plan to centralize, determine how it changes your desktop. For example, what DLLs has the application setup copied to the desktop? Tools, such as On Demand's WinInstall, offer an excellent before and after desktop image comparison.

As each application installs, watch for duplicate DLLs. Track their versions a nd test each application with the latest DLL revision. Some problems, such as those related to OLE opera tions, may not appear immediately. This testing phase is one of the most critical steps in the process. While testing, remember the order in which a Windows application searches for its modules: launch directory of application, working directory of application, Windows directory, Windows System directory and search path directories.

In most cases, we found that you should either delete core DLLs from each application's working directory or overwrite DLLs in the application working directory with the latest versions found while installing applications one at a time. For example, if Word 6.0c requires CTL3DV2 and OLE2 DLL, located in APP\ WINWORD, you should replace them with newer versions installed with your other applications.

At the end of this long process, you should have an integrated set of DLLs and applications. On the "clean" PC, set the desktop look and feel. You can also standardize on configuration file formats (config.sys, autoexec.bat and INI files), including comm ents where needed. Decide if you will be locking groups on the desktop. If you use Windows95, make sure you implement System Policies to achieve maximum flexibility in desktop control. To wrap it up, gather all these tested files into one desktop image.

For a Networked Windows desktop, the resulting files may be copied to the common Windows directory on the server, and the required configuration files (INI, registry and so on) can be copied to each of the users' personal Windows directories. For a local Windows desktop, the image can be downloaded to the users' hard drives. In the case of a Windows95 desktop, WinInstall may also be used to distribute applications. If you already have implemented Microsoft Systems Management Server (SMS), you can use the PDF and MIF files from WinInstall to set up applications.

How You Maintain the Common Desktop We found two operations that can assist you in maintaining the integrity of the common desktop. First, control the application versio ns and their modules. By using the technique described above, test new applications before allowing local installations or integration into the LAN-based applications.

Second, we found that performing periodic compliance checks is a necessity. Using tools such as Symantec's Norton Administrator for Networks (NAN), schedule a periodic check of all desktops against your common baseline of integrated modules. We ran a compliance check for the CTL3DV2.DLL and used the NAN script found below. Be sure to change source and target directories accordingly. You can achieve similar functionality using Microsoft's SMS, but not until version 1.2.

What Other Tools Can Help? Maintenance of the common desktop requires the use of a software distribution product. One benefit of the common desktop is that you can "assume" many elements of the user's PC. The standard AUTOEXEC.BAT, Program Group names under Windows and icon properties for integrated applications, to name a few, all are kno wn and thus will help you distribute changes and enhancements efficiently via software distribution.

WinInstall from On Demand does just that. Its features are well suited to sites with Microsoft's SMS. WinInstall snaps into SMS and forms application installation routines in SMS' PDF format. But all is not roses; currently WinInstall's lacks error checking, logging and contingency recovery.

Tools that provide the ability to take over a LAN user's desktop are also essential. This type of remote control, along with other features, will help you to provide superior levels of support.

The common desktop will help solve many PC network client problems that you see on your LAN today. Application conflicts, change management and contingency recovery all become easier to resolve. Make no mistake, this control does take more effort on your part to run the operation. But organizations who have deployed a co mmon desktop are seeing quantifiable benefits with reduced support costs and hig her productivity.

Kiran Movva is a systems analyst at a major energy corporation on the West Coast. He can be reached at kmovva@nwc.com.

Norton Administrator For Networks Script

sub main



'Source is the Baseline modules directory on the server(ImageWinDir)



'Target is the user's Windows source directory(WinDir)



ImageWinSysDir$="K:\IMAGE\WINDOWS\SYSTEM\"



WinSysDir$="C:\WINDOWS\SYSTEM\"



'For each file, you will duplicate the following code, simply changing the
file name in the line below



file$="CTL3DV2.DLL"



exist% = FileExists(WinSysDir+file)



if exist then



'Get file date and time of the two copies being tested



SDateAndTime# = FileDateTime(ImageWinSysDir+file)



TDateAndTime# = FileDateTime(WinSysDir+file)



'Get file length of the two copies being tested



SFileLength&= FileLen(ImageWinSysDir+file)



TFileLength&= FileLen(WinSysDir+file)



'if date, time or
 length is different then copy our baseline from server



if (SDateAndTime# > TDateAndTime#) OR (SFileLength&> TFileLength&amp)
then



FileCopy ImageWinSysDir+file, WinSysDir+file, FALSE



end if



end if



end sub