70-240 in 15 minutes a week: Software Distribution, Terminal Services, and IIS

Monday Apr 30th 2001 by ServerWatch Staff
Share:

Welcome to article number eleven in my 70-240 in 15 minutes a week series. This week's article covers Software Distribution, Terminal Services, and IIS. This includes a look at software installation via group policy, the basics of configuring terminal services, as well as an overview of setting up a web or FTP server using Windows 2000.

by Dan DiNicolo
http://www.win2000trainer.com

Welcome to article number 11 in my 70-240 in 15 minutes a week series. This week's article covers Software Distribution, Terminal Services, and IIS. This includes a look at software installation via group policy, the basics of configuring terminal services, as well as an overview of setting up a web or FTP server using Windows 2000. This article again ties into the Server portion of the series. 

The material to be covered in this article includes:

- Software Installation and Maintenance via Group Policy
- Installing and Configuring Terminal Services
- Internet Information Services 


Software Installation and Maintenance via Group Policy

A Window 2000 environment running Active Directory provides the ability to use group policy to distribute software to users and computers. This allows for the distribution of software at the site, domain, and organizational unit levels (the 3 levels within Active Directory to which group policy can be applied). Note that software can only be distributed to client systems running Windows 2000.

In a group policy object, the distribution of software is handled as part of both the computer and user sections, as shown below:

When distributing software, two options exist - assigning and publishing. Software can be assigned to both users and computers, but software can only be published to users. The difference between the distribution types is outlined below:

Assigning software to users: Doing this will distribute software to users, but will not actually install it on their system. When software is assigned to a user, it 'follows' them, or appears to be installed on every machine they log on to. In reality, only shortcuts appear on the programs menu. If they user clicks on the shortcut, then the application is actually installed on that system. Assigning software to users gives that user access to the applications they need, even if the system doesnt have the software already installed.

Assigning software to computers: This method actually installs the software assigned to the computer the next time the system is restarted, making it available to all users of the system.

Publishing software to users: This method adds the application to the Add/Remove programs section of control panel, allowing the user to install the application if necessary. It does not appear to be installed as software assigned to a user does. A published application can also be installed via document invocation. For example, if a user clicked on a zip file, WinZip would install if it had been published to the user.

When choosing to distribute an application via group policy, the application must be in a packaged format, an .msi file. Many new applications now ship with an msi file already included. An msi file includes instructions on how an application is to be installed, along with all system modifications it will make. If you wish to distribute an application that is not in .msi format, you can create your own msi by using WinInstall LE, a repackaging application included on the Windows 2000 CD. Essentially you use it to take a 'before' snapshot of the system configuration, then install the software, after which you take an 'after' snapshot. The differences are recorded, and the necessary files and .msi file are stored to whatever directory you have specified. This directory should be shared, and then chosen as the location of the application you wish to distribute via group policy. When software is distributed via group policy, the user does not need any special privileges (such as being an administrator) to install the software. Instead, the software is installed using the elevated privileges of group policy. Another benefit of software distributed using an msi file is its resilience - if the software becomes damaged in any way, it will go back to its source files and automatically fix itself the next time you try to run it (assuming the source files are still available, of course).

If an msi file does not exist or cannot be created, it is still possible to publish the software to a user using something called a .zap file. Basically this is a text file containing the instructions necessary to install the software. The downside of this method is that the installation of the software requires that the user have an appropriate level of access to install software on the system - it will not install under the elevated privileges of group policy. Note that a .zap file is only used for publishing, and only to users (since you cant publish software to a computer, remember!). For a look at a zap file, click here.

When you choose to distribute a piece of software via group policy, you will be presented with the screen shown below:

The path to the package should be provided in a manner that will allow network clients to connect, for example the UNC path to the .msi file location. The screen shot below outlines a package that will be assigned to users in a domain:

An important note with respect to distributing software via group policy - be careful with respect to how you apply policy for the purpose of software distribution. If the above example were assigning software to all users in a domain, every installation would obtain the package from the \\laptop server, even those in other physical sites. A better practice is to design for the assignment and publishing of software such that a local package is used and unnecessary WAN traffic is avoided. 

You can also control what happens to software once a package is removed from group policy, as shown below:

Terminal Services

Windows 2000 Server includes terminal services for the purpose of remote administration of servers as well as the ability to provide centralized access to software and the Windows 2000 desktop. Not installed by default, terminal services provides an environment that is often referred to as 'thin client'. In this environment (also provided by third-party products such as Citrix Metaframe), only screen-shots, keyboard strokes, and mouse movements are passed between the server and the client. All processing actually takes place on the server, which greatly reduces the computing requirements on the client side. As such, even Intel 386 running Windows 3.11 can provide users with access to the Windows 2000 environment and associated applications. Terminal services uses the Remote Desktop Protocol (RDP) to pass data between the terminal service client and server.

Terminal services is installed via the Windows Components Wizard. After choosing to install terminal services, you will be prompted to choose between the two possible install modes, as shown below:

Remote administration mode allows 2 simultaneous terminal services connections for the purpose of remote administration and requires no additional licensing. Application server mode is provided for the purpose of allowing regular users to run applications in Windows 2000. In this mode, a terminal services licensing server much also exist (a 90-day grace period is provided), since every terminal client connection will require a terminal service CAL. Note that Windows 2000 Professional systems do not require an additional CAL to access the terminal server, but other operating systems do.

Once terminal services has been installed, the next step is to install the client software on systems that you wish to be able to connect. By default, the client software is found in the %systemroot%\system32\clients\tsclient folder. This folder can be shared, which would allow you to install the client over the network (it is not shared by default). Alternatively, Windows 2000 includes an administrative tool called the Terminal Service Client Creator, which will create a set of floppy disks containing the client software, as shown below:

The 16-bit version requires 4 disks, while the 32-bit version requires 2. Once the client software is installed, the user will use the terminal service client to access the server. The client will display a list of accessible terminal servers in the domain or workgroup, allowing the user to specify a server, as well as the screen resolution, and so forth, as shown below:

The option to compress data is selected by default, while the option to cache bitmaps to disk is not, but will speed up performance by reducing the amount of data passed over the connection. After the client chooses a server from the list, they will be prompted to log on, just as if they were sitting at a Windows 2000-based system, except that it all happens from within a program window. Once logged on, their session appears with a window, as shown below:

By default, all domain users have the ability to log on to a terminal server. However, it is possible to control who can and cannot, via a the terminal services profile tab, as shown below:

Note a few important points here beyond the 'allow logon to terminal server' checkbox. The User Profile section allows you to provide individual profiles to users. If you choose not to, all users will use the same profile, and will be subject to any additions or deletions made by other users. Also, you might consider providing the users with a home directory which is mapped automatically when the log on to the terminal server, since users may not be logging on from Windows 2000-based systems.

Since clients are creating a session with the terminal server, it is also possible to control what happens when a session is left idle or disconnected, since sessions will use up server resources. The session tab on a user account controls settings for a given user. These user settings can be overridden at the server level if necessary.

Note that there is a different between disconnecting and ending a session. When disconnected, a session is still running on the server and can be reconnected later. When ended, the session is removed from the server completely. To disconnect a session, the user simply needs to close the session window. To end a session, the user should choose to log off as if they were sitting at an actual Windows 2000 client.

Windows 2000 terminal services also provides the ability to remote control user sessions, but only terminal service sessions. As such, an administration can remotely take control of a user's terminal session, in order to help the user through a task or something similar. Note from the screen below, by default remote control is enabled, but requires the user's permission to access a session:

The actual management of all sessions is handled via the Terminal Services Manager administrative tool, which allows you to send console messages, disconnect sessions, view connected users, and view process activity.

When exploring terminal services, it is also important to note that not all applications will function correctly in this simultaneous multi-user environment. As such, for some applications you will be required to first run an application compatibility script in order for it to function correctly. A number of these scripts are provided, and can be found in the %systemroot%\Application Compatibility Scripts\Install folder. Another note - when installing applications on a terminal server, you should be sure to use Add/Remove programs in control panel, since this will ensure that the application is installed for all users. However, when installing items that cannot be installed in this manner (such as a web browser plug-in), you will need to run the change user command. To do this:

- Run the command change user /install prior to installation
- Install the application
- Run the command change user /execute after the installation

This will ensure that the program is available to all users. Add/Remove programs runs both commands automatically.


Internet Information Services

For the Windows 2000 Server exam you are required to be familiar with the essentials of IIS 5.0, which is installed by default on a new Windows 2000 Server installation, and upgrades systems with IIS 4.0. The two main features of IIS remain its functionality as both a web and ftp server, which we'll concentrate on here. Note that many other services do exist under IIS, including the ability to act as an SMTP (mail), NNTP (news), or streaming media server.

After IIS 5.0 is installed, two new user accounts are created by default, and placed in the Users container. One, called IUSR_computername, is provided for the purpose of allowing anonymous access to the IIS-based system. The other is called IWAM_computername, and is the account under which IIS runs. This is used to start scripting applications, for example. 

IIS will also create a folder called Inetpub on the IIS system, and subdirectories of this folder provide the working roots for installed services. For example, wwwroot is the location of the default website, while ftproot houses the root directory for ftp connections. While these directories are used by default, others can be created and placed in different folders or partitions if this better meets your needs. It is usually best, however, to keep everything situated in a single location in order to simplify the administrative process.

IIS services are managed using the Internet Services Manager tool. You can access the master property sheet for a server by right-clicking the server and choosing properties. Settings set on the master property sheets for the WWW or FTP services will be inherited by all new sites you create. As shown below, the master properties allow you to control settings such as the amount of bandwidth dedicated to each server, registered MIME file types, and server extensions, which includes server usage optimization. The master property sheet for WWW is shown below:

Configuring a website on IIS can be done either by editing the default web site or by creating a new site altogether. A single IIS server is capable of supporting many web sites, and differentiating them in a number of ways. The first is via port number. By default, a web server responds on port 80, although this can be changed. If you only had a single IP address, you could host multiple web sites by assigning each a different port number. Second, you can use host headers. In this scenario, a web site is identified by its host header name, which matches the domain name used to access it. In the third scenario, a server is assigned multiple IP addresses, and each site simply uses a different address. To create a new WWW or FTP site, simply right-click the server name and choose to create a new site, a wizard will walk you through the basic creation process. The majority of the properties must still be configured by accessing the properties of the site itself. The screen shot below shows the many tabs that can be configured for a web site:

An explanation of the tabs is listed below:

Web Site - basic identification information about the site including the port number, IP address, description, logging type, and connection information.
Operators - controls which users have operator privileges for the site, allowing them administrative control over many properties of the site.
Performance - allows the website to be tuned for expected hits, as well as bandwidth and CPU throttling for the site to be configured.
ISAPI filters - allows you to configure settings relating to isapi filters and their processing order.
Home Directory - specifies which directory on the server acts as the root directory for this site, sets permissions and application properties.
Documents - defines default document to be loaded when a request is sent to the server. You can specify alternative documents, as well as change the order of search.
Directory Security - controls site authentication, IP address and domain name restrictions, and the configuration of certificates.
HTTP Headers - allows you to set content expiration, custom http headers, set content ratings (like RSAC ratings), and configure additional MIME types.
Custom Errors - allows you to edit or define custom error pages - for example you could create your own, including your logo.
Server Extensions - allow you to use version control, set server performance, set client scripting and properties relating to inheritance of security settings.

As you may have noticed, for a website you are able to set basic permissions that will apply to all users who connect to the site. However, you should also note that all resources may also be protected by NTFS permissions, and this allows you a more granular level of control, if required. For example, a user who has the NTFS permission Deny Read for a folder will not be able to view files in that folder, even if accessing the resources via the web server which allows Read to the directory. 

Internet Information Services allows a number of different authentication options, depending upon the type of usage required for the server. The screen shot below outlines the choices available. Note that by default, anonymous access and Integrated Windows authentication are selected.

Anonymous access - this option does not require the user to provide credentials to access the resource.
Basic authentication - password is sent as clear text. Some browsers (like Netscape Navigator) do not support integrated windows authentication, necessitating this option.
Digest authentication - a challenge/response system that does not pass unencrypted passwords between the client and server. 
Integrated Windows authentication - formerly called NTLM, uses the credentials of the currently logged-on user. 

Both FTP and WWW sites can control access via IP address, while a WWW site can also control access via domain name. This allows you to control either who does not (common) or does (less common) have access to the given site. This would allow you to block connections from a given domain or certain IP address, or limit access to only a selected group or person in the same manner. The screen shot below shows an example of a site that allows access to everyone, except for users from a certain subnet.

Note that you should know how to designate an entire subnet in one of these lists - that will require knowledge of subnetting, which you can review from article 7 in the series.

It is also important that you be familiar with some of the more common TCP and UDP port numbers for the exam. Some of the most common and their related services are listed in below:

FTP - TCP port 21 (control, data travels over TCP port 20)
Telnet - TCP port 23
SMTP - TCP port 25
DNS - TCP and UDP port 53
HTTP - TCP port 80
LDAP - TCP port 389
HTTPS - TCP port 443


The properties for an FTP server appear similar to those for a web server, although there are fewer property sheets. By default, a connection to an FTP server is initiated via a connection to port 21 on the server, though again this can be changed. A single IIS server can most multiple FTP sites, either by each using a separate IP address, or by assigning each a different port. The property sheet for the default FTP site is shown below:

An explanation of each of the tabs is listed below:

FTP Site - contains basic information about the site including IP address, port, connection, and logging settings.
Security Accounts - controls the ability to allow anonymous connections, as well as the ability to grant site operator privileges.
Messages - allows you to set the messages that will appear to uses when they connect, disconnect, or the maximum number of simultaneous users has been exceeded.
Home Directory - allows you to specify the home directory location on the server and the directory listing style.
Directory Security - allows you to specify which computers are granted or denied access to the FTP site according to IP address or subnet address.

And yet another week of your studies completed! Next week we'll finish the Windows 2000 Server portion of the series with a look at the various odds and ends that are left and didn't necessarily fit well anywhere else. Thanks to all who have been following the series and have contacted me - you have really helped to keep me motivated. As usual, I look forward to your questions, comments, and feedback. I hope you'll also visit my message board if you have any questions while studying. My preference is that all study-related questions be posted there for the benefit of others, who may also have the same question. Good luck with your studies this week - we're almost half way there!

Dan

Share:
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved