IE9 Rendering Problems

We have been having problems with IE and some add-ins: notably Flash 11 and Silverlight. The symptoms include having some flash objects not appear at all. Streetview, for example, displayed a blank black panel with some images appearing at the mouse passed over it. For Silverlight, it was Word Web App. Again, a black background with some text occasionally appearing when the mouse rolled over. SharePoint also got a rough time, with permission denied boxes appearing to be totally blank.

We have discovered that the problem is not with Internet Explorer, Silverlight or Flash. In fact it was the Intel Graphics Adaptor incorporated into our otherwise well endowed desktops.

There is a simple work-around for this (if an upgrade to the Graphics Driver) does not fix the problem: Tell Internet Explorer to use the Software Render. Tools -> Internet Options: Advanced Tab: Tick 'Use Software Rendering instead of GPU Rendering'. Done!

Now if, like me, you have around 500 PCs and laptops to look after, you don't want to wander around all 500. Neither do I want to have the pain of having to explain to a range of competencies how to fix this themselves. Instead, I use group policy preferences (under user configuration) Windows Settings, Registry:
Hive: HKCU
Path: Software\Microsoft\Internet Explorer\Mait
Value Name: UseSWRender
Value: 1

Apply this to all your affected users and enjoy a cuppa.

IPv6 Reverse Proxy using Apache on Windows

Moving to IPv6 poses certain problems. The biggest of which is application compatibility. Of Course, as one would expect, Microsoft is on the bandwagon for IPv6. Unexpectedly, their web proxying product, Forefront TMG, does not play happy with IPv6. Maybe Microsoft are expecting us to put all our web servers out there straight on to the IPv6 web, bolts and all. We have all our web servers safely in our intranet, and use a single firewall/reverse proxy application to serve pages to the outside from multiple sources inside without the need to expose those servers, or multi-home them.

So what is out there that can do the job? Thankfully, Apache comes to the rescue. Apache makes proxying fairly simple, if you like text configuration files. After tinkering with it for a little bit, you'll see why I say that. Unfortunately, the IPv6 troll strikes again. In the standard Apache binaries, compiled for Windows, IPv6 is not built into the listening stack. But that is not the end of the world, because you can compile Apache yourself with Visual Studio's command line tools. I used Visual Studio 2010 professional in my attempt.

So, this document details how to build your own Apache binaries, with IPv6 listeners enabled:

To start off with you will need the locations of perl and awk.exe to be in the path variable. Check out where to get these from the Compiling Apache for Windows page.

Download the latest source versions. You are going to need the source code for Apache, Openssl and zlib. Create a working directory for the Apache source code and extract it there. You will find amongst the directory structure a directory called srclib. In this directory, create a sub-directory called openssl. Extract the Openssl source there. In the srclib directory, create another folder called zlib. Extrack the zlib source in there.

Build the components in the following order: zlib - Openssl - Apache

Building zlib: Open srclib\zlib\win32\makefile.msc. Add 'inffast.obj' to the OBJS= line and save the file. From your visual studio command prompt navigate to srclib\zlib. Build using the following two commands:
nmake -f win32\Makefile.msc
nmake -f win32\Makefile.msc test
If this is successful, you will see a series of tests where a file is created, compressed and decompressed.

Building openssl: From your visual studio command prompt navigate to srclib\openssl. the following commands:
perl Configure VC-WIN32 enable-camellia no-idea no-rc5
ms\do_ms.bat
nmake -f ms\ntdll.mak
Finally, create an empty file and name it store.h and place it in srclib\openssl\inc32\openssl

Building Apache: Open the file srclib\apr\include\apr.hw. Fine the line:
#define APR_HAVE_IPV6    0
Change the 0 for a 1. From your visual studio command prompt, navigate to the root of your Apache source code. Compile with the following commands:
nmake /f Makefile.win _apacher
nmake /f Makefile.win installr INSTDIR=D:\Apache2
(For D:\Apache2 put in a blank directory of your choice. Once compiled, this will contain the complete programme file structure for Apache.)

Now move the whole installation to your destination server. We used server 2008 R2. Place into the Program Files directory of your choice. Once located run httpd.exe -k to install the application as a service.

Now a little cheat. I had previously downloaded the msi installation files off the Apache website and had been fiddling around with that until I discovered that they had compiled it without IPv6 support. If you want to get up and running quickly, run the installer and answer all the questions. Your conf file is then set up to run for your server. I then deleted the contents of the programme files and inserted my compiled version, keeping the original working configuration.

So to add an IPv6 listener to Apache open the main httpd.conf file and add, for example:
listen [2xxx:xxxx:xxxx:xxxx::xxxx]:80
listen [2xxx:xxxx:xxxx:xxxx::xxxx]:443
Make sure your ssl certificates are all in place, by un-commenting the httpd-ssl.conf (in httpd.conf) and changing the settings accordingly. Thankfully, the Apache configuration files are well commented and set up is not rocket science.

Un-comment the httpd-vhosts.conf (in httpd.conf) and add your own site in place. Here are two examples:

Permanent redirection to https:

<VirtualHost [2xxx:xxxx:xxxx:xxxx::xxxx]:80>
 ServerAdmin admin@s.org.uk
 ServerName host.s.org.uk
 ServerAlias *.s.org.uk
 ErrorLog "logs/host.s.org.uk-error.log"
 CustomLog "logs/host.s.org.uk-access.log" common
 ProxyRequests Off
 
http://host.s.org.uk/*>
  Order deny,allow
  Allow from all
 

 redirect permanent / https://host.s.org.uk/
VirtualHost>
Proxy a http site over https

<VirtualHost [2xxx:xxxx:xxxx:xxxx::xxxx]:443>
 SSLEngine on
 SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
 SSLCertificateFile "C:\Program Files (x86)\Apache Software Foundation\Apache2.2\conf\cert.pem"
 SSLCertificateKeyFile "C:\Program Files (x86)\Apache Software Foundation\Apache2.2\conf\cert.key"

 ServerAdmin admin@s.org.uk
 ServerName host.s.org.uk
 ServerAlias *.s.org.uk
 ErrorLog "logs/ssl.host.s.org.uk-error.log"
 CustomLog "logs/ssl.host.s.org.uk-access.log" common
 ProxyRequests Off

 http://host.s.org.uk/*>
  Order deny,allow
  Allow from all
 

 ProxyPass / http://host.s.org.uk/
 ProxyPassreverse / http://host.s.org.uk/
 ProxyPreserveHost Off
VirtualHost>

There are a few configuration gotchas in Apache to watch out for:
SSLPassPhraseDialog: No doubt you will want to run https on this. Unfortunately, the default setting (builtin) does not work on Windows. So you have to point this setting to an application. I pointed it to notepad. Having removed the need to enter a pass phrase this never gets called.

SSLSessionCache: This setting requires a path not broken by spaces. If you have placed your installation in Programme Files, this setting does not work. To get round it, create a shortcut in the root of the drive that points to your Apache directory. Then use that shortcut in the setting. (e.g. shmcb:c:\Apache\etc...)

Maybe Microsoft and other vendors will get their IPv6 act together before people start realising that the products they paid for are not up to scratch, and before freeware products like Apache start stealing their thunder...

Sonicwall NSA Support for IPv6

You may see a few posts on IPv6 through the summer. Keep tuned.

Sonicwall NSA firewall devices DO support IPv6. What they do not tell you is that you need a specific version of the firmware. (5.5.6) When you go to the downloads site, click on the previous versions link and look for the feature release - Version 5.5.6.0-IPv6.

Why they do not mention this anywhere is beyond me. But you've heard it here now. I hope my two days of frustrated hunting around will save you time.

SCCM, WinPE and 802.1x - Windows 7 Service Pack 1

In addition to my last post on this issue here, Windows 7 Service Pack 1 has brought with it only a minor change. The details in that post are still valid, with one minor exception.

In "Stage Two Prepare the WinPE Image" I referred to a hot fix package KB972831, which contained the WinPE module for 802.1x. This had to be added using DISM /add-package. Happily the Service Pack 1 AIK toolkit now contains the winpe-dot3svc.cab in the same location as the other three cabs (winpe-scripting.cab, winpe-wmi.cab, winpe-wds-tools.cab.) 

This means that there is very little reconfiguration needed for introducing your SP1 image.

SCCM and WDS

One of the most complained about problems on the SCCM technet message boards is when the PXE service point stops working. We have had this problem for some time now. The issue ranges from simply not starting after a reboot to not working at all after provisioning a new PXE service point. Our last PXE outage lasted about a month.

The problem is now that there are so many post on this issue, it is hard to find one with a workable solution. The first thing you should be aware of this blog from the Configuration Manager Support Team. This is the first place to go to when looking for solutions to your WDS and SCCM problems. As you will note, even they are constantly updating the information. The last update was on 6 January (or 1 June - depending how you read it) this year. The whole integration of SCCM and WDS is so complex, that even the people who created it are having a hard time.

And even after following the instructions in the above blog, you can still come up against a brick wall. For example: Simply uninstalling the SMS_PXE service point and the WDS server is not enough. You also need to delete the "remoteinstall" directory, or WDS will install and pick up the (probably wrong) settings when it is re-installed.

Another big issue is communications between the WDS server and the Database server. In the world of Windows Server 2008 R2, the firewall is switched on by default. Even with an SQL exception the WDS server can find itself blocked out of the Database. My solution there was to allow all traffic from the WDS server through to the SMS Database Server. My symptoms included the WDS services failing to load the SMS provider with 0x4005 error. As any persistent user of the Technet Forums knows, 0x4005 means 'access denied' in any application.

One of the best ways to figure out whether the issue is at the the WDS end or at the SCCM end, is to actually configure the WDS server as a WDS server. If you have already configured SCCM with a boot image and an OS image, it's really simple to do. After uninstalling and re-installing the WDS role, go ahead and configure the WDS server. Now before the server will start to server PXE, it needs a boot.wim and an install.wim. Having already configured the boot and OS images, you can simply pick them up from their source directories. Just pick up the boot.XXX0001A.wim files and drop them in a temporary directory on the WDS server. Rename the files boot.wim and install.wim. The fact that they are not configured for WDS use is neither here now there at this point. You just need to have both a boot and an install file in order for the WDS server to start servicing PXE requests. Using the WDS mmc console, add the boot file first, then add the install file. Now try to start the service and boot a client to PXE. If it works, your WDS installation is clean.

Following best practice, uninstall the WDS server as you did before, remembering to remove the remoteinstall directory, and then follow the instructions in the blog mentioned above. If you then have problems (even after setting a firewall exception for the WDS server on your SMS DB server) you are looking at a SCCM issue such as access by the WDS server's computer account to the database.

Disable MS Word 2007 Proofing Tools via Group Policy

Yes it is possible!

Why would I want to do this? Well, for exams, of course. In order to have multi-use PCs that are used for teaching to have the possiblity of use for qualified exams, the PCs need to have it's proofing tools tied down.

The other things like internet access and access to network locations is easy enough, but how do you lock down Proofing in Word 2007? Well, you have probably at first glance seen the Group Policy Objects for Word 2007. You can find them in User Settings/Administrative Templates/Microsoft Office Word 2007/Word Options/Proofing. But, as anyone who has ever tried these settings knows, when you open Word 2007, the settings are easily switched back on or bybassed by using the items in the proofing toolbar or by going into the options.

Ah - but what if you could disable the specific user interface items? Well you can - that's easy: Under Microsoft Office Word 2007/Disable Items in User Interface/Custom you can do this. Microsoft has a whole page devoted to this subject. You can find that here.

So what IDs do you disable. Well here is my list:
2566
15780
9056
6111
12842
14453
2815
3492
3492
4025
3997
3958
790
2
3217
2349
329
3219
2469
2788
11323
7343
7387

The important one, the one that is not in the documentation, is 11323. including this ID disables the "Options" button in the Office Button (that un-named circle that someone sensible renamed 'File' in Office 2010.) Without the "options" button disabled, those pesky office group policies can be over-ridden by the user. Without access to options, the user must accept a proofless Word.

But that is not quite enough. It is still possible to gain access to Options by using the "Alt-T, O" legacy key press. But once again, there is an answer. In the same folder as 'Disable commands,' is 'Disable shortcut keys.'

Once again here is my list:
118
254
79,12
118,16
118,4

The 254 entry is equivalent to the key and option combination 84,16. It's not that clearly explained, the key is the standard ascii character that is being used in the combination. 84 is t. The number following the comma is the option. Alt is 16, Ctrl is 8 and Shift is 4. Any combination adds up; so Ctrl-Shift is 12 (8 + 4).

So these options will now disable:

• 118 - F7 Do a spell check
• 79,12 - Ctrl-Shift-o - Opens the research bar
• 254 (or 84,16) - Alt-T Legacy Tools Menu

So now we have used the standard group policies to disable proofing on Word 2007. The User interface buttons are disabled and the options menu is also unreachable so that the disabled options can no longer be turned back on.

The only thing left to do is to make sure the Group Policy Object is targeted only at your Exam login, or your teachers are going to get very angry with you.