Decision time for Windows 2000 users – what I really think

Last week, I was fortunate enough to be quoted on the front page of IT Week by Martin Veitch, in his article “Decision Time for Win2000 Users“. Of course, as my wife is a Public Relations Consultant, I understand (and even expect) only a partial quote when a journalist asks for comment, so I’m using my blog to put this into context, as the soundbite which Martin used seems to have surprised some people, including one of Microsoft UK’s Enterprise Strategy Consultants.

Yes, Windows 2000 is still popular. The AssetMetrix Research Labs report, on which Martin’s article is based, notes that between the last quarter of 2003 and the first quarter of 2005 the popularity of Windows 2000 only fell by 4%. However, the real news here is not that clients are sticking with Windows 2000 but that people are finally junking Windows 9x/ME/NT and moving to XP. Windows 9x system usage fell over the same period from 28% to 5%, Windows NT was down slightly (down from 13.5% to 10%) whilst Windows XP usage increased from less than 7% to 38%.

My colleagues and I have worked with many organisations to migrate from Windows 9x and NT to XP; but the reason that Windows 2000 is still in use by 48% of corporate IT environments is that (when patched), it is a stable and reliable platform. Microsoft may have ended support for NT last year, and 2000 is about to go onto extended support but firms are willing to tolerate the risk of not moving, whilst they recoup the investment that they have made. The heady days of the late 1990s “millennium date bug” upgrades are gone and business users are demanding value for money from their IT assets. Many of my clients have moved away from a 3 year write down of desktop PCs to 5 years, or even 7 years in one case (mind you, I’m helping them to move their retail estate from NT 3.51 to XP!). That means that those who took a big leap to implement Active Directory and adopt Windows 2000 are contemplating skipping a release, before they move directly to the next version of Windows (codenamed Longhorn). What I do expect to see over the next year or so is a lack of Windows 2000 device drivers and the consequential hardware issues driving a move to Windows XP and Server 2003 where perhaps corporates are downgrading Windows XP licenses on new PCs to match their Windows 2000 standard operating environments (SOEs).

As for Linux or the new low-cost Mac, well, at the risk of being flamed (or even accused of being sponsored by Microsoft – which incidentally I’m not!), I don’t see any of my customers moving from Windows on the desktop (yet). The education sector may be being forced down an open source route to save money (false economy I say – we should be teaching our children using the software that they will later encounter in the workplace), and consumers/hobbyists will be looking at the best technology, but in the commercial world, the reality is that organisations are not usually interested in the best technology, or even the lowest total cost of ownership (TCO) – a much overused term which is always open to dispute – but are more concerned with deploying software that the majority of users can use with the least retraining whilst minimising licensing costs through volume licensing agreements – by and large that will mean using the Windows platform and the software vendor will be Microsoft!

So what is my real advice for Windows 2000 users?

  1. Build on your Windows 2000 investment and take advantage of new security features by moving to Windows XP (with SP2) and Windows Server 2003 (with SP1) now.
  2. Windows 9x/NT to 2000 was a step change but the move to XP/2003 is less so (and the licensing costs should be minimal for those organisations that already have software assurance).
  3. Don’t wait until Windows Longhorn. This will be another major release, which is not expected until 2006 (client, with the server version following in 2007), after which many organisations will still wait for the first service pack before deploying.
  4. Finally, new technologies (such as Internet Explorer 7.0), with new features and security enhancements will only be available for recent platforms (i.e. those that are still supported by Microsoft).

Troubleshooting DNS on a Windows server

Earlier today, I blogged about some of the tools that are available for monitoring Active Directory (AD) enterprise replication and troubleshooting Windows authentication. Given that AD is so heavily reliant on the domain name system (DNS), it seems logical that I also list some of the tools available for monitoring and troubleshooting DNS issues.

The first port of call is the Windows version of the original Unix DNS lookup tool (nslookup.exe). Typing nslookup at a command prompt enters the nslookup shell, from where issuing the help command will list all of the available options.

The DNS server troubleshooting tool (dnscmd.exe) is a support tool for Windows 2000 Server and Windows Server 2003 (available on the Windows installation media) which allows administration of DNS from a command prompt. It extends and replaces the earlier dnsstat.exe tool provided as part of the Windows NT resource kit. The DNS server troubleshooting tool displays and changes the properties of DNS servers, zones, and resource records, manually modifying properties, creating and deleting zones and resource records, and forcing replication events between DNS server physical memory and DNS databases and data files. Some operations of the tool work at the DNS server level while others work at the zone level. Simply type dnscmd for usage information.

DNS has its own set of performance counters available under the performance monitor DNS object.

The domain controller diagnostic tool (dcdiag.exe) checks DNS functionality as part of its diagnostic tests but the command to specifically test DNS registration (which does not need to be run from a domain controller) is dcdiag /test:registerindns /dnsdomain:domainname.

The network connectivity tester (netdiag.exe) helps to isolate networking and connectivity problems by performing a series of tests to determine the state of a network client to identify and isolate network problems. Parsing the output for “DNS test” will give DNS-specific results. Type netdiag /? for usage information.

DNS debug logging may be set in the DNS server properties and creates a log file at %systemroot%\system32\dns\dns.log for further diagnosis of DNS activity.

Finally, the dnslint.exe support tool allows verification of DNS records for a specified domain name to help diagnose potential causes of incorrect delegation and other common DNS problems, producing an HTML report. Usage information can be obtained by issuing the dnslint /? command.

Troubleshooting Windows authentication with the Microsoft account lockout and management tools

A few weeks back I was at a Microsoft TechNet UK event where John Howard demonstrated the free tools provided by Microsoft to troubleshoot and diagnose account lockout and management issues for Windows NT, 2000 and 2003:

  • acctinfo.dll (also included with the Windows Server 2003 resource kit tools) is installed using the regsvr32 acctinfo.dll command and extends the functionality of the Active Directory users and computers MMC snap-in, with an Additional Account Info page on the user object properties to assist in isolating and troubleshooting account lockouts and to change a user’s password on a domain controller in that user’s site. This extra page contains a variety of information, including:
    • The last time the password was set.
    • Domain password policies.
    • Password expiration date.
    • Lockout status.
    • Last good and bad logons.
  • alockout.dll can be used to create a log file to assist in diagnosing the cause of account lockout problems. It should be copied to the %systemroot%\system32 folder on the computer experiencing the lockout problems (usually a user’s workstation) and the appinit.reg script run to add alockout.dll to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs key. Once the computer is restarted and an account locked out, a log file called alockout.log will be created in the %systemroot%\debug folder. This tool should not be used on servers that host network applications or services (in particular it should not be used on Exchange servers, because it may prevent the Exchange store from starting).
  • aloinfo.exe displays the password age for user accounts to allow determination of accounts which are about to expire in order to anticipate problems before they occur. It is a command prompt tool, with two options:
    • aloinfo /expires /server:servername returns a list of user names followed by the age of their password.
    • aloinfo /stored returns a list of services and the accounts used as well as mapped drives for the currently logged on user.
  • enablekerblog.vbs can be used as a startup script to enable Kerberos logging (as described in Microsoft knowledge base article 262177) on all clients running Windows 2000 or later (it actually sets HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\Kerberos\Parameters\LogLevel to 1, which once removed will disable Kerberos logging). When looking at Kerberos authentication issues, it is worth checking to see that the Kerberos key distribution center service is started on all domain controllers, that time synchronisation is working correctly from the PDC emulator at the root of the forest down to all client machines (Kerberos authentication will fail if the time is skewed by more than 5 minutes by default), and that both Kerberos and LDAP have service location records defined in DNS (check with nslookup _kerberos._udp.domainname and nslookup _ldap._tcp.domainname).
  • eventcombmt.exe (also included with the Windows Server 2003 resource kit tools) searches event logs on multiple computers and collects event records matching specified criteria (useful for gathering specific events from event logs on several different computers to one central location).
  • lockoutstatus.exe (also included with the Windows Server 2003 resource kit tools) determines all the domain controllers that are involved in a lockout of a user in order to assist in gathering the logs. It can be useful in identifying if lockout problems are arising from Active Directory replication issues, as typically this means there will be two or more entries for different domain controllers.
  • nlparse.exe can be used to extract and display desired entries from the netlogon log files generated by lockoutstatus.exe or alockout.dll, parsing the logs for specific return status codes and directing the output to a comma-separated value (.CSV) file. It is also possible to enable netlogon debug logging with the nltest.exe Windows support tool, or via the registry, as described in Microsoft knowledge base article 109626.

Links

Implementing and troubleshooting account lockout (WindowSecurity.com).
Microsoft account lockout and management tools.

MsTsc.Server errors with TSAC ActiveX control

I haven’t used the Terminal Services Web Client for a few years and when I installed it on a Windows 2000 server with the latest updates applied I received an “Object doesn’t support this property or method: ‘MsTsc.Server'” error.

After a bit of research I found that the problem dates back to some security updates from 2002 (for further details, see the Remote Networking Development website and/or Microsoft knowledge base article 328002 and/or Microsoft security bulletins MS02-046 and MS02-047). Downloading the latest Remote Desktop Web Connection fixed the problem and my servers are now available from wherever I happen to be.

Script to disable password expiry for local Windows accounts

One of the shortcomings of the net user command in Windows is the inability to set the password never expires flag on an account (account expiry options can be set, but not password expiry and the full syntax is described in Microsoft knowledge base article 251394).

There are 13 flags on an NT SAM/Active Directory user account which may be manipulated using VBScript (for further details of the 13 flags, see Microsoft’s sample scripts or there is some useful information about the object model at the Motobit Software website).

This script can be used to set the password never expires flag on a specified account. I’ve tested it against the local SAM database on a Windows XP PC, but in theory it should work on all versions of Windows NT (2000, XP, 2003 Server, etc.) and also against Active Directory accounts if you run it on a domain controller.

Command line alternative to the Windows device manager

One of the Microsoft consultants that I have been working with sent me a link to a handy tool today – devcon.exe is a command line alternative to the Windows device manager and full details (including a download link) may be found in Microsoft knowledge base article 311272.