Windows 2003: Loses connection to a network share on a Windows 7 machine

This has been perplexing us at work for a bit this week.  We have a Windows 2003 server which attempts to send its backup logs to a desktop PC.  It used to send it to a Windows XP machine, but that has now been replaced with a Windows 7 Professional workstation.

The problem is that everything works fine for 10-20 minutes at a time.  Then the Windows 2003 server will lose connection to the Windows 7 desktop and you will be unable to map to the share points on the Win7 machine until you reboot the Windows 7 desktop.

On the Windows 2003 server you will see:

C:> net view \\hostname.example.com

System error 58 has occurred.

The specified server cannot perform the requested operation.

This will also show up in the error log on the Windows 7 as:

Error 2017: The server was unable to allocate from the system nonpaged pool because the server reached the configured limit for nonpaged pool allocations.

The fix for this is two-fold and is all performed on the Win7 machine.  It requires editing a pair of registry entries on the Win7 machine.

1) HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargeSystemCache

This gets changed from "0" (zero) to "1" (one).

2) HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\Size

This gets changed from "1" to "3".

Reference links:

Windows 7 Nonpaged Pool Srv Error 2017
Systems Internals Tips and Trivia

PuTTY and SubVersion on Windows 2003

One thing we use SubVersion for in the office is for tracking configuration changes to our Linux servers. Everything under /etc or any other file that we change by hand (or with configuration tools) gets put into SVN which tracks the changes. It's possible to do the same thing under Windows (although not everything can be tracked).

A) Install PuTTY on the Win2003 server

1. The usual defaults are fine (install to C:\Program Files\PuTTY)

2. Create a public key (RSA, 2048 bit, no passphrase) and save it somewhere on the Windows 2003 server hard drive. I'd recommend an easy-to-type location because you'll be referencing constantly in batch files.

Security implications:

- Make sure that the account on the SVN server is a limited account, maybe even with a restricted shell. Just in case the authorized_keys file restriction is ever removed by accident.

- Setting the authorized_keys file to only allow "svnserve -t" as a command will keep most attackers from gaining console access to the server. But you're relying on the security of the svnserver application to not have an buffer/overflow exploits that allow shell access.

- Our decision was that the public key on the Win2003 server did not need a passphrase. The risks are worth it in order to be able to script svn commands to shove log files across the wire to the central SVN server every hour.

3. Upload the public key to your SVN server, configure it in the authorized_keys file and restrict it to only allowing command="svnserve -t".

# su accountname
# cd /home/accountname
# mkdir .ssh
# chmod 700 .ssh
# cd .ssh
# cat > machinename@svn.pub
(paste in PuTTY key)
# ssh-keygen -i -f machinename@svn.pub >> authorized_keys
# vi authorized_keys
(add command="svnserve -t" to the front of the new key line)
# chmod 600 *

4. Fire up PuTTY and attempt to connect to your SVN server. That will cache the server's public key in PuTTY's records.

B) Install the SubVersion Win32 command-line client on the server.

1. Install SVN to the default location

2. Right-click on My Computer, Properties, Advanced, Environment Variables

3. Under System Variables, click "New":
Variable name: SVN_ASP_DOT_NET_HACK
Variable value (can be anything at all): _svn

4. Under System Variables, highlight "PATH" and click "Edit". Add ";C:\Program Files\PuTTY" to the end of the PATH statement (which assumes you installed PuTTY to that location)

5. Under User Variables, click "New":
Variable name: SVN_SSH
plink -ssh -l user -pw password
- "user" should be your username on the SVN server
- the "-pw password" is optional if you did not put a passphrase on your key

C) Add the base set of directories to the server.

1. Check connectivity to the SVN server

C:\ svn list svn+ssh://user@svn.example.com/var/svn/repos

(if that doesn't work, go back and verify SSH connectivity)

2. Create a "C" folder in the root of the repository to represent your "C" drive. I usually do it on another system in a temporary folder.

3. Do the default checkout to the root of C: and D:

C:\ svn co svn+ssh://user@svn.example.com/var/svn/repos/C .
D:\ svn co svn+ssh://user@svn.example.com/var/svn/repos/D .
(note the "." at the end of the command)

4. Start adding folders and files to the SVN repository.

C:\ svn add -N Data
C:\ svn add -N Data\Logs
C:\ svn ci -m "log folder"

Rsync and SSH on Windows 2003 Server

Taking another stab at setting up RSync and SSH on our Windows 2003 servers. The goal is that we can upload web files to a central server and then have it synchronize the other servers in the array. Once again, I'm going to use the cwRsync and copSSH packages (latest version is 2.0.9).

Installation on a Windows 2003 Domain Controller:

1. Download cwRSync, open up the ZIP file, then extract/run cwRsync_Server_x.x.x_Installer.exe.
   
2. Click "Next" to move past the splash screen
   
3. Click "I Agree" to move past the license screen
   
4. Select both the "Rsync Server" and "OpenSSH Server" (unless you have already installed and configured SSH) then click "Next"
   
5. Choose your installation location, the default is "C:\Program Files\cwRsyncServer"
   
6. Click "Install" to begin the installation process
   
7. cwRsync will install and create a default service account with a randomly generated password.
   
8. Write down the service account password.
   
9. Click "Close" when the install has finished.
   

So now if you look in "Active Directory Users and Computers", there should be a newly created account called "SvcwRsync". Since we are installing this on a domain controller, you should rename this account to "SvcwRsync_SERVERNAME" so that it doesn't cause problems for other installations. You'll also need to change the login details for the "RsyncServer" and "OpenSSH SSHD" services.

Once you have things configured, make sure to go to the Services control and set the services to start up automatically. I also recommend configuring the Recovery tab so that the services are automatically restarted after 2 or 5 minutes.

...

Now to start locking things down. First, I'm going to restrict what interfaces (IP addresses) that the cwRSync service can listen on by adding an address line to rsyncd.conf.

address = 127.0.0.1

One the machine that you will be using to talk to the rsync daemon on the host server, you'll also need the cwRsync tools installed along with OpenSSH. Because the rsync daemon can only listen on 127.0.0.1 (localhost), we'll need to create an SSH tunnel from the client machine to the host server before we can talk to the rsync daemon.

One the client machine:

1. Create a new folder under "C:\Program Files\cwRsyncServer\home" for the new user. In my particular case, I'm calling my user "backuppull" because I am pulling backup files off of the rsync server and down to my local machine.

2. Create a ".ssh" folder under that new home folder.

3. Open up a command window (Start, Run, "cmd") and change directories to the home folder ("C:\Program Files\cwRsyncServer\home\backuppull")

4. Create ssh keys for this user. Since we want to do this sync in a batch file without user-interaction, they'll need to be created with null passwords. You may wish to use the "-b 2048" option to create stronger keys (recommended for RSA, DSA can only be up to 1024 bits).

mkdir .ssh
..\..\ssh-keygen -t rsa -N "" -b 2048 -f .ssh\id_rsa
..\..\ssh-keygen -t dsa -N "" -b 1024 -f .ssh\id_dsa

5. You will now need to transfer the public key files to the host server. Again, you will create a new home directory for the user in the "C:\Program Files\cwRsyncServer\home" folder tree along with creating a ".ssh" folder under that home folder. The two files that need to be copied are:

id_dsa.pub
id_rsa.pub

6. Now append the contents of these files to the ".ssh/authorized_keys" file on the host server.

type id_dsa.pub >> authorized_keys
type id_rsa.pub >> authorized_keys

7. Now to configure SSHD on the host server. You will need to find and edit the sshd_config file (probably in "C:\Program Files\cwRsyncServer\etc"). The following changes should be made in the current version default settings.

PermitRootLogin no
PasswordAuthentication no

Result code 0x57 when scheduling a backup

This was a slightly odd one that did not show up on Google at all. We had a bunch of backup jobs on our main Windows 2003 file server and had recently promoted the Win2003 server to a domain controller using DCPROMO.EXE. In the process of doing that, some tasks refused to run and we also had to delete and re-add a lot of tasks.

In the Scheduled Tasks window, we saw a result code of "0x57" in the Last Result column. In the schedule log (Scheduled Tasks, Advanced, View Log):

"Backup-FileServer-DailyAppend-Week2.job" (ntbackup.exe)
Finished 7/28/2006 8:30:48 PM
Result: The task completed with an exit code of (57).

We checked a few things and finally took a very close look at the "Run" field in the task. Turns out that we were missing a double-quote in the middle of the NTBACKUP command line.

Printer Banner on Windows Servers

How do I configure a Print Separator Page? (March 1999)
- Explains very briefly how to do it.

Using separator pages
- A much more useful article.

Shared printer separator page for Windows 2000 and Windows XP
- Another source.

Auditing tools for Windows

fsum by SlavaSoft - (free) Creates md5 signature files compatible with the md5sum command line tool (found on most unix/linux distros), but has the additional feature of directory recursion. The tool also supports other checksum/hash functions.

DumpSec by SomarSoft - (free) This tool used to be called DumpACL back in the days of Windows NT 4.0. It has been re-released to report on the newer ACL information in an Active Directory Domain (Windows 2000), plus it has the option to dump out lists of users, groups, policies, shares, registry ACLs, and a few more goodies. Output is either an interactive report viewer, a custom save file format, or various report file styles.

rsync - (free) While not strictly an auditing tool, rsync is useful for pushing/pulling log files off of a server onto a better protected server for long-term storage. The primary advantage is that rsync will only send the portions of a file that have changed, reducing transfer traffic. It also supports compression of the transfer and you can route the information through ssh for security. The version I use is cwRSync, which is a streamlined version of the Microsoft Windows port that doesn't require the full Cygwin application to be installed.