Tracking Windows server product licenses

Posted on By Mark Wilson
This content is 19 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 just had a call from a client who was concerned that he couldn’t add client access licences (CALs ) for his new Exchange Server in the Licensing administrative tool. I’ve never really used this tool so I had to do some research before I could answer his question. Microsoft knowledge base article 824196 describes the license logging service (LLS) but the key points to note are all in the article summary:

  • LLS was originally designed to help administrators manage licenses for Microsoft server products that are licensed on a per-server basis (the server CAL model).
  • LLS was introduced with Windows NT Server 3.51 but it is disabled by default in Windows Server 2003.
  • Because of design constraints and evolving licencing terms, LLS cannot provide an accurate view of the total number of per-user CALs purchased, compared with the total number of CALs that are used on a single server or across the enterprise.
  • LLS will not be included in future versions of the Windows operating system.

Basically, it seems that LLS is a hangover from Windows NT and nowadays there is no real reason to use it in Windows Server 2003.

Problems accessing the Virtual Server administration website on a Windows Server 2003 domain controller

Posted on By Mark Wilson
This content is 19 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.

Although I have several computers at home, most of my server roles are running on a single PC. That means Active Directory (AD) domain controller (DC), DNS, DHCP, RIS, WSUS, and print services are all on one box (file services are on my NSLU2) so I figured that adding Virtual Server 2005 R2 to the mix shouldn’t be too big a problem. It’s certainly not good practice, but it works.

Another bad practice is to run internet information services (IIS) on a DC, but I already have IIS installed for WSUS, so adding the Virtual Server administration website should have been reasonably straightforward. Following installation, existing websites on the server were working as expected but any attempt to access the Virtual Server 2005 administration website resulted in an HTTP Error 403 – Forbidden: Access is denied. message, despite entering the domain administrator credentials when prompted (and already being logged on as the domain administrator).

From checking the event log, I found that Virtual Server was logging the following event on startup:

Event Type: Warning
Event Source: Virtual Server
Event Category: Virtual Server
Event ID: 1130
Date: 01/05/2006
Time: 15:28:23
User: NT AUTHORITY\NETWORK SERVICE
Computer: SERVER1
Description:
The service principal names for Virtual Server could not be registered. Constrained delegation cannot be used until the SPNs have been registered manually. Error 0x80072098 – Insufficient access rights to perform the operation.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

I tried the steps in Microsoft knowledge base article 890893 but adding the appropriate SPNs to AD didn’t seem to make any difference.

A bit of Googling turned up a blog entry from David Wang which although not completely relevant, contained a reference to a similar problem in the comments. Sure enough, when I checked the IIS logs, the error code was 403 19, as shown below:

#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
2006-05-01 21:29:39 W3SVC2 ipaddress GET /VirtualServer/VSWebApp.exe view=1 1024 domainname\Administrator ipaddress Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322) 403 19 1314

I tried David’s advice of switching the IIS DefaultAppPool identity to LocalSystem and that worked (LocalSystem is a very highly-privileged account), but (despite my lackadaisical approach to co-hosting services and the probably security implications) I didn’t really feel that it was an ideal solution and I switched back to Network Service. I then set about trying to work out why the Network Service account (NT AUTHORITY\NETWORK SERVICE) didn’t have the appropriate permissions. Microsoft knowledge base article 332097 looked as if it might be relevant (Microsoft knowledge base article 842493 is similar) but didn’t seem to solve the problem (in any case the IIS_WPG group already had the correct permissions) so I fired up the Local Security Settings MMC snap-in and checked out the user rights assignment in the local security policy.

Because my IIS server is also a DC, many of the user rights normally associated with the Network Service account had been removed (and were overridden by the Default Domain Controllers Policy). NT AUTHORITY\NETWORK SERVICE was also missing from the IIS worker process group (IIS_WPG) membership (and could not be added as it is a local account) so I edited the local security policy and the Default Domain Controllers Policy (another bad practice – I should really have created a new policy for DCs running IIS) as follows:

  • Replace a process-level token (Default Domain Controllers Policy).
  • Adjust memory quotas for a process (Default Domain Controllers Policy).
  • Generate security audits (Default Domain Controllers Policy).
  • Log on as a batch job (Default Domain Controllers Policy).
  • Impersonate a client after authentication (local security policy).

The following user rights were already in existence:

  • Bypass traverse checking (inherited from Everyone).
  • Access this computer from the network (inherited from Everyone).
  • Log on as a service (Default Domain Controllers Policy).

After forcing a group policy refresh (using gpupdate /force) and issuing the iisreset command, I was able to access the Virtual Server administration website as expected; although the event 1130 warnings are still being recorded in the event log, along with event 1129 since I enabled the virtual machine remote control (VMRC) server:

Event Type: Warning
Event Source: Virtual Server
Event Category: Remote Control
Event ID: 1029
Date: 04/05/2006
Time: 21:19:18
User: NT AUTHORITY\NETWORK SERVICE
Computer: SERVER1
Description:
The service principal name for the VMRC server could not be registered. Automatic authentication will always use NTLM authentication. Error 0x80072098 – Insufficient access rights to perform the operation.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

I stress that running multiple services on a single PC (even with proper server hardware) is not a good idea; nor is running IIS on a DC; and neither is editing either the Default Domain Policy or the Default Domain Controllers Policy. If you need to do it though, hopefully these notes will help to work out why processes that rely on the Network Service account are not working as they should.

Windows Server 2003 Service Pack 1 overview

Posted on By Mark Wilson
This content is 19 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 meaning to write about the new functionality in Windows Server 2003 service pack 1 (SP1) for a while now, but various distractions led to this post sitting on ice for several months. I thought about dropping it altogether, but then I changed my mind because even though Windows Server 2003 release 2 (R2) is now generally available, SP1 information is still pertinent for two reasons:

  • R2 is installed on top of an SP1 baseline.
  • Many organisations will wait before implementing R2 – so SP1 is still highly relevant to a large chunk of the market (especially those still using Windows 2000, many of whom were waiting for the first Windows Server 2003 service pack before upgrading).

At last year’s Microsoft Technical Roadshow, John Howard presented a Windows Server 2003 SP1 technical overview session, at which he explained that, like Windows XP SP2, Windows Server 2003 SP1 is basically a security update. In producing SP1, Microsoft’s goal and vision was to respond to customer challenges around security, reliability and performance, making it simple both to cope with current threats and to secure a system ready for future threats. Robustness is addressed through some changes to increase performance (e.g. http.sys now runs in kernel mode for IIS servers) and reliability is about allowing systems operation with the minimum of downtime. Most importantly, tools like the security configuration wizard can be used to decrease the attack surface, exposing fewer ports and services so that organisations that have disabled a potentially vulnerable service can patch at their leisure, rather than having to schedule emergency downtime to cope with a major threat.

SP1 addresses security concerns with a number of new features, which I’ll describe in the rest of this post.

Data execution prevention (DEP) is implemented both in hardware – where no execute (NX) support is provided – and in software (functional on any process supporting Windows Server 2003). Controlled using a boot.ini /noexecute=policylevel switch, four policy levels can be selected:

  • OptIn – hardware DEP on, applications can select whether or not to use it.
  • OptOut – DEP is on, unless an application opts out.
  • AlwaysOn – DEP is on (for all applications).
  • AlwaysOff – DEP is off (for all applications).

As for many boot.ini file settings, this DEP can also be controlled through the GUI (system properties).

Post setup security updates (PSSU) is a feature designed to protect servers between the first boot and application of the most recent security updates, opening on the first administrative logon (if Windows Firewall was not explicitly enabled using an unattended installation or group policy) and blocking all inbound connections until the PSSU dialog box is completed (at which time all updates will have been applied).

PSSU offers links to install critical security updates (from Windows Update), as well as the opportunity to configure automatic updates and will re-open on the next login if not fully completed before the computer is restarted (or if forced to close using Alt and F4, which will leave the Firewall enabled). PSSU is invoked during a slipstreamed installation, but is not applied when existing servers are upgraded or when the Windows Firewall is enabled or disabled through group policy.

Unlike Windows XP SP2, the Windows Firewall is not enabled by default on Windows Server 2003 SP1 (unless PSSU is in effect). Microsoft say that this is because the primary purpose of a server is to accept inbound connections, although I would counter this by saying that the software should be secure by default and an administrator should have to take action to open ports and allow services. The boot-time security provided by the firewall is non-configurable, offering basic networking only (domain controller lookup, DHCP client, etc.) until the server is fully online. Like the XP SP2 firewall, multiple network profiles are supported (e.g. more aggressive control when away from the corporate network) and is the Windows Server 2003 SP1 firewall is integrated with the netsh command line utility.

Role-based configuration and lockdown is facilitated with the security configuration wizard (SCW). Although best practice, many administrators view reducing the attack surface on a server as difficult, time consuming, risky (services might be broken) and involving a whole load of documentation to review. Using the SCW, the process is simplified, using a role-based metaphor to disable unnecessary services and IIS web extensions, block unused ports, secure open ports using IPSec, reduce protocol exposure and configure audit settings.

SCW can be installed from the Add or Remove Programs Control Panel applet (appwiz.cpl), or by setting scw=on in unattend.txt. Command line support is included (scwcmd), as are rollback (scwcmd rollback), view (scwcmd view) and analysis (scwcmd analyze) capabilities. Although the security policy is not set through group policy, it can be applied to multiple servers as the configuration can be saved to an XML file for re-use (or converted to a group policy using scwcmd transform /p:filename.xml /g:policyname).

Incidentally, best practice would be to avoid saving the configuration file by server name as this would be useful information for a would-be hacker (and can be overwritten by later updates). The SCW viewer is also a good reference for port numbers, etc. used by various Windows services.

Other new security features include IIS 6 metabase auditing, VPN quarantine functionality and Internet Explorer security enhancements (as per Windows XP SP2 – described in the application compatibility testing and mitigation guide). RPC and DCOM are also enhanced (as for XP SP2) to reduce the attack surface with no more anonymous inbound RPC, restrictions on outbound RPC (both of these may be overridden with a registry key) and only administrators can invoke DCOM components remotely.

Another new Windows feature (which I believe NetWare administrators have had for years) is access based (directory) enumeration (ADE). ADE hides directories on a share based on a user’s access rights. The service pack version of ABE needs to be programmatically enabled (John Howard’s blog carries a link to an unsupported Microsoft utility which will enable this) but since SP1 was released, ADE has been made available for download from the Microsoft website with GUI and command line support (abecmd). It is fully described in the accompanying white paper and for those who would like to see a demonstration, John Howard has recorded an ADE blogcast.

I’m sure there are some other enhancements within SP1 that I’ve missed, but these are the major security improvements. Windows Server 2003 was already pretty good and with SP1 it got better. Add Windows Server 2003 R2 to the mix and there are also some great new features.

Configuring a Solaris 10 DHCP client to register with a Windows Server 2003 DNS server

Posted on By Mark Wilson
This content is 19 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.

Last week, I wrote about configuring a hostname for a Solaris 10 DHCP client. Alan Thompson very kindly left a comment on that post about using DHCP to set the hostname on the network (i.e. in the DNS) and I’m pleased to say that it works a treat on my Windows network.

I have a Windows Server 2003 server which acts as my domain controller, DNS server and DHCP server. DHCP is configured to update DNS (always dynamically update DNS A and PTR records, discard them on lease deletion, and to do this for clients that do not request updates) and this was working well for my Windows clients but although my Solaris client (laptop3) had been retrieving IP information from the DHCP server, the DHCP console showed no name for the lease (and so couldn’t update DNS).

By following Sun’s instructions for enabling a Solaris client to request a specific hostname, DHCP was able to register the client’s name in DNS, using the fully qualified domain name as set in the DHCP scope options (option 015 DNS Domain Name).

I tested this using the nslookup laptop3 command, which returned:

Server: dnsserveripaddress
Address: dnsserveripaddress#53

Name: laptop3.domainname
Address: laptop3ipaddress

It’s worth pointing out that Sun’s instructions are not quite correct for Solaris 10 x86, as step 1 is not necessary (the comments in the /etc/default/dhcpagent file explain that, by default, the DHCP agent will try to request the hostname currently associated with the interface performing DHCP); however the other steps were spot on (add inet hostname to /etc/hostname/interface, flush cached DHCP data using pkill dhcpagent and rm /etc/dhcp/ interface.dhc, then reboot), meaning that my Solaris client now participates in my Windows network name resolution.

Telnet issues on Windows Server 2003

Posted on By Mark Wilson
This content is 19 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 spent a good chunk of this morning trying to get the Telnet service working on Windows Server 2003. By default, this service is disabled and configuring the Telnet service to start automatically and then starting the service is straightforward enough, but when I tried to connect, after supplying username and password details, my clients received the following message:

Failure in initializing the telnet session. Shell process may not have been launched.

Telnet Server has closed the connection

Although the troubleshooting advice for Telnet at the Microsoft Windows Server 2003 TechCenter appears reasonably comprehensive, it didn’t detail this message at all; however Microsoft knowledge base article 309523 does – but only for 64-bit versions of Windows. My telnet server is also a domain controller, and as the advice involves demoting and promoting the server, I chose not to try it on a 32-bit version of Windows (a Google search revealed plenty of anecdotal evidence that it doesn’t work).

I had been trying to establish the connection from a Unix client, so thinking that was the issue, I tried telnet locahost from the server itself but received the same result and checking the application event log revealed various entries similar to the following:

Event Type: Error
Event Source: TlntSvr
Event Category: None
Event ID: 4049
Date: 11/01/2006
Time: 10:00:40
User: N/A
Computer: servername
Description: Error in creating CMD process. System Error: A required privilege is not held by the client.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Following the link in this event led me to check for the presence of %windir%\system32\login.cmd

One post on the microsoft.public.windows.server.general newsgroup looked hopeful, suggesting that the Secondary Logon service also needs to be started; however, when I checked, the Secondary Logon service was already running on my server. I restarted the Secondary Logon and Telnet services just in case (that made no difference) but the newsgroup post had got me thinking about the credentials used by the Telnet service (by default, this was NT AUTHORITY\LocalService). I changed the service to start using the Local System account, restarted the Telnet service and it started accepting connections. Just to be sure, I changed the credentials back to NT AUTHORITY\LocalService (which does not need a password) and restarted the service, breaking Telnet again. That confirmed that it was related to the service’s logon credentials and I went back to using the Local System account.

I’m not sure what the security implications of this hack are. Pretty severe I imagine, as membership of the TelnetClients security group doesn’t seem to make any difference to whether my users can logon to the server using Telnet or not, but at least I can get a console connection to my server from a Unix client now (my Windows clients can use RDP).

Wireless security and secure remote access

Posted on By Mark Wilson
This content is 19 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.

Last night, I attended Steve Lamb‘s Microsoft TechNet UK briefing on wireless security and secure remote access. I won’t repeat the entire content here, because Steve has an article in the November/December issue of Microsoft TechNet magazine, entitled improve your web security with encryption and firewall technologies, which, when combined with Kathryn Tewson and Steve Riley’s security watch: a guide to wireless security article, just about covers the content of the event. Having said that, there were a few more snippets that came out during the presentation, which I’ve plagiarised (and extended) in the rest of this post…

Wireless Security

Anyone who needs to secure a Wireless network at home should check out Steve Lamb’s blogcast on securing a wireless router and Windows XP and, although I’ve already linked it above, I’ll repeat that Kathryn Tewson and Steve Riley’s security watch: a guide to wireless security article is also worth a read. Further information is also available on the Microsoft website.

Some additional notes that I took during Steve’s presentation were that:

  • Wireless network keys can be stored on a USB token.
  • Wired equivalent privacy (WEP) is often considered insecure but consider the name – the equivalency part indicates that it offers the same level of security as a wired network. Yes, it can be broken into, but so can a wired network with public access to the building). Wi-Fi Protected Access (WPA) (or preferably WPA2) is better and dynamic WEP is a half-way house, but whatever security is employed, the wireless network still needs to be easy to use.
  • There are sites on the ‘net that will show you how to break a wireless (or other) connection (if you think it’s irresponsible of me to link that site, you could also find it using a search engine, so I figure that it’s better that the methods are well known, than only being known by the bad guys).
  • Contrary to popular belief, there is no point in securing the SSID for a network as it is transmitted unencrypted (even on a network secured with WPA or WPA2). Ditto for media access control (MAC) addresses, which are easily spoofed.
  • Even WPA doesn’t do anything to prevent a denial of service (DoS) attack and WPA2 (802.11i) doesn’t stop all DoS attacks.
  • 802.1x is port-based authentication and applies equally to both wired and wireless networks. It does have weaknesses, including that it will only authenticate the initial connection. In a wireless configuration, man-in-the-middle (MitM) attacks can be guarded against by requiring the WAP to identify itself using certificates (using a group policy object).
  • WEP requires Windows XP. WPA requires Windows XP SP1, WPA2 requires Windows XP SP2 and a hotfix (see Microsoft knowledge base article 893357).
  • The Windows 2000 Internet authentication service (IAS) can be used as the RADIUS server component in a secure wireless deployment; however Windows Server 2003 supports auto-enrolment (which when used for computer and user certificates will make life much easier).
  • Windows XP will (by default) allow access to its nearest access point, even if it is not secure.

Very importantly – if (like I did), you think that your wireless network (e.g. at home) doesn’t need to be secured because there’s no data of value to be had and anyway, you have bandwidth to spare which you don’t mind your neighbours using, consider the implications of someone using your wireless network to access the Internet and perform illegal activities, which your ISP can trace back to you via your IP address. Having thought about that, I’ll be buying a new wireless access point very soon.

Secure Remote Access

Microsoft are positioning virtual private networking (VPN) technology as no longer the best solution for providing corporate remote access and I tend to agree. The idea of giving an untrusted computer an IP address from the internal network fills me with fear (unless some quarantining is in place). VPNs “blur” the network edge and anyway, do remote users need full network access? I’ve often accidentally printed a document in the office whilst working at home and then had to ask a colleague to retrieve and dispose of it for me (wasting paper, printer resources and somebody else’s time). Some solutions will use VLAN technology to limit the network access for VPN users – there are other methods too, especially when considering that 90% of VPN users only really want to read their e-mail. For example, Outlook Web Access, whilst having improved it’s interface capabilities dramatically with each new release, is still not really a great solution for access from outside the corporate firewall (it’s good for allowing users to access mail without setting up a MAPI profile, but is heavily reliant on ActiveX controls, which may not be allowed in an Internet cafe, and is also a risk if the remote client has a keylogger installed) – full client Outlook using HTTPS over RPC on a notebook/tablet PC is a far better option – totally transparent from an end user perspective (although still a problem if access is required if an e-mail links back to internal resources to retrieve a document).

Steve Lamb’s TechNet magazine article (and my previous post on securing the network using Microsoft ISA Server 2004) elaborate on the need for application layer firewalling rather than blindly allowing HTTP and HTTPS traffic through the firewalls. Other measures employed include pre-authentication and URL scanning.

SSL VPNs are another method of providing remote access (even though they are not really VPNs, but are actually just remote desktops in a browser). Windows Terminal Services can provide basic SSL VPN functionality, which can also be extended with products from Citrix.

Operating over the remote desktop protocol (RDP), which is based on the International Telecommunications Union (ITU) T.120 protocol family and is therefore independent of network and transport protocols, these solutions use compression and caching to reduce bandwidth requirements and support network load balancing. Windows Server 2003 brings a number of terminal services enhancements (over Windows 2000) including:

  • Connection to the console session (in remote administration mode).
  • Control of RDP options via group policy.
  • WMI provider for scripted terminal services configuration.
  • ADSI provider for access to per-user terminal services profiles.
  • Improvements to the terminal server manager MMC snap-in (reduced automatic server enumeration).
  • Ability to limit users to a single session.
  • Improved security:
    • Remote Desktop Users security group (which can be used in place of the Everyone group to fine tune access control.
    • 128-bit RC4 encryption.

Securing terminal services comes back to the well-known principle of defence in depth:

  • A physically secure terminal services server.
  • A secure operating system configuration.
  • A secure terminal services configuration.
  • Network path security.
  • Using the registry to fine-tune control over terminal server sessions (probably overkill, but using group policy to control access is a similar principle).

Using the remote desktop web connection ActiveX control, terminal services can be provided across the web (and optionally secured using HTTPS). The initial client contact is to http(s)://servername/tsweb/ and the ActiveX control is downloaded over HTTP (TCP port 80) or HTTPS (TCP port 443). Once the browser has the ActiveX control installed, the user can connect to the terminal server over TCP port 3389.

If full VPN access is still required (and hopefully the methods above will avoid the requirement for this), then VPN server placement must be carefully considered. Running an encrypted PPTP or L2TP+IPSec VPN connection through a standard packet filtering firewall effectively bypasses the firewall as the VPN port will be open on internal and external firewalls and the traffic inside the connection will not be inspected.

Most network administrators will be alarmed if you propose the installation of ISA Server as the corporate firewall even though ISA Server 2004 has now achieved common criteria evaluation assurance level 4+. ISA Server 2004 is a perfectly good firewall (assuming that the underlying Windows platform is also well-managed), but it will probably be easier to justify to network administrators by using ISA as an additional server in the DMZ, or as the inner firewall (between the DMZ and the internal network). This way, the encrypted connection can be terminated at the ISA server and the firewall can inspect the inbound traffic.

Finally, if a VPN connection must be used to extend the corporate network to remote clients, then network quarantine controls should also be put in place. Full network access protection (NAP) is expected with the next version of Windows Server (codenamed Longhorn) but even now, Windows Server 2003 SP1 routing and remote access service (RRAS) allows for the provision of network access quarantine control for remote clients. The current Microsoft implementation involves using the connection manager administration kit (CMAK) to construct a custom RRAS client which includes a number of post-connection actions. Until these are passed, then vendor-specific options remain in place which prevent the remote VPN client from accessing the network. Unfortunately it is also possible for a technically able user to spoof the message which allows the vendor-specific attributes to be removed, but in reality this is a small risk. Microsoft’s NAP and Cisco’s network access control (NAC) will make this far more effective, extending the scope of control to include wired and wireless clients (as well as VPN clients).

Windows Server 2003 R2 is nearly ready

Posted on By Mark Wilson
This content is 19 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.

At today’s “What’s New in Windows Server 2003 R2” partner event, Annemarie Duffy, Microsoft UK’s Infrastructure Server Marketing Manager, first commented that Windows Server 2003 release 2 (R2) is “imminent” and then said that it is planned for release to manufacturing (RTM) within the next few days.

R2 is what Microsoft are calling a release update – released at approximately the mid point between major releases, as part what Microsoft calls its “predictable development lifecycle” (Windows Server 2003 was released in 2003 and the current estimated release date for the Windows Server product codenamed Longhorn is 2007). Microsoft claims that the R2 improvements build on Windows Server 2003 with service pack 1, supporting the organisation, customers, suppliers and partners through five pillars which provide new functionality to extend connectivity and control:

  • Identity management – Allowing the management of a single identity across partner, web and Unix applications.
  • Branch/remote office – Better connectivity, reliability and up to a 50% WAN traffic reduction.
  • Storage management – Better control over storage setup and a 10% lower management cost.
  • Web application platform – Latest 64-bit and Microsoft.Net technologies for doubling web application performance.
  • Virtualisation – Windows Server 2003 R2 Enterprise Edition and Virtual Server 2005 R2 represent the best value in server virtualisation with licensing now based on the maximum number of active virtual machines and not the number of images held, in addition to the inclusion of licenses for up to four guest instances of Windows Server 2003 R2 with each host.

(Note that these claims are from Microsoft’s marketing slides, and are not my comments).

Whilst Windows Server 2003 R2 will replace the existing Windows Server 2003 product with immediate effect, all of the new components are optional (and are actually installed from a second CD on top of an existing Windows Server 2003 installation with service pack 1 slipstreamed). This reduces the impact on organisations from a testing perspective, and is one of the reasons that this release update is not expected to include any kernel changes.

In terms of pricing and availability, if RTM is achieved next week then general customer availability should be around February 2006. Windows Server 2003 R2 is expected to be priced identically to Windows Server 2003 but there will be no upgrade SKU for existing licensed users. There will be no upgrade charge for Microsoft customers with software assurance (SA), e.g. as part of an enterprise agreement (EA), although a new server licence will be required for non-SA customers who plan to upgrade; however existing Windows Server client access licences (CALs) will remain valid (i.e. there will be no new R2 client licence). R2 will also share the same support lifecycle as Windows Server 2003 (i.e. extended support will end in 2013).

Watch this space for more information about some of the new features in R2 (basically as soon as I find time to write about them!). I’m particularly excited by the new licensing arrangements for virtualisation, the new print management capabilities, the new quota and file screening capabilities and the upgraded distributed file system (DFS) functionality, including remote differential compression (RDC). Active Directory federation services (ADFS), improved Unix interoperability and the updates to Active Directory application mode (ADAM) are also significant identity management enhancements and some of the figures quoted in relation to 64-bit computing support will definitely be worth investigating (especially with the rumours of Intel and AMD’s plans to move to an exclusively 64-bit platforms by the end of 2006 and Microsoft’s plans to make the Longhorn Server wave of products 64-bit only).

Finally, for those who want to know more and can’t wait for me to put aside some time with my keyboard, Microsoft is running a TechNet UK event next Wednesday evening (7 December 2005) at which Samm DiStasio (Director of the Windows Server Product Management Group, Microsoft Corporation) and Microsoft UK’s John Howard will present an introduction to Windows Server 2003 R2.

Using RIS to PXE boot non-Windows images

Posted on By Mark Wilson
This content is 19 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 written a few posts previously for this blog about Microsoft Remote Installation Services (RIS), but today I needed to do something I knew was possible in theory but had never done before – using RIS to serve a boot image of something that’s not an unattended Windows setup.

Although slightly complicated by the need to use Active Directory for security, RIS is, at its most basic, a PXE server, capable of serving boot images via TFTP to suitable client PCs (before an operating system is loaded). In theory, any bootable floppy can be converted into a RIS boot image file but Microsoft doesn’t provide the tools – for that you will need the 3Com RIS Menu Editor (RISME). The original version of this is a free download from 3Com – later versions (e.g. emBoot RIS Menu Editor 2.0) are available for a small price (with a free trial period) but I found the 3Com version to be perfectly adequate (although it only runs locally on a Windows 2000 RIS server, whereas v2.0 of the emBoot product allows remote creation and editing of RIS menus and boot images, and supports Windows Server 2003).

After running RISME to capture an image from boot media, an additional folder structure will have been created on the RIS server, either in \\servername\RemInst\Setup\English\Images\3com\i386\ or in \\servername\RemInst\Setup\English\Tools\3com\i386\, depending on whether or not the image was created via the Automatic Setup or the Maintenance and Troubleshooting tabs.

Along with the image (.IMG) file (which can be edited directly using a utility such as WinImage), is an appropriate boot loader (.LDR) file and a RIS setup information (.SIF) file containing something similar to the following text:

[OSChooser]
Description = "description"
Help = "helptext"
LaunchFile = "Setup\English\Images\3Com\i386\tool1.ldr"
Version = "1.00"
ImageType=Flat

RIS should automatically pick up the new .SIF file and offer it as a menu choice in the OS Choices menu although it may be necessary to edit the User Configuration | Remote Installation Services | Choice Options within the Default Domain Policy group policy object in Active Directory to allow access to some of the RIS menus (e.g. Maintenance and Troubleshooting).

I now plan to use this method to deploy Ghost images (via an MS-DOS boot disk, captured as an image) and a PXE boot to a RIS server but for more information (including links to enable PXE booting of Linux), check out Google’s cached version of an article on how to use RIS to bootstrap other operating systems (unfortunately the original is no longer available online).

GPMC modelling after upgrading Active Directory

Posted on By Mark Wilson
This content is 19 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.

Earlier today, I came across a interesting hangover from last week’s domain upgrade from Windows 2000 Server to Windows Server 2003.

After installing the group policy management console (GPMC), I was viewing a pre-existing group policy object (GPO) and GPMC notified me that Enterprise Domain Controllers did not have read access to all GPOs in the domain. This was initially worrying, but for once the help link had some useful information at the other end.

It turns out that Windows Server 2003 group policy modelling (simulating the resultant set of policy for a given configuration) is performed by a service that runs on domain controllers and in order to perform the simulation in cross-domain scenarios, the service must have read access to all GPOs in the forest.

In a Windows Server 2003 domain (whether it is upgraded from Windows 2000 or installed as new), the Enterprise Domain Controllers group is automatically given read access to all newly created GPOs. This ensures that the service can read all GPOs in the forest.

However, if the domain was upgraded from Windows 2000, any existing GPOs that were created before the upgrade do not have read access for the Enterprise Domain Controllers group.

GPMC had detected this situation and notified me that Enterprise Domain Controllers do not have read access to all GPOs in this domain and after reading the help text was was directed to use one of the sample scripts provided with GPMC, GrantPermissionOnAllGPOs.wsf to update the permissions for all GPOs in the domain.

Whilst logged on with Domain Admins permissions I simply opened a command prompt, navigated to %programfiles%\gpmc\scripts and issued the command cscript GrantPermissionOnAllGPOs.wsf "Enterprise Domain Controllers" /Permission:Read /Domain:dnsdomainname.

The output was as follows:

C:\Program Files\GPMC\Scripts>Cscript GrantPermissionOnAllGPOs.wsf “Enterprise Domain Controllers” /Permission:Read /Domain:home.local
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

Warning! By executing this script, all GPOs in the target domain will be updated with the desired security setting.

Both the Active Directory and Sysvol portions of the GPO will be updated. This will result in the Sysvol contents of every GPO being copied to all replica domain controllers, and may cause excessive replication traffic in your domain.

If you have slow network links or restricted bandwidth between your domain controllers, you should check the amount of data on the Sysvol that would be replicated before performing this task.

Do you want to proceed? [Y/N]
Y
Updated GPO ‘Default Domain Policy’ to ‘Read’ for Enterprise Domain Controllers
Updated GPO ‘Windows Software Update Services’ to ‘Read’ for Enterprise Domain Controllers
Updated GPO ‘Default Domain Controllers Policy’ to ‘Read’ for Enterprise Domain Controllers

Once this was completed, GPMC was able to function as normal with the existing GPOs.

Setting up IP forwarding on a Windows network

Posted on By Mark Wilson
This content is 19 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.

My network at home has two subnets joined by a wireless link (note that the IP addresses have been changed to protect the innocent):

IP forwarding

You might wonder why it doesn’t all sit under my desk (after all we’re not talking about a multinational corporation here) but the simple fact is that most of my kit has been procured from an eclectic mix of sources over the years (so it is hardly what you might call standard) and the server (on which I do a lot of testing) is a noisy beast, as is the 24-port switch that it’s plugged into – hence the reason they are stored away in the basement.

The trouble with this configuration is that the dual-homed PC which acts as a bridge between the wired and wireless segments in the basement is exactly that – dual-homed – i.e. it needs the 802.3 adapter to be on one subnet and the 802.11b adapter to be on another (otherwise this could all have been on one flat subnet). That means that it also needs to be able to route traffic to and from each subnet, otherwise the server is invisible to the rest of the network (and vice versa).

That’s where IP forwarding comes in (aka IP masquerading in Linux-speak).

Disabled by default in Windows 2000, XP and Server 2003, IP forwarding basically allows a dual-homed host to act as a network bridge. Microsoft knowledge base article 323339 details the registry setting to enable this on Windows Server 2003 – there are other articles for Windows 2000 and XP but they are pretty much identical.

There are, however, a couple of important points to note:

  • Only one interface should have a default gateway. In my case, the default gateway for the bridge’s wired connection is blank.
  • I also had to put a static route to 192.168.2.0/24 on my ADSL router using the IP address of the bridge’s wireless connection as a gateway (so that outbound traffic to the Internet from the 192.168.2.x network has a return path).

For comparison purposes, the routing table on my bridge (192.168.1.50/192.168.2.50) looks like this:

IPv4 Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x10003 ...00 08 02 xx xx xx ...... Intel(R) PRO/100 VM Network Connection
0x10004 ...00 80 c8 xx xx xx ...... D-Link AirPlus DWL-520+ Wireless PCI Adapter
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.50 25
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.1.0 255.255.255.0 192.168.1.50 192.168.1.50 25
192.168.1.50 255.255.255.255 127.0.0.1 127.0.0.1 25
192.168.1.255 255.255.255.255 192.168.1.50 192.168.1.50 25
192.168.2.0 255.255.255.0 192.168.2.50 192.168.2.50 20
192.168.2.50 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.2.255 255.255.255.255 192.168.2.50 192.168.2.50 20
224.0.0.0 240.0.0.0 192.168.1.50 192.168.1.50 25
224.0.0.0 240.0.0.0 192.168.2.50 192.168.2.50 20
255.255.255.255 255.255.255.255 192.168.1.50 192.168.1.50 1
255.255.255.255 255.255.255.255 192.168.2.50 192.168.2.50 1
Default Gateway: 192.168.1.1
===========================================================================
Persistent Routes:
None

Whilst on the ADSL router it looks like this:

Network Destination Netmask NextHop IF Type Origin
0.0.0.0 0.0.0.0 isprouter ppp-0 Indirect Dynamic
127.0.0.0 255.0.0.0 127.0.0.1 lo-0 Direct Dynamic
192.168.1.0 255.255.255.0 192.168.1.1 eth-0 Direct Dynamic
192.168.1.1 255.255.255.255 127.0.0.1 lo-0 Direct Dynamic
192.168.2.0 255.255.255.0 192.168.1.50 eth-0 Indirect Local
isprouter 255.255.255.255 mypublicipaddress ppp-0 Direct Dynamic
mypublicipaddress 255.255.255.255 127.0.0.1 lo-0 Direct Dynamic
btrouter1 255.255.255.255 btrouter2 ppp-0 Direct Dynamic

For the other LAN-connected devices, the important details are that for LAN 1 the default gateway is 192.168.1.1 and for LAN 2 the default gateway is 192.168.2.50.