Developer

Easily access system resources

The .NET Framework centralizes access to system resources in the System libraries to give developers better local and remote access. Tight integration with Active Directory keeps your system management apps secure.


The design of the .NET Framework goes a long way toward removing one of developers' biggest complaints about the Windows and COM architecture. For the first time, access to all system resources has been largely centralized in the System libraries. Developers can now create system management applications that can be used not only to manage the resources of a specific application but also for generic operations management tasks. In this article, I’ll describe the types of applications that .NET enables and then discuss some general guidelines you should use when architecting system management applications.

Local system management
Although the industry went through a phase in which it looked like every PC might be replaced by a “smart” terminal running thin client applications, that trend has leveled off. Organizations now see that some applications need the rich capabilities of local processors and storage. This means that developers need to be able to manipulate the local machine’s resources effectively.

Microsoft exposed the underlying file system in .NET by providing a set of objects and classes in the System.IO namespace. For example, System.IO provides the Directory and DirectoryInfo class. The Directory class has static methods you can call without first creating an instance. These methods, such as GetLogicalDrives, GetCurrentDirectory, and GetDirectories, give you direct access to the file system on the local machine. The DirectoryInfo class provides folder-level information about any directory on the local machine. These and other classes in System.IO give you the ability to create dedicated storage management applications or to add storage management features to new applications.

Remote system management
Although it’s interesting to be able to manipulate services running on the local machine, it’s more valuable to provide management capabilities remotely. The .NET Framework provides standard methods for developing system management applications and accessing those features remotely. As more companies implement Active Directory Services (AD) in Microsoft Windows 2000 and the upcoming Windows .NET Server, they’re also looking for ways to effectively manage the directory. Before .NET, that meant wading through extensive documentation covering the Active Directory Services Interface (ADSI). You needed a thorough understanding of developing LDAP queries in order to use ADSI effectively. In the .NET System.DirectoryServices Namespace, Microsoft provides all of the functions necessary to effectively manage AD. The DirectoryEntry object represents all of a user’s settings, and any .NET language can manipulate it with ease.

Other classes let you create and control AD groups. The .NET Framework exposes almost all of the necessary functionality you need to create departmental or application-specific AD management applications. In some cases, you’ll still need to make direct calls to the underlying Windows system, but these are rare—version 2 of the Framework should fix them.

All Microsoft systems products (SQL Server, Exchange, etc.) and many third-party products provide Windows Management Instrumentation (WMI) that developers can use to manage and control them. Unfortunately, prior versions of the WMI libraries were not fully accessible to anyone but hard-core C++ developers. The System.Management namespace unifies and simplifies access to the underlying WMI libraries, giving developers the ability to create management applications simply and quickly. Sample WMI applications include analysis applications that store information about business activity, health-monitoring applications that can take corrective action automatically if systems are at or near failure, and operational policy management applications that manage backups or provide automated machine management according to specific operational guidelines.

Another great new feature of the .NET Framework is the ease with which you can develop Windows Services applications. Moreover, the .NET Framework exposes Windows Services controllers that allow you to develop applications that not only manage the services and service dependencies for your own Windows Services, but also for existing Windows Services on the machine. It's fairly easy to develop a Windows Services management console that lets you monitor and control Windows Services on the local machine or any machine in your local network.

Exposing system management applications
It may be easy to manage machines on your network, but what about applications that aren’t on your local network? Using Web Services, you can expose many of these system-level services to remote management using Web clients. For example, I worked with a hosting company to design a set of system management applications that let their engineers diagnose, repair, and restart systems remotely with a cellular phone using a combination of Web services, system objects, and the Mobile Internet Toolkit. Of course, this brings up another issue of major concern—security.

Design guidelines
In order to create secure applications that perform well, you should design system management applications using a multilayered approach. First, create objects that perform the core system management tasks as COM+ components that inherit from System.EnterpriseServices. Sign these components and place them in the GAC before adding them to COM+ packages with the security necessary to perform only the tasks they are designed to perform. When you give the components an ID to impersonate, it's important not to use the standard Administrator account, but instead create unique individual accounts that expose the necessary permissions. Give the accounts names that make them easy to find and disable (if necessary), like RemoteSysAdminServices or RemoteSysAdminWMI. After installing the components in COM+ Packages, you can grant access to these packages to groups of users like Operators, PowerUsers, and Administrators. Using Active Directory as your source for credential verification lets you expose the objects through Web services or Web sites while still using the same credentialing source, since ASP.NET authentication and authorization can use Windows authentication.

The ability to develop system management applications quickly is one of the best new features of the .NET Framework. The .NET Framework’s tight integration with AD allows you to make sure that the system management applications are exposed only to the right people or systems.

Editor's Picks