Chapter 22. Advanced Network Management
Prev | Part III. Advanced Configuration | Next

## Chapter 22. Advanced Network Management

### John H. Terpstra

Samba Team

`<jht@samba.org>`

April 3 2003

This section documents peripheral issues that are of great importance to network administrators who want to improve network resource access control, to automate the user environment, and to make their lives a little easier.

## Features and Benefits

Often the difference between a working network environment and a well appreciated one can best be measured by the little things that makes everything work more harmoniously. A key part of every network environment solution is the ability to remotely manage MS Windows workstations, to remotely access the Samba server, to provide customised logon scripts, as well as other house keeping activities that help to sustain more reliable network operations.

This chapter presents information on each of these area. They are placed here, and not in other chapters, for ease of reference.

## Remote Server Administration

How do I get 'User Manager' and 'Server Manager'?

Since I don't need to buy an NT4 Server, how do I get the 'User Manager for Domains', the 'Server Manager'?

Microsoft distributes a version of these tools called nexus for installation on Windows 9x / Me systems. The tools set includes:

Server Manager
User Manager for Domains
Event Viewer

Click here to download the archived file ftp://ftp.microsoft.com/Softlib/MSLFILES/NEXUS.EXE

The Windows NT 4.0 version of the 'User Manager for Domains' and 'Server Manager' are available from Microsoft via ftp from ftp://ftp.microsoft.com/Softlib/MSLFILES/SRVTOOLS.EXE

## Remote Desktop Management

There are a number of possible remote desktop management solutions that range from free through costly. Do not let that put you off. Sometimes the most costly solutions is the most cost effective. In any case, you will need to draw your own conclusions as to which is the best tool in your network environment.

### Remote Management from NoMachines.Com

The following information was posted to the Samba mailing list at Apr 3 23:33:50 GMT 2003. It is presented in slightly edited form (with author details omitted for privacy reasons). The entire answer is reproduced below with some comments removed.

    > I have a wonderful linux/samba server running as PDC for a network.
    > Now I would like to add remote desktop capabilities so that
    > users outside could login to the system and get their desktop up from
    > home or another country..
    >
    > Is there a way to accomplish this? Do I need a windows terminal server?
    > Do I need to configure it so that it is a member of the domain or a
    > BDC,PDC? Are there any hacks for MS Windows XP to enable remote login
    > even if the computer is in a domain?
    >
    > Any ideas/experience would be appreciated :)

Answer provided: Check out the new offer from NoMachine, "NX" software: http://www.nomachine.com/.

It implements a very easy-to-use interface to the remote X protocol as well as incorporating VNC/RFB and rdesktop/RDP into it, but at a speed performance much better than anything you may have ever seen...

Remote X is not new at all -- but what they did achieve successfully is a new way of compression and caching technologies which makes the thing fast enough to run even over slow modem/ISDN connections.

I could test drive their (public) RedHat machine in Italy, over a loaded internet connection, with enabled thumbnail previews in KDE konqueror which popped up immediately on "mouse-over". From inside that (remote X) session I started a rdesktop session on another, a Windows XP machine. To test the performance, I played Pinball. I am proud to announce here that my score was 631750 points at first try...

NX performs better on my local LAN than any of the other "pure" connection methods I am using from time to time: TightVNC, rdesktop or remote X. It is even faster than a direct crosslink connection between two nodes.

I even got sound playing from the remote X app to my local boxes, and had a working "copy'n'paste" from an NX window (running a KDE session in Italy) to my Mozilla mailing agent... These guys are certainly doing something right!

I recommend to test drive NX to anybody with a only a remote interest in remote computing http://www.nomachine.com/testdrive.php.

Just download the free of charge client software (available for RedHat, SuSE, Debian and Windows) and be up and running within 5 minutes (they need to send you your account data, though, because you are assigned a real Unix account on their testdrive.nomachine.com box...

They plan to get to the point were you can have NX application servers running as a cluster of nodes, and users simply start an NX session locally, and can select applications to run transparently (apps may even run on another NX node, but pretend to be on the same as used for initial login, because it displays in the same window.... well, you also can run it fullscreen, and after a short time you forget that it is a remote session at all).

Now the best thing at the end: all the core compression and caching technologies are released under the GPL and available as source code to anybody who wants to build on it! These technologies are working, albeit started from the command line only (and very inconvenient to use in order to get a fully running remote X session up and running....)

To answer your questions:

- You don't need to install a terminal server; XP has RDP support built in.

- NX is much cheaper than Citrix -- and comparable in performance, probably faster

- You don't need to hack XP -- it just works

- You log into the XP box from remote transparently (and I think there is no need to change anything to get a connection, even if authentication is against a domain)

- The NX core technologies are all Open Source and released under the GPL -- you can today use a (very inconvenient) commandline to use it at no cost, but you can buy a comfortable (proprietary) NX GUI frontend for money

- NoMachine are encouraging and offering help to OSS/Free Software implementations for such a frontend too, even if it means competition to them (they have written to this effect even to the LTSP, KDE and GNOME developer mailing lists)

## Network Logon Script Magic

This section needs work. Volunteer contributions most welcome. Please send your patches or updates to John Terpstra.

There are several opportunities for creating a custom network startup configuration environment.

No Logon Script
Simple universal Logon Script that applies to all users
Use of a conditional Logon Script that applies per user or per group attributes
Use of Samba's Preexec and Postexec functions on access to the NETLOGON share to create a custom Logon Script and then execute it.
User of a tool such as KixStart

The Samba source code tree includes two logon script generation/execution tools. See `examples` directory `genlogon` and `ntlogon` subdirectories.

The following listings are from the genlogon directory.

This is the `genlogon.pl` file:

    	#!/usr/bin/perl
    	#
    	# genlogon.pl
    	#
    	# Perl script to generate user logon scripts on the fly, when users
    	# connect from a Windows client.  This script should be called from smb.conf
    	# with the %U, %G and %L parameters. I.e:
    	#
    	#       root preexec = genlogon.pl %U %G %L
    	#
    	# The script generated will perform
    	# the following:
    	#
    	# 1. Log the user connection to /var/log/samba/netlogon.log
    	# 2. Set the PC's time to the Linux server time (which is maintained
    	#    daily to the National Institute of Standard's Atomic clock on the
    	#    internet.
    	# 3. Connect the user's home drive to H: (H for Home).
    	# 4. Connect common drives that everyone uses.
    	# 5. Connect group-specific drives for certain user groups.
    	# 6. Connect user-specific drives for certain users.
    	# 7. Connect network printers.

    	# Log client connection
    	#($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
    	($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
    	open LOG, ">>/var/log/samba/netlogon.log";
    	print LOG "$mon/$mday/$year $hour:$min:$sec - User $ARGV[0] logged into $ARGV[1]\n";
    	close LOG;

    	# Start generating logon script
    	open LOGON, ">/shared/netlogon/$ARGV[0].bat";
    	print LOGON "\@ECHO OFF\r\n";

    	# Connect shares just use by Software Development group
    	if ($ARGV[1] eq "SOFTDEV" || $ARGV[0] eq "softdev")
    	{
    		print LOGON "NET USE M: \\\\$ARGV[2]\\SOURCE\r\n";
    	}

    	# Connect shares just use by Technical Support staff
    	if ($ARGV[1] eq "SUPPORT" || $ARGV[0] eq "support")
    	{
    		print LOGON "NET USE S: \\\\$ARGV[2]\\SUPPORT\r\n";
    	}

    	# Connect shares just used by Administration staff
    	If ($ARGV[1] eq "ADMIN" || $ARGV[0] eq "admin")
    	{
    		print LOGON "NET USE L: \\\\$ARGV[2]\\ADMIN\r\n";
    		print LOGON "NET USE K: \\\\$ARGV[2]\\MKTING\r\n";
    	}

    	# Now connect Printers.  We handle just two or three users a little
    	# differently, because they are the exceptions that have desktop
    	# printers on LPT1: - all other user's go to the LaserJet on the
    	# server.
    	if ($ARGV[0] eq 'jim'
    	    || $ARGV[0] eq 'yvonne')
    	{
    		print LOGON "NET USE LPT2: \\\\$ARGV[2]\\LJET3\r\n";
    		print LOGON "NET USE LPT3: \\\\$ARGV[2]\\FAXQ\r\n";
    	}
    	else
    	{
    		print LOGON "NET USE LPT1: \\\\$ARGV[2]\\LJET3\r\n";
    		print LOGON "NET USE LPT3: \\\\$ARGV[2]\\FAXQ\r\n";
    	}

    	# All done! Close the output file.
    	close LOGON;

Those wishing to use more elaborate or capable logon processing system should check out the following sites:

http://www.craigelachie.org/rhacer/ntlogon
http://www.kixtart.org
http://support.microsoft.com/default.asp?scid=kb;en-us;189105

### Adding printers without user intervention

Printers may be added automatically during logon script processing through the use of:

    	rundll32 printui.dll,PrintUIEntry /?

See the documentation in the Microsoft knowledgebase article no: 189105.

## Common Errors

The information provided in this chapter has been reproduced from postings on the samba@samba.org mailing list. No implied endorsement or recommendation is offered. Administrators should conduct their own evaluation of alternatives and are encouraged to draw their own conclusions.

Prev | Up | Next
Chapter 21. Winbind: Use of Domain Accounts | Home | Chapter 23. System and Account Policies