When sendmail is run as non-set-user-id root, it is run either as root when it is invoked by the root user, or as another user when it should not run as root. The sendmail distribution clearly cannot divine ahead of time what user you wish to use when not running sendmail as root. It could have chosen nobody, for example, but the user nobody does not exist under all versions of Unix.

You can choose your own username by using the confMSPQOWN build macro to place a line such as this into your build m4 file:

 define(`confMSPQOWN´, `nullmail´)

If you change the username, you will also have to build and install your own submit.cf file, and include in the mc file, for that creation, a definition for the new users with the RunAsUser option like this:

FEATURE(`msp´)
define(`confRUN_AS_USER´, `nullmail´)

If you don’t change the name, sendmail will use the name smmsp, which stands for SendMail Message Submission Program

Whether your keep the username chosen by the sendmail distribution, or choose a name of your own, you will need to add that name to your system’s passwd services. Here we show how to do this with the traditional Unix passwd file.

nullmail:*:32764:32764:Null Mail:/no/such/directory:/bin/false

In this example of a line from a traditional Unix passwd file, we have elected to create the user named nullmail. The line is divided into five fields by colons. The first ield is the name of the new user. The second field is the user’s password. But
because this user is not an actual person, we disable the password with an asterisk. On some systems you will need to put an x in this field, or the word NOPASSWORD. ee your system documentation for what to use in this field to disable a password for this new user.

The third and fourth fields are the user and group ID for the user. Here, we chose high numbers that are unlikely to conflict with actual user numbers. Some versions f Unix restrict the size of the numbers you can use. See your system’s  documentation. The fifth field is called the gecos field. It contains the full name of the users. We chose Null Mail, but you can choose any name you desire.

The last two fields are the home directory and shell for this user. The home directory should not exist, nor should it have the potential of ever existing. The shell hould be a program that will never successfully run. We chose /bin/false because
that program always exits with a nonzero (failure) value.

Add smmsp to /etc/group

When sendmail is run as non-set-user-id root, it is run either as root when it is invoked by the root user (in which case it can read all files), or as another user when t should not run as root. To enable the sendmail program to read and write its queue
when it is not root, it needs to always run as a predefined group. It does this by having its set-group-id permission set, and by running under an appropriate group. The sendmail distribution clearly cannot divine ahead of time what group you wish to use when not running sendmail as set-group-id. It could have chosen nogroup, for example, but the user nogroup does not exist under all versions of Unix.

You can choose your own group by using the confGBINGRP build macro to place a line suchas the following into your build m4 file. But don’t chose a group that is shared by any other user. For security reasons, the group you choose should be used only by sendmail:

define(`confGBINGRP´, `nullgroup´)

If you change the group, you will also have to build and install your own submit.cf file, and include in the mc file, for that creation, a definition for that new group with the RunAsUser option like this:

FEATURE(`msp')
define(`confRUN_AS_USER', `:nullgroup')

Note that the same option sets both the user and the group. A combined declaration might look like this:

 FEATURE(`msp')
define(`confRUN_AS_USER´, `nullmail:nullgroup´)

If you don’t change the group, sendmail will use the group smmsp.

Whether you keep the group name chosen by the sendmail distribution, or choose a name of your own, you will need to add that name to your system’s group services.

 nullgroup:*:32764:

In this example of a line from a traditional Unix group(5) file, we have elected to create the group named nullgroup. The line is divided into four fields by colons. The first field is the name of the new group. The second field is the group’s password. Because this group is not used by actual people, we disable the password with an asterisk. On some systems you will put an x in this field, or the word NOPASSWORD.  The third field contains the group number. That number should match the number used in the group field of the passwd(5) file. The last field contains the usernames of those that should also belong to this group. Generally, this will be an empty field.

Modify init Files

In a non-set-user-id root world, you run sendmail differently than the traditional manner to which you have become accustomed. There are two differences that you should attend to before installing the new non-set-user-id root setup. First, you need to decide how to drain the local message submission queue. Second, you need to decide on a name to differentiate the two roles with the syslog(8) facility

For local mail submission, sendmail will use a separate queue, one that is group read/write by the group discussed in the previous section. The sendmail program, in local message submission mode, sends a message and then exits. As a consequence, there is nothing running that can drain that separate queue of any messages that might be deferred there. The best way to drain it is with a queue processing daemon, such as this:

 /usr/sbin/sendmail -Ac -q30m

Here, the -Ac command-line switchtells sendmail to use the configuration file named submit.cf. This is the special message submission configuration file that knows about the second queue. The -q30m command-line switchcauses sendmail to wake up once each 30 minutes and process any deferred messages it finds in the second queue.

To differentiate one sendmail from another in the logs created by the syslog(8) facility, you can use the -L command-line switch. One suggestion looks like this:

/usr/sbin/sendmail -L mta-daemon -bd -q30m
/usr/sbin/sendmail -L msp-queue -Ac -q30m

The first line is the invocation of sendmail that is most common (with the -bd -q30m). The second line has been added to drain the second (mail submission) queue. The first will contain the identifier mta-daemon in its syslog(8) logfiles. The second will contain the identifier msp-queue. These identifiers are only suggestions, and you might prefer something more suitable to your site’s needs.

The sendmail program is usually started from a script in the etc directory. On System-V-based versions of Unix, that file is usually found in the /etc/init.d directory. On other versions of Unix, that file could live directly in the etc directory, and might be called rc or rc.local. Whichever file contains the commands to start sendmail on your system, look at it and determine how sendmail is currently started and stopped. You might, for example, find lines such as this, from a FreeBSD 4.0 sendmail startup file called rc:

case ${sendmail_enable} in
[Yy][Ee][Ss])
if [ -r /etc/mail/sendmail.cf ]; then
echo -n ' sendmail'; /usr/sbin/sendmail ${sendmail_flags}
fi
;;
esac

To modify this setup for use in a non-set-user-id root scheme, you would need to add the following line to your /etc/rc.conf file:

sendmail_flags="${sendmail_flags} -L mta-daemon"

Then create the file /etc/rc.local (if it does not already exist), and add the following lines to it:

case ${sendmail_enable} in
[Yy][Ee][Ss])
if [ -r /etc/mail/sendmail.cf ]; then
echo -n ' msp-queue'; /usr/sbin/sendmail -L msp-queue -q30m
fi
;;
esac

Take the time, now, to investigate how sendmail is started and stopped on your system. The new non-set-user-id root scheme will doubtless require special modifications on your part. Beginning withSolaris 7, for example, the pkill(8) command, as it is set up in /etc/init.d/sendmail, will not stop a sendmail that is running other than as root

 The submit.cf File

The submit.cf file is built for you automatically when you install sendmail. When you run make install, the following is one of the commands executed:

 cd ../../cf/cf && make install-submit-cf

This command will create and install a default /etc/mail/submit.cf file if that file does not already exist. For most sites, this default will be suitable for your use as is. If you customize at all, however, you will need to create your own submit.cf file. If, for example, you changed the user and group names for the non-set-user-id root version of sendmail with the following in your build m4 file:

define(`confMSPQOWN´, `nullmail´)
define(`confGBINGRP´, `nullgroup´)

you will need to create a custom submit.cf file. You create a custom submit.cf file just like you create a sendmail.cf file. You begin by creating a file called submit.mc. You can use the file cf/cf/submit.mc as a template for your own, or you can edit that file directly. If you edit that file directly, you will need to copy your changes to the same directory each time you upgrade sendmail to a new version.

Note that the name submit.cf is hardcoded and cannot be changed. When sendmail runs, unless you have built it to do otherwise, it will look for submit.cf in the same directory that it looks for its standard configuration file. If you change the location of the standard configuration file with the _PATH_SENDMAILCF build-time macro, you will also want to change the directory in which the submit.cf file is located. That directory is defined with the _DIR_SENDMAILCF
build-time macro.* For example, your build m4 file might look, in part, like this:

APPENDDEF(`confENVDEF´, `-D_PATH_SENDMAILCF=\"/opt/sendmail/sendmail.cf\"´)
APPENDDEF(`confENVDEF´, `-D_DIR_SENDMAILCF=\"/opt/sendmail/\"´)

Here, the first line changes the location of the sendmail.cf file. The second line is necessary so that sendmail will look for submit.cf in that same directory. Without this second line, sendmail would look for sendmail.cf in /opt/sendmail, but would look for submit.cf in the default location, /etc/mail.

Note that a Build install will always try to place the submit.cf file into a directory that begins with /etc/mail. But you can prefix this directory with another directory name, as shown here:

 # ./Build -E DESTDIR=/opt/sendmail install

This will cause the submit.cf file to be installed in the /opt/sendmail/etc/mail directory. If you have changed the location of your configuration files, as shown earlier, you will have to manually move the submit.cf file from its default installed location to your chosen location

Finally, note that by renaming or relocating the queue directory with the confMSP_QUEUE_DIR Build macro, the MSP_QUEUE_DIR mc macro must also be updated so that a correct submit.cf file will be created.

•  If you choose to run the new sendmail in place of the original, you first need to create and install a new configuration file. The m4(1) program is used to automate the process of configuration file creation.
• If you choose to keep the original and install the new sendmail in parallel (until you can test it), you can proceed with the installation and defer configuration files until later. Note that this choice presumes you customized the file locations.

Beginning withV8.12, installation of sendmail became a bit more complex. You now have the choice of running sendmail as either a set-user-id root or a non-set-user-id root program. Our recommendation, beginning withV8.12, is to run sendmail as a non-set-user-id root. If you wishto install sendmail as a set-user-id root program, despite the potential security risks implied by such an approach, just issue this new special command:

# ./Build install-set-user-id

The preferred way to install sendmail, beginning withV8.12, is to first create three required system changes, and then to run ./Build install as usual:

• Edit the /etc/passwd file (and possibly companion files suchas /etc/shadow and /etc/master.passwd, or possibly network services suchas Network Information Services [NIS]) to add the user smmsp. The name smmsp can be changed from its default withth e confMSPQOWN build macro.
• Edit /etc/group file (or possibly network services suchas NIS) to add the new group smmsp. The name smmsp can be changed from its default with the confGBINGRP build macro.
• Edit the /etc/rc.local file (or a different file depending on your version of Unix, such as /etc/init.d/sendmail or /etc/rc.conf) to change the way sendmail is started and stopped at boot time.

In a non-set-user-id root world, sendmail runs under two guises. In one guise, it is run by root to function as a listening daemon. This listening daemon is just like the listening daemon of earlier versions, except that, instead of running as root no matter who ran it, it now runs as root only if root runs it.

In its second guise, sendmail runs as an ordinary user to collect locally submitted messages. In this mode of operation, sendmail is set-group-id to a special group, so it runs in that group no matter who runs it. That group owns and has write permission to a separate queue into which locally submitted deferred messages are placed.

For this division of labor to work, the two guises need to use different configuration files.  The configuration file used by the locally submitted message sendmail is called submit.cf. Which configuration is used depends on how sendmail is run.

If sendmail is run withth e -bm command-line switch, the -bs command-line switch, or the -t command-line switch, it first tries to open and read submit.cf. If that file does not exist, sendmail falls back to reading its standard configuration file. The -bm command-line switch (sendmail’s default mode) causes sendmail to run as a mail sender, once in the foreground, gathering a list of recipients from the command line and reading the message from its standard input. The -bs command-line switchcauses sendmail to run a single MTP session in the foreground over its standard input and output, and then to exit.

The -t command-line switchcauses sendmail to gather its list of recipients from its standard input rather than from the command line. In addition to determining the use of submit.cf based on sendmail’s mode of operation, sendmail can also be coerced into using or not using submit.cf based on a new command-line switch. The -A command-line switch takes one of two possible arguments. If it is followed by an m character, sendmail uses the sendmail.cf file. If the -A is
followed by a c character, sendmail uses the submit.cf file:

/usr/sbin/sendmail -Am ← use sendmail.cf

/usr/sbin/sendmail -Ac ← use submit.cf

% cd sendmail
% ./Build -n
Configuration: pfx=, os=SunOS, rel=4.1.4, rbase=4, rroot=4.1, arch=sun4, sfx=
Using M4=/usr/5bin/m4
Creating ../obj.SunOS.4.1.4.sun4/sendmail using ../devtools/OS/SunOS
← many more lines here
%

Here, Build found that our machine was a sun4, running the SunOS 4.1.4 release of Unix. Build then created the working directory ../obj.SunOS.4.1.4.sun4, set up symbolic links to all the source files in that directory, and finally generated a Makefile there.

 Build with m4

The make(1) program* is used to compile and install sendmail. Th eBuild script creates not only an object working directory, but also an appropriate Makefile in that directory using m4(1). Unless you tell Build to do otherwise, the Makefile it creates

will be based solely on information it find  in the appropriate devtools/OS and devtools/Site subdirectories.

For most sites, this default behavior will produce the desired result. For other sites, different defaults are needed.

Creating a Makefile with Build is simplicity itself. First decide whether you wish to maintain your m4 file inside the sendmail source tree, or outside it. If you choose to maintain your m4 file inside the source tree, just name it devtools/Site/site.config.m4 and run Build like this:

% ./Build

Note that here we have chosen to maintain all our Build m4 files inside the sendmail source tree. This approach allows administrators to rebuild sendmail without needing to remember where the m4 file is located.

If you choose to maintain your m4 file outside the source tree, use the -f commandline switch with Build to specify the location of that file:

% ./Build -f /usr/local/configs/sendmail/oursite.m4

Note that here we have chosen to maintain all our Build m4 files in a directory that is outside the sendmail distribution. This approach allows you to upgrade to new eleases of sendmail without having to remember to copy the devtools/Site directory
each time. The downside to this approach is that you must remember to use the -f command-line switchevery time you build. If you fail to remember, or if someone lse builds without knowing the need for -f, the created sendmail binary may not
work as you expect or might lack the abilities you require.

 Run Build

After you have finished configuring your m4 build file, you are ready to build sendmail. First run the following command in the sendmail source directory:

# ./Build -f /path/to/your/m4/file -n

This command first creates the obj directory in which sendmail will be built, populates that directory with symbolic links, and places a configured Makefile there. It then displays all the commands that make will generate without actually executing them.

If you are building a plain vanilla sendmail, or if you have placed your m4 file in the devtools/Site directory, you can omit the -f and the path to your m4 build file. If you wishto tune sendmail to your custom needs first, before running Build, you need to create an m4 file (as discussed earlier).

You can create your Build m4 files either outside the sendmail distribution or inside a special directory inside the distribution. If you maintain them outside, you will have to use the -f switch each time you build, but will avoid having to copy them again for each release of sendmail.

If you create a special file inside the devtools/Site directory, that file will be included without the need for an -f. The name of the file is site.config.m4. If you want to maintain several master files in that directory, you can do so depending on your
operating system type. When Build runs, it prints a line that looks like the following, split to fit the page:

Configuration: pfx=, os=SunOS, rel=4.1.4, rbase=4, rroot=4.1, arch=sun4,
sfx=,variant=optimized

Here, the name of the operating system is printed following the os=. If you were to create a file in the devtools/Site directory called site.SunOS.m4, it, too, would be automatically found and used without the need for an -f switch.

If you have defined the environment variable SENDMAIL_SUFFIX, the sfx= will be assigned that value with a dot in front of it. That value can be used to further tune the name of the files in devtools/Site. For example, if SENDMAIL_SUFFIX is defined as server, the Build script will find and use a file called site.SunOS.server.m4.

The devtools/Site directory is first searched for the literal name site.config.m4. If that is not found, it is searched for the file named site.os=sfx=.m4, and after that for the file named site.os=.m4.

If all looks well after you have run Build withan -n, you can run it again, this time without the -n.

If You Change Your m4 Build File

After you run Build, you will likely find that you need to change one or more items in your m4 build file. Whenever you change that file, you will need to use the -c switch with Build to force it to create a new Makefile withyour new information in it. You do this by adding the -c switch to Build’s command line:

% ./Build -c -f ../../builds/oursite.m4

% ./Build -c ← if using devtools/Site

Using a graphical user interface

1. From the Control Panel, open the Add or Remove Programs applet.
2. Click Add/Remove Windows Components.
3. Double-click Network Services.
4. Check the box beside Dynamic Host Configuration Protocol (DHCP).
5. Click OK.
6. Click Next.
7. Click Finish.

Using a command-line interface

First, create a file using a text editor such as Notepad with the following contents:

[netoptionalcomponents]
 dhcpserver=1

Next, use the sysocmgr.exe utility with the following parameters (assuming the file you just created is named c:\dhcp_install.txt):

> sysocmgr /i:%windir%\inf\sysoc.inf /u:c:\dhcp_install.txt

If the server you installed DHCP on is multihomed (i.e., has multiple active network adapters), you’ll want to make sure the correct network adapters are enabled for use by the DHCP Server. You can enable or disable adapters for use by DHCP Server by doing the following:

1. Open the DHCP snap-in.
2. In the left pane, click on the server node.
3. From the menu, select Action > Properties.
4. Select the Advanced tab.
5. Click the Bindings button.
6. Make sure the interfaces where the DHCP Server should respond are checked.
7. Click OK until all dialog boxes are closed.

1. Open the Group Policy Management snap-in.
2. In the left pane, navigate to the GPO you want to modify. Left-click on it and select Edit.
3. If you want to publish an application to computers the GPO applies to, expand Software Settings under Computer Configuration. If you want it to apply to users, expand Software Settings under User Configuration.
4. Right-click Software installation and select New > Package.
5. Enter the UNC path of the location of the MSI installation file (even if it resides on a local drive on the domain controller.
6. Select the MSI file and click Open.
7. Select Assigned if you want this application to be installed automatically on each client the GPO applies to. Select Published if you want this application to be downloaded and made available to be installed via an Add/Remove Programs applet if the client chooses to install it (this option is only available for the User Configuration section of a GPO).
8. Click OK.

You can use group policy to install applications, hotfixes, and service packs on servers. The preferred method for installation is to use Microsoft Installer files, but you can also use something called a ZAW down-level application package (ZAP) file to do non-MSI-based installations (for example, using Setup.exe instead). ZAP installations can be configured only in the User Configuration section of a GPO. For more on ZAP installations, see MS KB 231747.

When you assign an application to the User Configuration section of a GPO, the application is automatically installed the next time targeted users log into a computer. When an application is assigned to the Computer Configuration section of a GPO, it is installed the next time the GPO is refreshed on targeted computers (or when the computers reboot). In both cases, the application installation is finalized the first time a user actually runs the program.

Publishing an application is a little different. You can publish an application only in the User Configuration section of a GPO, not the Computer Configuration section. After you publish an application, it will show up in the Add/Remove Programs applet and be available for the user to install on demand.

You can do much more than just basic assigning and publishing of applications with GPOs. You can also upgrade and remove applications. For a quick overview of those processes, see MS KB 314934. You can also use the GPO software installation feature to install service packs on your clients. See MS KB 278503 for more information on how to install a service pack using a GPO.

1. From the Control Panel , open the Add or Remove Programs applet.
2. Click on Add/Remove Windows Components.
3. Click on the component you are interested in.
4. If there are subcomponents, the Details button will become active. Click on it. Check the box beside the components you want to install. When you are done, click OK.
5. Click Next. At this point the component(s) will be installed.
6. Click Finish to close the screen.

Using a command-line interface
Create an answer file using a text editor, such as notepad.exe. Here is an example answer file that would install the DNS Server service:

[netoptionalcomponents]

dns=1

Next, run the sysocmgr utility with following parameters (assuming you named the answer file c:\comp_install.txt):

> sysocmgr /i:%windir%\inf\sysoc.inf /u:c:\comp_install.txt

Using VBScript

Unfortunately, there are no scripting interfaces for installing Windows Components. However, you can run the sysocmgr command from the previous section directly within a batch script (.bat extension) or using the WScript.Shell Run method within VBScript.

' This code simulates the same steps from the command-line solution.

' First, an answer file is created containing the parameters to install

' the DNS Server. Then the sysocmgr command is invoked to perform the

' installation.

strFile = "c:\comp_install.txt"constForWriting = 2

set objFSO = CreateObject("Scripting.FileSystemObject")

set objFile = objFSO.OpenTextFile(strFile, constForWriting, True)

objFile.WriteLine("[netoptionalcomponents]")

objFile.WriteLine("dns=1")

objFile.Close

set objWshShell = WScript.CreateObject("WScript.Shell")

intRC = objWshShell.Run("sysocmgr /i:%windir%\inf\sysoc.inf /u:" & _

                        strFile, 0, TRUE)

if intRC <> 0 then

   WScript.Echo "Error returned from sysocmgr command: " & intRC

else

   WScript.Echo "Windows Component installed"

end if

A Windows Component is an optional feature of the operating system. A Windows Component can be anything from server service, such as DNS, to a small application, like Calculator. You’ve undoubtedly used the steps I described in the graphical solution to install a Windows Component before. Fewer people are as familiar with the command-line (and VBScript) solutions.

You can script the installation (and uninstallation for that matter) of Windows Components using the sysocmgr.exe utility. All you need is an answer file that contains the components to install or uninstall. This can in fact be the same answer file you use to do unattended installations. Sysocmgr.exe reads only the [Components] and [Netoptionalcomponents] sections of an answer file. To see all the available components you can include in these sections, you need to look at the unattended reference documentation that is available on the Windows Server CDs for Windows 2000 and Windows Server 2003.

On a Windows 2000 CD, navigate to \SUPPORT\TOOLS\ and open the deploy.cab file. Within deploy.cab is a file named unattend.doc, which you’ll need to extract and open. This file contains all answer file settings. On a Windows Server 2003 CD, you also need to open \SUPPORT\TOOLS\deploy.cab, but instead you want to extract ref.chm from it. Within ref.chm is a section entitled Unattend.txt, which contains all of the settings.

Again, you’ll want to look at the [Components] and [Netoptionalcomponents] sections of the reference documentation. For [Components] there are over 80 different entries you can use and for [Netoptionalcomponents] there are 13 possible entries. One difference to note about the two sections is that you enable or disable components in the [Components] section using on (to install) or off (to uninstall) and for the [Netoptionalcomponents] section you use 1 (to install) or 0 (to uninstall).

Here is a sample answer file that installs IIS and the DNS Server service:

[Components]

 iis_common = on

 iis_www = on

 iis_www_vdir_scripts = on

 iis_inetmgr = on

 fp_extensions = on

 iis_ftp = on

 netoc = on[NetOptionalComponents]

 dns=1

Run the executable and extract the files to a folder on your server. Then install the protocol stack by running setup.exe. If you are running Service Pack 2 or later (and hopefully you are), you have to perform some additional steps to get the installation to work. By default if you run the setup program it will complain about the system not being at Service Pack 1. Follow the directions on the following site to fix the problem: http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/faq.asp.

Once you have the stack installed, you should follow the steps outlined in the graphical user interface instructions to configure it for a particular network connection (which also applies to Windows Server 2003).

Using a graphical user interface

1. Open the Control Panel.
2. From the Network Connections applet, double-click the connection you want to install IPv6 for.
3. Click the Properties button.
4. Click the Install button.
5. Select Protocol and click the Add button.
6. Select Microsoft TCP/IP version 6 and click OK.
7. Click Close.

Using a command-line interface

The following command installs the IPv6 stack. It must be run directly on the target server:

> netsh interface ipv6 install

If you need to run the command remotely, you can use the psexec command:

> psexec \\server01 netsh interface ipv6 install

Using VBScript

There is no scripting interface to install the stack, but you can shell out and run the netsh command as in the following example:

' This code installs the IPv6 on the computer the script is run from.strCommand = "netsh interface ipv6 install"

set objWshShell = WScript.CreateObject("WScript.Shell")

intRC = objWshShell.Run(strCommand, 0, TRUE)

if intRC <> 0 then

WScript.Echo "Error returned from running the command: " & intRC

else

WScript.Echo "Command executed successfully"

end if

IPv6 is the next generation TCP/IP protocol suite intended to replace IPv4. Adoption of IPv6 has been slow, but seems to be steadily gaining momentum. Fortunately, Windows Server 2003 provides better support for IPv6 than it did Windows 2000. For a good overview of IPv6 and how to configure the Windows client, see the following FAQ: http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/faq.asp.