Automatically appending the time and date to text files using Notepad

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I found this little nugget of information which may be useful for anyone looking to automatically append the time and date to a text file each time it is edited with Notepad.

According to the Made with Notepad campaign website, it works for versions of Notepad from Windows 95 onwards, and I have tested it on Windows XP Professional (SP2).

Simply start the text file with .LOG and save. From then on, the current date and time will be added to the end of the document each time it is opened in Notepad.

Windows AutoPlay on a USB flash drive

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve been looking at using the AutoPlay functionality in Windows to launch an HTML document each time I insert a USB flash drive. Controlled using a file called autorun.inf, AutoPlay is designed for CDs, but I see no reason why it should not work with other removable media.

There is an excellent overview of the autorun.inf file on the Moon Valley Software website. Although autorun.inf files are easy to edit using a standard text editor such as Notepad, the Moon Valley Autorun.inf Editor is a free download from the Moon Valley Software website, which includes a particularly useful feature to locate and display icon resources within a .DLL.

Using this, I soon had a file which changed the icon and name for the USB flash drive when I inserted it, but I could not get it to automatically launch an HTML document.

After some searching (most notably a TechRepublic post), I discovered that the open command in autorun.inf only recognises programs. Windows 2000 and later recognise the shellexecute command to open other file types, for example:

[autorun]shellexecute=index.html

Once open= is replaced with shellexecute=, the context menu in Windows Explorer recognises index.html as the default action for the device, but for some reason it does not launch when I insert the USB flash drive into either of the PCs I’m using today. I checked out Microsoft knowledge base articles 155217 and 314855 but found the PCs were correctly configured to AutoPlay.

Searching the ‘net brought up a host of utilities (some free, some not) which are designed to extend the AutoPlay functionality, but by far the most useful utility was autorun.exe (a free download from the Tarma Software Research website, not to be confused with Peter Harrison’s AutoRun from the imagespro.com website). I found that autorun.exe would execute the commands in my autorun.inf file, but still not automatically launch when the USB flash drive was inserted.

New commands in recent Windows releases

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

This morning, I discovered a new command in Windows XP (and Windows Server 2003) – systeminfo.exe allows an administrator to query a local or remote computer for basic system configuration information.

Additionally, the TweakXP.com website suggests a useful method of restricting the output from systeminfo.exe so that only certain information is displayed, by piping it through find.exe. Deepak Sharma posted similar information on his weblog, but also points towards Microsoft’s uptime reliability and availability information tool (uptime.exe), a Windows NT download (that also works on XP).

After some more research, I found that systeminfo.exe is just one of a few new commands in recent versions of Windows and full details may be found in the %windir%\help\ntcmds.chm file.

Windows XP SP2 RDP client now available for legacy versions of Windows

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Microsoft have released an updated Remote Desktop Connection (formerly Terminal Services) client for Windows 95, Windows 98, Windows ME, Windows NT 4.0 or Windows 2000. This is the same version as is included with Windows XP service pack 2 (v6.0.2600.0).

Useful TCP and UDP port numbers

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Having spent the afternoon configuring Windows Firewall exceptions, I thought I’d post some links to useful port number information.

Of course, %systemroot%\system32\drivers\etc\services contains port numbers for well-known services defined by IANA, but this is an incomplete list and the up-to-date version is on the IANA website.

Although now out of date (superseded by the RFC 3232 online database), the missing table of contents for RFC 1700 (assigned numbers) provides links to a pile of useful information that doesn’t seem to be covered in RFC 3232. This information is not just from the RFC and includes links to items such as country codes from ISO 3166, although a more up-to-date list of country codes is available on the ISO website (note that the ISO country codes do not necessarily equate to the top level domain codes, e.g. United Kingdom is GB in ISO 3166, but both GB and UK on the IANA website).

Finally, the ISS website has details of commonly used ports (along with some descriptive information) for Microsoft services as well as other vendors.

Trying to suss out what SUS is up to?

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I found a useful script on the SUSserver.com website for detecting and interpreting the automatic updates client registry settings.

Microsoft Scripting Host (Monad)

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few weeks back I published a post about Microsoft’s plans to withdraw support for VBscript. One of my clients tipped me off a couple of days back with some more information about the new Microsoft Scripting Host (MSH) shell – codenamed Monad, which will be included in the Windows Server product codenamed Longhorn.

Windows and .NET Magazine reports that:

“Monad is a new administration scripting and automation solution for Longhorn. Although the technology is roughly 2 years away from being released, Monad appears to be Microsoft’s long-awaited comprehensive, consistent, and unified systems administration model designed from the ground up for Windows IT professionals…Monad will be the technology through which Microsoft and Independent Software Vendors (ISVs) will enable their Windows applications to be managed from the command line and automated using shell scripts.”

Problems with Microsoft clusters

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few weeks back I was trying to configure a Windows 2000 cluster for a client. Nothing too unusual about that, but we still came across a couple of issues:

Firstly, the shared disk was on a SAN, with Veritas Volume Manager providing dynamic multi-path support. Veritas’ document describing how Volume Manager works with Microsoft Cluster Server suggests that once the Microsoft Cluster service is installed, it is possible to modify an existing Volume Manager installation to install the Volume Manager DLLs. We found that it is not enough for the Cluster service to be installed (i.e. present but without the Cluster Service Installation Wizard having been run) – the cluster has to be fully configured before the Volume Manager MSCS Support will install correctly;

The second issue was far more difficult to diagnose. We had a problem whereby the first cluster node would install without issue; however when we attempted to join the second node to the cluster it would fail and report the following message in %systemroot%\cluster.log:

[JOIN] Unable to get join version data from sponsor xxx.xxx.xxx.xxx using NTLM package, status 5.

The problem turned out to be related to the password length for the Cluster service account. When you set or change a password, Windows generates both a LAN Manager Hash (LM hash) and a Microsoft Windows NT hash (NT hash) of the password. These hashes are stored in the local Security Accounts Manager (SAM) database or in Active Directory; however LM hashes are relatively weak and are often disabled for security reasons, as described in Microsoft Knowledge Base article 299656.

Our Active Directory was running under Windows Server 2003 (albeit in Windows 2000 mixed mode), and because Windows Server 2003 is more secure by default, it does not store LM hash values for passwords.

According to Microsoft Knowledge Base article 272129, all cluster authentication is handled internally to the Cluster service. The only time the Cluster service contacts a domain controller for authentication is to validate the Cluster service account when the cluster is first formed. Every node that requests to join a cluster is validated using RPC communication over the private network by the node that owns the quorum resource. Only LM or NTLM authentication is used for this (i.e. not NTLM v2 or Kerberos).

According to Microsoft Knowledge Base article 828861, if a password of less than 15 characters is used for the Cluster service account, the setup process generates an LM hash to build a session key to authenticate whilst attempting to join the second node to the cluster. Because no LM hash is stored in Active Directory, the domain controller cannot build a matching session key and access is denied; however, when a password that has 15 or more characters is used for the cluster service account, the setup process cannot generate an LM hash and a Windows NT password hash is used to derive the session key instead. The domain controller is able to generate a matching session key and authentication succeeds.

The result of all this is that the Cluster service account must use a password that contains 15 characters or greater.

Incidentally, there is a really useful best practice guide for installing the Microsoft Cluster service on the Microsoft website. Microsoft Knowledge Base article 278007 describes some of the new features in Windows Server 2003 clusters in comparison with Microsoft Windows 2000 Advanced Server and Microsoft Windows 2000 Datacenter Server.

Microsoft to withdraw support for VBscript

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

OK, we’ve all heard of Microsoft trying to withdraw support for a product (NT 4.0 anybody?), but at a recent partner event they stated that support for VBscript is to be phased out. Apparently there is a replacement product codenamed Monad, which will allow the scripting of console applications. When I pushed for timescales, I was told that it won’t be tomorrow, but could be as soon as 12-18 months before VBscript is withdrawn.

Expect to see an outcry soon from Windows system administrators everywhere!

Scripting page file modifications for Windows 2000, XP and Server 2003

This content is 21 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A useful new feature of Windows XP and Windows Server 2003 is the PagefileConfig utility (pagefileconfig.vbs) which enables an administrator to display and configure a system’s virtual memory settings from the command line.

As this new feature is implemented as a Visual Basic script, I tried it on Windows Server 2000 and it works – with one proviso – before running the script, I needed to copy the cmdlib.wsc windows script component from Windows Server 2003 and register it (regsvr32 cmdlib.wsc /s). Just to be sure about the state of my Windows 2000 server, once the page file modifications had been made, I unregistered cmdlib.wsc (regsvr32 /u cmdlib.wsc /s) and deleted the file.

Of course, on useful parameter to have when scripting page file operations is the amount of physical RAM installed in the computer. For this, I used the getram.vbs script from Rob van der Woude’s scripting pages.