Find Windows system uptime from the command line


Here’s a quick and easy way of checking how long a Windows server or workstation has been up, via the command line.  It pipes the results of Net Statistics Workstation into find.  Run the following from a command prompt:

net statistics workstation | find /i “statistics since”

The results will look like

Statistics since 8/12/2009 11:08 PM

Which shows the machine has been up since 11:08pm on August 12, 2009.

Howto: Do not display the name of the user who has locked a Windows computer or server


Normally when a Windows workstation or server is locked, you’ll see something similar to the following Windows Security message:  

This computer is in use and has been locked.
 
Only DOMAIN\USER (user name) or an administrator can unlock this computer.
 
To not show the name of the user who has locked a computer, the following can be defined in a workstation level GPO
 
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Interactive logon: Display user information when the session is locked.
 
There are three choices if you enable this policy:
 
  • User display name, domain and user names (default setting)
  • User display name only
  • Do not display user information
 
Besides being able to apply this to Active Directory GPOs, this setting appears in the local security policy on my Windows XP SP3 VM.  The setting is not available on my XP SP2 laptop, but I see from KB837022  there is a hotfix that corrects this problem in XP SP2.


Alternatively, the following DWORD can be created in the registry of XP SP2, Windows Vista, and Windows Server 2008 machine to accomplish the same thing:
 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system\DontDisplayLockedUserId
 
User display name, domain and user names = 1
User display name only = 2
Do not display user information =3
 
You need to restart the machine for the change to take effect.
 
You may also be interested in the related Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Interactive logon: Do not display last user name setting. This security setting determines whether the name of the last user to log on to the computer is displayed in the Windows logon screen.

If this policy is enabled, the name of the last user to successfully log on is not displayed in the Log On to Windows dialog box.  If this policy is disabled, the name of the last user to log on is displayed.

Windows Server Firewall Exceptions for Remote Administration Tools


Microsoft has a web page that lists the various tools you can use to remotely administer a Windows Server system. The page lists each remote administration tool and the steps that are required to successfully use the tool with the Windows Firewall service enabled on the local or remote machine.

Firewall configuration details for the following remote administration tools are provided:

  • Active Directory Domains and Trusts (Windows Firewall: domain)
  • Active Directory Management (Windows Firewall: admgmt)
  • Active Directory Schema Management (Windows Firewall: schmmgmt)
  • Active Directory Sites and Services (Windows Firewall: dssite)
  • Active Directory Users and Computers (Windows Firewall: dsa)
  • Authorization Manager (Windows Firewall: azman)
  • Certificate Templates (Windows Firewall: certtmpl)
  • Certificates (Windows Firewall: certmgr)
  • Certification Authority (Windows Firewall: certsrv)
  • Certutil command (Windows Firewall: certutil)
  • Cluster Administrator (Windows Firewall: cluadmin)
  • Cluster command (Windows Firewall: cluster)
  • Component Services (Windows Firewall: comexp)
  • Computer Management (Windows Firewall: compmgmt)
  • Connection Manager Administration Kit Binaries (Windows Firewall: cmbins)
  • Connection Manager Administration Kit Wizard (Windows Firewall: cmak)
  • Device Manager (Windows Firewall: devmgr)
  • Dfscmd command (Windows Firewall: dfscmd)
  • DHCP (Windows Firewall: dhcpmgmt)
  • Directory Service Utilities (Windows Firewall: ntdsutil)
  • Disk Defragmenter (Windows Firewall: dfrg)
  • Disk Management (Windows Firewall: diskmgmt)
  • Distributed File System (Windows Firewall: dfsgui)
  • DNS Management (Windows Firewall: dnsmgmt)
  • Dsadd command (Windows Firewall: dsadd)
  • Dsget command (Windows Firewall: dsget)
  • Dsmod command (Windows Firewall: dsmod)
  • Dsmove command (Windows Firewall: dsmove)
  • Dsquery command (Windows Firewall: dsquery)
  • Dsrm command (Windows Firewall: dsrm)
  • Event Viewer (Windows Firewall: eventvwr)
  • Fax client console (Windows Firewall: fxsclnt)
  • Fax Service Manager (Windows Firewall: fxsadmin)
  • File Server Management (Windows Firewall: filesvr)
  • Group Policy Object Editor (Windows Firewall: gpedit)
  • IIS Application Management script (Windows Firewall: iisapp)
  • IIS Backup script (Windows Firewall: iisback)
  • IIS Configuration script (Windows Firewall: iiscnfg)
  • IIS FTP script (Windows Firewall: iisftp)
  • IIS FTP Virtual Directory script (Windows Firewall: iisftpdr)
  • IIS Help script (Windows Firewall: iisschlp)
  • IIS Service Extension script (Windows Firewall: iisext)
  • IIS Virtual Directory script (Windows Firewall: iisvdir)
  • IIS Web Management script (Windows Firewall: iisweb)
  • Indexing Service (Windows Firewall: ciadv)
  • Internet Authentication Service (Windows Firewall: iasmsc)
  • Internet Information Services (IIS) Manager (Windows Firewall: iis)
  • IP Security Monitor (Windows Firewall: ipsecmon)
  • IP Security Policies (Windows Firewall: ipsecpol)
  • Local Security Settings (Windows Firewall: secpol)
  • Local Users and Groups (Windows Firewall: lusrmgr)
  • Network Load Balancing Manager (Windows Firewall: nlbmgr)
  • Network Monitor tools (Windows Firewall: netmon)
  • Performance (Windows Firewall: perfmon)
  • POP3 Service (Windows Firewall: p3server)
  • Public Key Management (Windows Firewall: pkmgmt)
  • Remote Desktops (Windows Firewall: tsmmc)
  • Remote Storage (Windows Firewall: rsadmin)
  • Removable Storage (Windows Firewall: ntmsmgr)
  • Removable Storage Operator Requests (Windows Firewall: ntmsoprq)
  • Resultant Set of Policy (Windows Firewall: rsop)
  • Routing and Remote Access (Windows Firewall: rrasmgmt)
  • Security Configuration and Analysis (Windows Firewall: sca)
  • Services (Windows Firewall: services)
  • Shared Folders (Windows Firewall: fsmgmt)
  • Telephony (Windows Firewall: tapimgmt)
  • Terminal Services Configuration (Windows Firewall: tscc)
  • Terminal Services Manager (Windows Firewall: tsadmin)
  • UDDI Services Console (Windows Firewall: uddi)
  • Windows Management Infrastructure (Windows Firewall: wmimgmt)
  • Windows Media Services (Windows Firewall: wmsadmin)
  • Windows Server 2003 Administration Tools Pack (Windows Firewall: adminpak)
  • WINS (Windows Firewall: winsmgmt)
  • Wireless Monitor (Windows Firewall: wiremon)

Microsoft also has a guide to Windows firewall configuration by server role.

Thanks to David for the pointer to this article.

Howto: Install and Configure Moodle on Windows Server 2003 with IIS 6


Matthias Wachs has written a very nice white paper that discusses how to install Moodle on Windows Server 2003.  The paper is written in English, but the link was found on a German language web site.

His paper covers configuring Moodle to work with the following products:

  • Windows Server 2003 R2
  • IIS 6
  • SQL Server 2005
  • PHP 5.2.x
  • Moodle 1.9

For those of you who are not familiar with Moodle, it is a is a course management system (CMS) – a free, Open Source software package that allows educators to create and manage online learning communities. 

What makes Matthias’ white paper so nice is that documentation for installing and configuring Moodle to work with IIS has been pretty minimal – and may be particularly challenging to implement on the x64 platform.  FYI, you can find a 64-bit version of PHP here.

Howto: Uninstall the SLES Virtual Machine Driver Pack for Windows on Xen


Disclaimer: I recently fell off the turnip truck with respect to Xen, the virtualization platform included with SLES 10. All my past virtualization experience has been with VMware or Virtual Server, so this may be blatantly obvious to the rest of the IT world…

We are running Groupwise Mobile Server (GMS) on a Windows Server 2003 R2 guest loaded on a Xen/SLES10 Linux server. The GMS keeps bluescreening every time a user attempts to sync a Palm (but not iPAQ/PocketPC) device. The BSOD says the problem lies with ndis.sys, the guest’s nic driver. It was suggested to us to uninstall the paravirtualization driver pack to see if the problem kept occuring.

Little did we know that actually figuring out how to uninstall the driver pack from the Windows guest would be so difficult. I thought I could go into Yast on the host or Add/Remove programs on the guest to uninstall and that would take care of it, but that was not the case.

To uninstall the paravirtualization drivers on the Windows guest:

1 Make sure the installation CD is detached from the virtual machine.

2 Browse to c:\Program Files\Novell\XenDrv

3 Double-click uninstall.exe

You will be prompted to reboot the system.

4 Close all applications that are running and click OK

The system restarts. The Found New Hardware Wizard appears, indicating that it has found new hardware.
5 Click Yes, this time only, then click Next. The wizard asks to install software for the PCI Device.

6 Click Cancel.

The driver pack is now uninstalled from your system.

This also may seem blatantly obvious, but once the driver pack is completely uninstalled from your guest OS, you’ll lose the benefits of the paravirtualized drivers.

On a related note, if you want to upgrade the Driver Pack, you need to uninstall the current pack before you install the new one.

Since we uninstalled the driver pack the VM hasn’t blue screened once, which is good. But I’m bummed about not getting the benefits of the paravirtualized drivers. If anyone has any idea how to solve this, I’d love to hear about it at thebackroomtech[at]gmail[dot]com

Howto: Migrate file shares, permissions, and user profiles paths in a Windows 2003 domain


I’m in the process of migrating from serv1, a Windows 2003 Domain Controller (DC) to serv2, a new Windows 2003 DC.  Serv1 has approximately 185 student accounts and 5 staff accounts.  Each user has their own shared folder on the server which is defined in Active Directory Users and Computers (ADU&C) user account profile path.  There are a handfull of other shares that need to be migrated as well. 

I decided on the following requirements and stipulations for my migration solution in this particular scenario:

1)  Make an effort to use only freeware or shareware tools whenever possible.

2)  The user home directories (defined by the user profile path) needed to be copied to the new server, but the data inside their home directories was not to be retained on the new server.

3)  I was not going to reshare each folder once it was migrated, so I needed some other method of redefinng the shares on serv2.  I needed the share permissions migrated as well

4)  Existing NTFS  permissions for user home directories needed to applied on serv2.

5)  The user profile path had to be updated in ACU&C from \\serv1\users\%username% to \\serv2\users\%username%

6)  The drive letter location of all the user’s home directories was being changed from c:\users\%username% (on serv1) to e:\users\%username% (on serv2).

I took the time to come up with this methodology since I have to do this type of server migration all the time.  This should also work for migrating from Windows 2000 to Windows 2003.  Here’s my solution:

I initially planned on using the Microsoft File Server Migration Toolkit to migrate from serv1 to serv2, but I found it to be very clunky and not very configurable.  It kind of seemed like it was a migration tool for dummies without any advanced options that would confuse Joe Admin.  I played around with it for about an hour before detrmining it was not the solution for me.

The next path I wandered down was to use Robocopy (with the optional GUI) to copy my \\serv1\users directory to \\serv2\users.  Robocopy is a part of the Windows 2003 Resource Kit Tools, and Robocopy GUI is available from the Technet Magazine November 2006 Utility Spotlight.

Robocopy has a ton of options available, which is why the GUI comes in handy.  I originally planned to copy the \\serv1\users data to \\serv2\users using the syntax found in KB323275, but it never behaved quite as expected.

I tried to execute Robocopy in the following manner (type on all one line), expecting the directory tree structure to copy one folder down (LEV:1) from \\serv1\users, but it only copied the files located in \\serv1\users, but no directories. 

robocopy.exe \\serv1\users \\serv2\users /COPYALL /LEV:1 /ZB /V /FP /W:5 /R:5 /LOG:copy.log

So I changed /LEV:1 to /LEV:2, and it copied the directory structure \\serv1\users\%username%, plus the data in the %username% folder, which was not what I wanted (again, type as one line)

robocopy.exe \\serv1\users \\serv2\users /COPYALL /LEV:2 /ZB /V /FP /W:5 /R:5 /LOG:copy.log

Robocopy frustrated the hell out of me, so I moved on to try xxcopy.exe, which is very similar to Robocopy.  I briefly perused the author’s web site and saw “freeware version”, so I started working with it.  Not until I received error messages about copying between remote shares did I notice the freeware version of xxcopy.exe was for personal property use only – since I don’t own this network, I was not allowed to use the free version per their licensing agreement – so I needed a new direction once again.

I finally resorted to using the good ole Windows xcopy.exe (see KB 289483 and KB 323007 for usage and options) to copy my directory structure from within the source users directory to the destination users directory:

xcopy *.* /T y:\users

This worked too well – it copied all subdirectories, which is definitely not what we wanted.

I was frustrated with my lack of progress, so I went back to my second robocopy, which copied the correct directory structure, but also copied the files within the directories.

robocopy.exe \\serv1\users \\serv2\users /COPYALL /LEV:2 /ZB /V /FP /W:5 /R:5 /LOG:copy.log

Next I used del.exe from within the \\serv2\users in order to delete all the files (but not folders) within the \\serv2\users\%username% structure:

del.exe *.* /f /s /q

This worked great, but did not remove hidden files.  In order to remove the hidden files, I had to do the following:

del.exe *.* /f /s /q /ah

Now I finally had the correct directory structure on \\serv2\users.  I could move on to copying the share permissions, since Robocopy.exe had copied the folder permissions for me when I used the  /copyall option.

Microsoft’s official method of migrating shares from one server to another is documented in KB125996, which requires a export of the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Shares from \\serv1, and the importing of that resultant .reg file into \\serv2.

That process works great as long as the same drive letters are used on both servers.  In my case, c:\users was the source on \\serv1, which e:\users would be the share location on the destination \\serv2.  If you look at the exported .reg file, it’s not in a human readable format, its a bunch of hex numbers.  I hoped I could do a find and replace using a hex editor to change c:\users to e:\users in my exported .reg file, but that was another huge waste of time.

Finally I came across jv16 Powertools 2007, which I installed on \\serv2.  I imported the .reg file from \\serv1 into \\serv2, then ran the Registry Find and Replace utility, and replaced all instances of c:\users\ with e:\users\.  I rebooted \\serv2, and my 190 (or so) shared folders magically appeared!  Finally, I was making progress!

(As a side note, I recommend supporting the developer of this utility, and will be purchasing the $59 commercial license.  Personal licenses are $29.95.  I will gladly pay the $59 rather than have to recreate each share on \\serv2 by hand.)

Finally, I needed to change each of the user’s profile paths in Active Directory Users and Computers from  \\serv1\users\%username% to \\serv2\users\%username%.  I had no desire to edit each account by hand, so I searched for a solution and came up with ADModify.net, which I was faintly familiar with as an Exchange tool.

ADModify is very intuitive to use.  You’ll need to select the domain and source DC, then make sure the “show only users” check box is selected and “show containers only” in de-selected.  Click the green arrow box and expand your domain, and the list of OUs are displayed.  Expand the OU your users reside in and highlight the users whose profile path you’d like to modify.  The only slight roadblock I came acrosss using this utility was that I had to select my users once again from the right most pane before I could press next.

Once you press next, the familiar ADU&C interface appears.  I went to the Profiles tab, and selected the Profile Path check box, then entered \\serv2\users\%username% as the path to the profile.  I pressed the Go button, and all of my user’s profile paths were changed!  My migration was finally complete.

[update 11-09-2007]

KB 310316 describes a registry modification that can be made to modify how Windows Explorer handles permissions when objects are copied or moved to another NTFS volume. When you copy or move an object to another volume, the object inherits the permissions of its new folder. If you want to modify this behavior to preserve the original permissions, follow the instructions to modify the registry.

KB 174273 describes how to use scopy.exe to copy NTFS files or directory structures while maintaining NTFS permissions and restoring Share Level permissions. This method includes copying between partitions, hard drives, or computers.  It also briefly mentions using PermCopy.exe, a command-line utility that copies share-level permissions (access control lists [ACLs]) from one share to another.

If you’re using scopy to copy local group permissions to other domains, read KB 168470 regarding potential access problems with the trusting domain.

If you use some other solution to copy your data to it’s new location but still want to copy NTFS file system access control lists (ACLs), check out KB 323275 for how to do this with Robocopy.