Why IE 7.0 must rely on XP SP2

Posted on By Mark Wilson
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 seen a lot of press coverage over the last week or so about Microsoft’s plans for Internet Explorer (IE) 7.0. One of the major gripes seems to be that it will require Windows XP service pack 2 (SP2).

So what’s wrong with that?

One of the main reasons that people are moving to other browsers (e.g. Firefox) is that IE is perceived as insecure. SP2 is a major security update for the Windows XP desktop operating system. Why provide a new (more secure) browser product to people who do not use the latest security patches on their operating system?

SP2 has been publicly available since August 2004 (6 months ago). The temporary blocking mechanism to hold back automatic SP2 deployment from Windows Update is scheduled to expire on April 12 2005. There is no point in IT Managers burying their heads in the sand and ignoring SP2 any longer. I will concede that Microsoft should have shipped v4.0 of the Application Compatibility Toolkit alongside SP2 (after all, application compatibility is probably the largest barrier to SP2 deployment) but it amazes me that so few organisations have made the move to SP2 after all this time.

For those who are not even using Windows XP, whilst the extra functionality in IE 7.0 may be useful, Microsoft is a product and technology business and it needs to maintain its licensing revenues through getting people to adopt the latest technologies (especially whilst strategic products are being delayed by major security rewrites).

If an older platform is seen “good enough” then fine; but “good enough” shouldn’t just be about functionality – it needs to consider the whole picture – including security. It may be that the risk assessment considers remaining on a legacy (possibly unsupported) platform is more favourable than the risk (and cost) of upgrading. That’s fine too – as long as that risk is acceptable to the business.

My recommendation? Organisations who are using Windows XP should fully test their applications and carry out a controlled upgrade to SP2 as soon as possible. Those who continue to use older operating systems (especially Windows 9x, ME, and NT) should urgently consider upgrading. Then keep patch levels up-to-date, for example, by using Microsoft Software Update Services (SUS) and the Microsoft Baseline Security Analyzer (MBSA). IT users can’t continue to complain about the security of the Microsoft platform if they won’t deploy the latest (or even recent) patches.

Trials and tribulations with RIS

Posted on By Mark Wilson
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.

After a few weeks developing my unattended PC build using physical PCs, today I needed to deploy a virtual PC (VPC). It should be simple to boot a VPC to a Remote Installation Services (RIS) server and apply an image as normal, but in case anyone else out there is googling to find out why they can’t get it working, here’s some of the stuff I’ve found today.

The SMC 9332 NIC which VPC emulates does not include PXE support, but RIS has provision for this in the form of the remote installation boot disk, which may be created using the \\servername\reminst\admin\i386\rbfg.exe tool (and for VPC users, Roudy Bob has published a virtual RIS Boot Disk on his website).

I spent a while this morning wondering why I was receiving the following message, even though my virtual PC was using the host PC’s network card and the DHCP logs in %systemroot% showed an IP address being assigned to a device with the MAC address of my virtual PC:

DHCP
No reply from a server
Press any key to reboot system

This particular problem turned out to be related to my RIS configuration – after a not inconsiderable time spent searching, Microsoft knowledge base article 891372 reminded me that I had selected the checkbox to prevent responses to unknown clients in the properties for the RIS server (I pre-stage client PCs so that when they are rebuilt, RIS already knows the computer name).

Once that was fixed, everything was looking good, except that the Client Installation Wizard was not displayed. I enabled debug logging on the Boot Information Negotiation Layer service and the %systemroot%\debug\binlsvc.log file indicated that the RIS server was communicating with my client, but for some reason it was hanging after the server had sent a response:

[BinlServer] 02/15 14:07:30 [MISC] Client Guid: {00000000-0000-0000-0000-0003ffa7b536}
[BinlServer] 02/15 14:07:31 [MISC] MachineDN = CN=VPC1,OU=Policy,DC=home,DC=local
[BinlServer] 02/15 14:07:31 [OPTIONS] Server allows new clients and the Server is generating the OS Chooser path response.
[BinlServer] 02/15 14:07:31 [OPTIONS] Server allows new clients and the Server is generating the OS Chooser path response.
[BinlServer] 02/15 14:07:31 [MISC] SamName = VPC1$
[BinlServer] 02/15 14:07:31 [MISC] Name = VPC1
[BinlServer] 02/15 14:07:31 [OPTIONS] Recognizing client.
[BinlServer] 02/15 14:07:32 [MISC] Client Guid: {00000000-0000-0000-0000-0003ffa7b536}
[BinlServer] 02/15 14:07:32 [OPTIONS] Recognizing client.
[BinlServer] 02/15 14:07:32 [MISC] Client Guid: {00000000-0000-0000-0000-0003ffa7b536}
[BinlServer] 02/15 14:07:32 [OPTIONS] Recognizing client.
[BinlServer] 02/15 14:07:32 [STOC] Sending response to = 192.168.7.106, XID = 63702087.

Compared with a working (physical) PC, where the log read:

[BinlServer] 02/15 14:17:01 [MISC] Client Guid: {84e1f6e8-cfcc-11d6-7f6d-218f133b01ff}
[BinlServer] 02/15 14:17:01 [MISC] MachineDN = CN=LAPTOP1,OU=Policy,DC=home,DC=local
[BinlServer] 02/15 14:17:01 [OPTIONS] Server allows new clients and the Server is generating the OS Chooser path response.
[BinlServer] 02/15 14:17:01 [OPTIONS] Server allows new clients and the Server is generating the OS Chooser path response.
[BinlServer] 02/15 14:17:01 [MISC] SamName = LAPTOP1$
[BinlServer] 02/15 14:17:01 [MISC] Name = LAPTOP1
[BinlServer] 02/15 14:17:01 [OPTIONS] Recognizing client.
[BinlServer] 02/15 14:17:02 [MISC] Client Guid: {84e1f6e8-cfcc-11d6-7f6d-218f133b01ff}
[BinlServer] 02/15 14:17:02 [OPTIONS] Recognizing client.
[BinlServer] 02/15 14:17:02 [MISC] Client Guid: {84e1f6e8-cfcc-11d6-7f6d-218f133b01ff}
[BinlServer] 02/15 14:17:02 [OPTIONS] Recognizing client.
[BinlServer] 02/15 14:17:02 [STOC] Sending response to = 192.168.7.104, XID = 8831c65a.
[BinlServer] 02/15 14:17:04 NULL screen name so we are retrieving the Welcome Screen.
[BinlServer] 02/15 14:17:04 Retrieving screen file: 'E:\RIS\OSChooser\welcome.osc'

I spent hours trawling the ‘net, completely mistified as to why physical PCs worked, but not virtual PCs, until a colleague reminded me that RIS servers should not have multiple NICs installed (they can have but it is not recommended – this is also explained in Microsoft knowledge base article 891372). My RIS server does have two NICs – one connected to a 3Com SuperStack 3300 switch (downstairs), and one wireless LAN connection to the LAN in my office upstairs (which uses a mixture of wired and wireless LAN technologies). As a last resort, I plugged the host PC into the downstairs switch and the VPC suddenly found the RIS server.

For reference, by default, after obtaining an IP address and downloading the boot image, RIS displays a prompt for the user to press F12. This may be disabled by renaming startrom.com to startrom.old and startrom.n12 to startrom.com (found at \\servername\reminst\oschooser\i386). You can also edit the .osc files used by the Client Installation Wizard as these are simply OSCML documents (modelled on HTML 2.0).

Now RIS is working as I expected and I can even go back to pre-staging clients (GUIDs for VPCs are formed with the MAC address for the virtual NIC, prefixed with 00000000-0000-0000-0000-).

This should have been simple, but a couple of minor issues made it very difficult – I just hope my experience is useful to someone else out there in cyberspace.

Links

How to set up, configure, and use Remote Installation Services in Windows 2000
Customising RIS Installations

Preselecting English (United Kingdom) settings during Windows XP setup

Posted on By Mark Wilson
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.

By default, Windows XP installs English (United States) as the input language. It is possible to add other languages, for example English (United Kingdom), but if you try to remove English (United States) you are prompted that it is in use and will be removed after the next reboot. This may only be a minor inconvenience, but can be circumvented using an unattended setup file, either for a fully- or partially-unattended build.

Within the [Unattended] section of the answer file, a KeyboardLayout= entry may be specified. The Microsoft Windows Preinstallation Reference states that this entry is used to specify the type of keyboard layout to install during text-mode setup and I have found that by using a United Kingdom keyboard for text-mode setup, no United States entries are created during GUI-mode setup.

The KeyboardLayout= entry must match one of the strings (in quotation marks after the =) in the [Keyboard Layout] section of txtsetup.sif (which is found in the Windows XP installation source).

For reference, my RIS-based unattended installation uses the following entries to specify UK-only regional settings and location:

[Unattended]
KeyboardLayout="United Kingdom"

[RegionalSettings]
Language=00000809
SystemLocale=00000809
UserLocale=00000809
InputLocale=0809:00000809
UserLocale_DefaultUser=00000809
InputLocale_DefaultUser=00000809

Further information on the available regional settings may be found in Microsoft knowledge base article 289125 and the Microsoft global development website has a full list of the available National Language Support (NLS) code pages.

Troubleshooting an MS-DOS application which hangs the NTVDM subsystem in Windows XP and Windows Server 2003

Posted on By Mark Wilson
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 working on an intriguing (and frustrating) issue for a few weeks now and a couple of days back we finally resolved the issue.

My client has an MS-DOS (FoxPro 2.6a database) application running within an NTVDM on Windows XP. Every now and then, the application will hang – seemingly randomly. Windows XP did have service pack 2 applied, but the issue also occurs on service pack 1 PCs (I didn’t try the RTM version). Only the application hangs – it is possible to terminate the NTVDM process and carry on working as normally.

Normal actions for troubleshooting MS-DOS applications in Windows XP were not helping to resolve the issue, but the software vendor managed to narrow the issue down to FoxPro waiting for input. Occasionally, the input does not timeout and return control to the calling program – it seems that this is the root cause of the NTVDM hang. Identifying this allowed them to construct a test program which polled for input, timing out every few seconds and would reliably hang an NTVDM at a seemingly random time, but always within an hour.

Using their test program on a variety of PCs, the software vendor found that the problem was related to the Intel hyper-threading technology (my client has standardised on a version of the IBM ThinkCentre M50 which includes a single 3GHz Intel Pentium 4 processor with HT technology). Whilst disabling hyper-threading is unlikely to result in any significant performance degradation (hyper-threading only provides an average 10-20% performance gain as most applications do not fit completely with the hyper-threading model), it was still considered by IBM, Microsoft, my client and myself as a tactical workaround, rather than a strategic fix.

After seeking advice from Microsoft, I ran the test program on a Compaq ProLiant DL380 G2 server with two Pentium III 1.26GHz processors and found that the issue is not limited to Windows XP and hyper-threading, but to both Windows XP and Windows Server 2003 when running with an ACPI Multiprocessor PC HAL. Turning off hyper-threading on the PCs was no longer good enough as we can expect to see multiple processor cores constructed on a single die in the near future, leading to a rise in the use of multi-threaded applications (the logical processor provided by the hyper-threading technology in the Intel Pentium 4 processor is simply a precursor to this).

So why does an MS-DOS application running within an NTVDM on a 32-bit version of Windows use multiple processors? The answer it seems is that although the MS-DOS application is not multi-threaded, modern versions of Windows are, and can allocate parts of the NTVDM process to any available processor. With that in mind we re-ran the test program with processor affinity set to use only CPU0 in Task Manager. The results were the same as disabling hyper-threading – no NTVDM hang! Obviously, setting processor affinity manually is not sustainable outside the test environment, and short of running the application on Windows Server 2003 Enterprise Edition (with the Windows System Resource Monitor to control processor affinity) we needed to find an alternative solution.

That solution came in the form of the imagecfg.exe tool provided with the Microsoft Windows 2000 Resource Kit (supplement one). This can be used to edit an executable file and permanently set the processor affinity for a given application:

Using the imagecfg -a 0x1 c:\windows\system32\ntvdm.exe command did the trick, although Windows File Protection/System File Checker quickly restored the original ntvdm.exe file so I needed to perform this on a copy of ntvdm.exe in a temporary folder, and then overwrite both c:\windows\system32\ntvdm.exe and c:\windows\system32\dllcache\ntvdm.exe.

Once updated, the NTVDM process runs on CPU0. Of course, this limits all programs under the control of the NTVDM subsystem but it is far more preferable to disabling logical or physical processors in the BIOS; however, as this is a change to an operating system file, it must be considered alongside the implementation of any service packs and/or hotfixes from now on. Reversing the change is simply a case of restoring the original ntvdm.exe file.

Discovering unknown devices in Windows

Posted on By Mark Wilson
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.

Whilst developing my unattended Windows XP build, I came across a number of devices that were not automatically detected by Windows.

Sometimes, right-clicking the unknown device in Device Manager and selecting the Update driver… option allowed Windows Update to connect to the Internet and locate updated drivers (which in turn identified the device and allowed me to download and integrate the OEM drivers into the Windows XP installation source).

On other occasions it was not so simple, and I needed to do some research to identify the device using the PCI device instance ID (found on the details page of the device properties).

A couple of years back I was introduced to Craig Hart’s PCI and AGP bus sniffer. I could have just run the utility, but in this case I chose to search its companion file (pcidevs.txt) for the vendor and device PCI IDs. Using this technique, I was able to identify my unknown device as the Broadcom (vendor 14E4) BCM4306 802.11g Wireless NIC (device 4320), which is also known as a Dell Wireless 1350. Once I had that information, all that was required was to download the drivers for integration.

Problems with certain NICs and a RIS-based Windows XP installation

Posted on By Mark Wilson
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.

After my hard disk failure last month, I decided to resurrect a project that I had shelved some time ago – implementing an unattended setup for my PCs at home. I have a variety of computers from HP (Compaq), IBM and Dell, which makes things slightly more complicated than it might otherwise be (although not impossible), so this was an opportunity to implement some of the business desktop deployment (BDD) technologies that I practise at work to implement a standard operating environment (SOE) and allow me to rebuild PCs at will.

My previous experience with unattended installations has largely been on the server side, basically amending and appending OEM installation scripts (e.g. Compaq/HP SmartStart or the HP ProLiant Essentials Rapid Deployment Pack (RDP)). This time I had a plethora of drivers to consider, and a limited (zero) budget. To allow for a repeatable, customisable, build I decided not to use any imaging technologies but instead to create a standard unattended setup, including all the drivers needed for the various PCs and a common set of applications. One thing I could rely on the presence of was Pre-boot eXecution Environment (PXE)-enabled workstations, so I set up and configured Microsoft Remote Installation Services (RIS) to serve my Windows XP + SP2 installation “image” (not really an image, but that’s the RIS terminology).

Incidentally, the most complete resource for information on creating unattended builds that I am aware of is the Microsoft Software Forum Network’s “Creating the Ultimate Unattended XP CD”. Although CD based, this gives much of the information needed for a successful RIS-based installation.

Everything was looking good until I tried to perform a PXE network service boot and connect to the RIS server. I could see that my DHCP server was issuing IP addresses to clients but they received an error:

PXE-E53: No Boot Filename Received

Basically, the PXE clients couldn’t find the RIS server. DHCP was being served from an ADSL router and I couldn’t find any way to configure the router to redirect PXE clients. Logically, interaction between the PXE client, the DHCP server and the RIS server should not have been affected by the router because PXE uses DHCP broadcast requests and all the computers were all on the same subnet but once DHCP was migrated to the RIS server, the error disappeared and the RIS Client Installation Wizard ran as expected. Since then, I’ve found Microsoft PSS’ Technical Guide to Remote Installation Services, which suggests various troubleshooting actions but for now it works, so maybe I’ll investigate further some other time.

The next issue was that Windows XP setup failed as the network drivers for the Broadcom BC570x NIC in my Dell Latitude D600 were not available from the Windows XP installation source:

The operating system image you selected does not contain the necessary drivers for your network adapter. Try selecting a different operating system image. If the problem persists, contact your administrator. Setup cannot continue. Press any key to exit.

Microsoft state that a hot fix is required to resolve this issue; however the Broadcom driver FAQ gives an alternative resolution which involves editing the B57WIN32.INF setup information file. I didn’t want to do this as it would break the digital signature and I would prefer to construct the build using signed drivers only. Instead, I used the latest drivers (v7.86) from Broadcom rather than the Dell-packaged version and once I had integrated the network drivers with the RIS installation source, deleted any instances of precompiled setup information (.PNF) files and restarted the Boot Information Negotiation Layer service, I was able to commence my unattended Windows setup.

This time, a new error halted text-mode setup:

File b57w2k.sys caused an unexpected error (21) at line 3788 in d:\xpsprtm\base\boot\setup\setup.c. Press any key to continue.

Some posts in the Bink.nu and MSFN forums led me to a solution for this by copying the Windows 2000 version of the drivers (B57W2K.SYS) to the Windows XP installation source \i386 folder alongside the Windows XP driver (B57XP32.SYS) and the setup information file (B57WIN32.INF).

Once the Dell PC was working, I had the same issue with an IBM ThinkPad T40 with an Intel PRO/100 VE card and so it seems logical to assume that this issue may apply to a variety of NICs.

For the BC570x, a Windows User Group (Nordic) article which discusses integration of Intel and Broadcom drivers with RIS images suggests rewriting the B57WIN32.INF file to replace all references to B57W2K.SYS with B57XP32.SYS, but again, I avoided this to prevent issues with unsigned drivers. Intel’s solution to installing PRO/100 or PRO/1000 NICs via RIS requires a further download but I got it working by applying the same resolution as for the Broadcom drivers – i.e. using IBM’s distribution of the Intel drivers (v7.0.28.0) and including the Windows 2000 E100BNT5.SYS driver in the Windows XP installation source \i386 folder for text-mode setup.

I should point out that it was only necessary to add these network drivers to the \i386 folder on the Windows XP installation source in order to use the NIC to copy files during setup and it is still necessary to add OEM device drivers to the Windows XP installation source for all undetected devices in order to allow the drivers to be used during the plug and play (PnP) section of setup.

After a couple of days downloading, integrating and testing drivers, my RIS-based Windows XP installation works for all of my computers and now I can focus on the finer points of the build, tuning the Windows XP installation and adding applications to my SOE.

Get Windows XP and Office 2003 in Welsh

Posted on By Mark Wilson
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 went to Uni’ in Wales, so I feel duty bound to publicise this for my Welsh-speaking friends!)

Microsoft have worked with the Welsh Language Board to develop two new Welsh-language interface packs – one for Windows XP and another for Office 2003. They are free to download, and enable Welsh speakers to work more easily in their chosen language whether at home, in business or in education.

To find out more, visit the Welsh pages on the Microsoft UK website.

Getting Tivoli to work on a Windows XP computer with a personal firewall enabled

Posted on By Mark Wilson
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’m working with a client on a Windows XP standard operating environment (SOE) that includes service pack 2 (with Windows Firewall enabled). They use IBM Tivoli for remote control, inventory and software distribution but IBM do not currently support the Tivoli client on SP2 machines and some work was needed to get it working across the firewall. For reference, here are the firewall exceptions that were needed:

  • IBM Tivoli Inventory Collector (C:\Program Files\Tivoli\lcf\inv\SCAN\wepmcoll.exe);
  • IBM Tivoli JRE (C:\Program Files\Tivoli\lcf\bin\w32-ix86\tools\jre\1.3.0\bin\java.exe);
  • IBM Tivoli Management Agent (C:\Program Files\Tivoli\lcf\bin\w32-ix86\mrt\lcfd.exe);
  • IBM Tivoli Mobile Console (C:\Program Files\Tivoli\lcf\dat\1\mobile\mobile.exe);
  • IBM Tivoli Mobile Console Distribution (C:\Program Files\Tivoli\lcf\dat\1\cache\bin\w32-ix86\TME\mobile\epnewdist.exe);
  • IBM Tivoli Remote Control Target (C:\Program Files\Tivoli\lcf\PCREMOTE\w32-ix86\tgt\eqnrcmai.exe);
  • IBM Tivoli Software Distribution Engine (C:\Program Files\Tivoli\lcf\dat\1\cache\bin\w32-ix86\TME\swdis\spde\spd_eng.exe).

Theoretically these would be the same whatever the personal firewall product in use; however all of the above should be configured as application exceptions (Tivoli uses randomly generated ports under certain circumstances and so simple packet filtering exceptions would be inappropriate). If the firewall in use only handles packet filtering, then you may have more difficultly getting this working (you may need to open big holes in the firewall to cover a range of possible ports – in this case I would suggest using the Windows Firewall instead as it does offer application filtering – see my earlier post about choosing whether to run the Windows Firewall, a third party firewall, or both).

Obviously installations of Tivoli (as for most enterprise management products) vary according to the features in use and if the exceptions above do not completely resolve the issue, James Dawson gave me the following advice:

  1. Run netstat -ano | find "LISTENING". This will give a list of TCP ports that are listening for connections and the last column of the output is the ProcessID (PID) of the process actually listening. You can then use the PID to find what ports the Tivoli process(es) are running on, and then add these ports to the exceptions.
  2. Use the PIDs from the output of step 1 to check whether Tivoli is using any UDP ports: netstat -ano | find "PID" (repeat for each Tivoli PID).

Allowing files to be replaced as part of an FTP rename operation

Posted on By Mark Wilson
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.

Yesterday, one of my clients came across an interesting scenario. They use FTP to poll sales data from their retail outlets back to a central location. As part of this process, the polling file is renamed to filename.bak; but what if filename.bak already exists from an earlier poll? The existing NT 3.51 FTP Server network component allows the rename with no problem, but XP’s FTP Server (part of IIS 5.1) does not, producing an error:

550 filename.bak: Cannot create a file when that file already exists

A quick search on the ‘net unearthed Microsoft knowledge base article 309634 . Once I had extracted the mdutil.exe utility from a Windows 2000 CD (see Microsoft knowledge base article 240225) I was able to run the following command:

mdutil set msftpsvc/1/AllowReplaceOnRename 1

A restart of the IIS Admin service was all that was needed then to allow the rename to take place within the polling process.

Installing the “Energy Blue” theme on a computer running Windows XP Professional

Posted on By Mark Wilson
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 has released the “Energy Blue” theme (used in Windows XP Media Center Edition 2005) for tablet PC users. The theme provides new colours, new effects and a new wallpaper, which according to Microsoft “will give your Tablet a fresh, updated appearance”.

The normal setup mechanism will not allow the update to install on non-Tablet PCs, but as hinted by the Windows IT Pro magazine network WinInfo Daily Update, it is still possible to install the theme on a PC running Windows XP Professional. To do this:

  1. Use a third-party extraction utility (e.g. WinZip) to extract the files within the downloaded file (WindowsXP-TabletPC-EnergyBlueTheme-x86-ENU.exe) to a temporary folder.
  2. Once extracted, copy the files as follows, creating folders as necessary (once all files are copied, the temporary folder created in step 1 may be deleted):
    • royale.theme -> %systemroot%\Resources\Themes
    • royal.msstyles -> %systemroot%\Resources\Themes\Royale
    • shellstyle.dll -> %systemroot%\Resources\Themes\Royale\Shell\Homestead
    • shellstyle.dll -> %systemroot%\Resources\Themes\Royale\Shell\Metallic
    • shellstyle.dll -> %systemroot%\Resources\Themes\Royale\Shell\NormalColor
    • shellstyle.dll -> %systemroot%\Resources\Themes\Royale\Shell\Royale
    • energybliss.jpg -> shellstyle.dll -> %systemroot%\Resources\Themes\Royale\Wallpaper
  3. Within the Display Properties select the Energy Blue theme from the drop-down selection on the Themes page. A new Color Scheme called Royale will also be available on the Appearance page.