Networked File Systems and Application Servers

UNIX applications are often stored on an application server, and their executable files are accessed from the client using NFS mounts. This greatly simplifies the deployment of applications, because they need to be deployed to only one server (the application server).

If your migrated application continues to use application servers, there are issues that affect both Win32 and Interix implementations . The main issues arise due to differences in the ways the UNIX and Windows networked file systems operate .The next two sections describe how you should address these issues for Win32-and Interix-based applications.

Migration to the Windows platform gives you an opportunity to reevaluate whether to continue using application servers. Your evaluation should take into account network bandwidth requirements and the proximity of network shares.

You should deploy any Win32-based application by using the Windows Installer service, whether or not it is to be located on an application server. This may entail as little as placing a shortcut on the user s desktop, although most applications require at least some skeletal installation to accommodate Component Object Model (COM) or DCOM component registration, user preference settings, and building local configuration files. Creating .msi installation packages enables an enterprise to maintain a consistent technology, use Group Policy-based deployment, and enjoy wide support by other tool vendors . Also, consider that most applications will enjoy increased performance and reliability when executed from local drives .

Server-Based Win32 Applications

For applications that were executed from a UNIX file server by using a symbolic link on the client, there are a couple of difficulties resulting from the migration to Win32:

• Local desktop references in Win32-based applications

  Windows-based applications often use local references to DLLs, configuration files, the Windows registry, and COM components . This is solved by locally installing the required DLLs, configuration files, registry changes, and COM components on each desktop.

• Differences between NFS and CIFS

  The Common Internet File System (CIFS) file access protocol behaves differently in network or server failure scenarios than does the NFS protocol that is commonly used in UNIX systems. The solution to this problem is described in the restof this section.

This section will discuss the use of processes and technologies, including Windows Client Side Caching, Windows Installer service, and others to mitigate the issues in coordinating the deployment of very large applications across the enterprise. Thisis not meant to be an exhaustive discussion of these technologies but rather to concentrate on the case where the application is very large (both in size on diskas well as the number of files) and a large user base must be able to use a newly deployed or upgraded version quickly.

One of the challenges faced in migrating from UNIX to Win32 is that CIFS is a stateful protocol maintaining a session between the client computer and the file server. NFS, on the other hand, is stateless. This means that NFS is unaffected bya NFS server becoming unavailable on the network. In this situation, an NFS client will wait and retry the service periodically until the NFS server reappears.

The operating system and many UNIX applications are unaware of the loss of an NFS server and will continue to wait (even in the middle of a function call to a distant library file) until the connection returns or the user terminates the client process. CIFS, on the other hand, will raise an error if a server or a network anomaly makesa file share unavailable. Many applications that have been ported to the Windows platform have not allowed for this fact and do not perform adequate error trapping. You can use Microsoft Client-Side-Caching (CSC) in Automatic Caching for Programs mode to overcome this issue.

Client Side Caching and Server-Based Win32 Applications

Using caching to overcome network and server failure requires the use of Windows 2000 Server or Advanced Server network shares that support the Automatic Caching for Programs mode. This capability is a property of the Windows Server-side share. In some situations, the applications will reside on servers running Windows 2000 (even domain controllers), while shared user data may still be stored on UNIX file servers. This is fine because the advantages of caching that assists in serving application binaries may actually be undesirable for shared data files due to concurrency issues.

When a Windows 2000 server share has its Caching Settings property set to Automatic Caching for Programs , the Windows 2000 client will be directed to cache every file designated for caching that is opened for execution. After a file has been cached, the client will check on subsequent file open requests to see if either the local or the server version of the file has changed. If neither has changed, the client will open the local copy without further contact with the server. This methodology hides CIFS errors or warnings from the application. There is an assumption that the application performs standard error checking routines around any call to load a file (such as a .dll file) prior to invoking any of its members . If that file has not been called upon previously in the current session or has not been precached, the chance of an unchecked error exists.

Client-Side Caching and Administrative Pinning

An adjunct technology to Automatic Caching is a client-side policy setting called Administrative Pinning. This policy, implemented through Active Directory Group Policy, ensures that files that must be available to the client computer are pinned in the client s file cache.

The term pinned refers to a capability known as Automatic Caching for Programs. This provides offline access to shared folders containing files that are not to be changed. This caching option is used for files that are run or accessed for read-only. This greatly reduces network traffic and network timeouts because these pinned files are opened directly, without accessing their network version.

In this way, the executable files and DLLs that are critical to the application canbe prepopulated and are never removed from the cache to make room in the allotted cache space for more recently accessed files.

After a file is pinned, no recaching is necessary for files that do not change (for example, binary executable files). If a file changes on the server, CSC will automatically get the new copy and keep it pinned. Thus pinning is a one-time action.

– To implement Administrative Pinning:

1. Start the Group Policy Editor. On the Start menu click Run , then in the Open dialog box, type gpedit.msc , and then click OK .

   You will see the Group Policy Editor window as shown in Figure 13.1.

2. In the Explorer window, click Computer Configuration , click Administrative Templates , click Network , and then click Offline Files .

   This is illustrated in Figure 13.1.

3. In the Offline Files dialog box, double-click Administratively assigned offline files .

4. In the Administratively assigned offline files dialog box, on the Setting tab, select Enabled . Then click Show under Files and Folders .

5. In the Show Contents dialog box, click Add .

6. In the Add Item dialog box, under Enter the name of the item to be added ,enter a name for this file or folder. Under Enter the value of the item to be added , enter the fully qualified Universal Naming Convention (UNC) of yourfile or folder, and then click OK .

   Embedded environment strings are allowed as part of the UNC file path .

7. In the Explorer window, click User Configuration , click AdministrativeTemplates , click Network , and then click Offline Files .

8. In the Offline Files dialog box, double-click Administratively assigned offline files .

9. In the Administratively assigned offline files dialog box, on the Setting tab, select Enabled . Then click Show under Files and Folders .

10. In the Show Contents dialog box, click Add

11. In the Add Item dialog box, under Enter the name of the item to be added ,enter a name for this file or folder. Under Enter the value of the item to be added , enter the fully qualified Universal Naming Convention (UNC) of yourfile or folder, and then click OK .

Embedded environment strings are allowed as part of the UNC file path.See Figure 13.1.

The Computer and User policies are merged at run time to pin the union of the files specified in both settings. Whenever this policy is applied, the client will pin every file listed. If an entry is a folder, the folder s contents will be pinned recursively. This processing is performed in the explorer.exe process on a background thread at IDLE priority level. It s best that a subsequent synchronization occurs to ensure the pinned files are complete in the local cache. The typical synchronization at logoff is sufficient for this. In Microsoft Windows XP, this has changed so that the files are synchronized to the local cache at the time they are pinned. Some thought and testing needs to be put into which and how many of the application s files should be administratively pinned.

Figure 13.1: The Group Policy Editor and administratively assigned offline files

The system inspects several parameters when determining whether a file needs tobe synchronized. Modified date is the most obvious parameter used. In addition, ifa file has been modified on the client while offline, the CSC database sets a bit on that file indicating that it has been changed, and this bit is inspected as well during synchronization. There is no byte-by-byte comparison involved.

Performance Considerations with Client-Side Caching

To synchronize files, the files must be placed in the local cache. As the numberof files in the cache increases , synchronization slows. Large numbers of cachedfiles will also affect the lookup speed for any given file.

If the user has enabled the Synchronize all offline files before logging off option, any directory being synchronized is scanned on the network so that any new files that have been created on the server since the last synchronization are pinned. If the user has many directories pinned, and those directories contain many files, this can take some time.

CSC attempts to dynamically reconnect after a network or server failure if no cached files have been modified while offline and the client has no files open from that share.

Server-Based Interix Applications

For applications that were executed from a UNIX NFS file server, often using automount and NIS maps on the client, the transition to the Windows platformand Interix result in a couple of difficulties:

• Interix does not support dynamic mounts or automount NIS maps.

• As with Win32-based applications discussed earlier, the CIFS file access protocol behaves differently in network or server failure scenarios than does the NFS protocol that is common in UNIX systems.

Generally it is not recommended to serve Interix application binaries from a file server, but when this is required, the use of static (nonautomounted) NFS file shares is the recommended approach. If static file shares are unacceptable, then use of the Microsoft Distributed File System (DFS) should be considered .

Replacing Automount with Microsoft Distributed File System

If Interix ported applications are to be served from the same set of NFS file servers as the original UNIX application, you can meet the need for automounting in Interix by using the Microsoft Distributed File System (DFS).

Note  

Microsoft DFS is not the same as the Open Systems Foundation s Distributed File System (DFS).

DFS allows system administrators to make it easier for users and applications to access and manage files that are physically distributed across a network. With DFS, directories and files distributed across multiple servers appear as if they reside in one place on the network. DFS acts as a network-based file system with a single root directory. End users have no need to know or to specify the actual physical location of files to access them.

DFS includes both server-based and client-based DFS components. For more information about DFS components, see Understanding the Distributed File System (DFS ) and Using the Distributed File System (DFS) in Windows 2000 Server online Help.

– To set up the Interix user environment to look like the UNIX automounted environment

1. Create DFS links to NFS shares as defined in UNIX NIS domain automount maps. (See the following procedure.)

2. Use Interix to create symbolic links to the top-level DFS links (for example, apps, data, home, scratch, and so on).

3. Change the local shell startup scripts (C and Korn Shell) to use the links.

This solution has the advantage of being a single point of administration for both the NIS automount maps and the DFS import script. The only portion of this procedure that needs to be performed on a Windows 2000 DFS Server is the use of the DFSUTIL command-line application to import the DFS configuration information to generate DFS links.

– To create the DFS links from NIS automount maps

1. First, run a ypcat on each NIS automount map to generate text output of theNIS map.

2. UNIX text manipulation utilities are run to create a text file in the format needed for the import function of the DFSUTIL utility.

3. The import text file is copied to the Windows 2000 Server.

4. DFSUTIL is run to create the DFS links.

This process is shown in Figure 13.2.

Figure 13.2: How to convert automounts to Windows DFS

The Windows workstation uses the information in the DFS links to mount the appropriate application image environment for each user with NFS shares on UNIX. This process can take place using a script run when each user logs on. You will find a script that will simulate automounting in Using DFS to Automount in Interix later in this chapter.