Exchange 2007 OWA/ActiveSync with Two SSL Certificates
Yes, it is possible. It's not pretty by any means (a proper Class 2 SSL Certificate is the best way to go), but it can be done. Click Continue Reading for the process.
Non-Tech: Unintentional Humour from Valve
When Valve was first leaking details about Steam for Mac, they released a series of images parodying 'classic' Apple ads. This was one:
I get what they're trying to say - the PC is boxy and old-fashioned while the Mac is shiny and new. The unintentional humour is that while the Portal turret does it's job adequately in its game, it's easily defeated. The PC (or Team Fortress 2 turret) on the other hand starts out small and meek, but can be easily upgraded in to a massive powerhouse. That said, which would you rather have? Effective but locked down, or less-than-pretty but easily customizable?
Of course, I could just be reading too much in to things again.
IDNK: Windows 7 Dual Monitor Feature
I did not know that, on Windows 7 systems with a dual-monitor setup, you can middle-click on a window title bar (maximized or normal) and the window will instantly jump to the other monitor. To return it, simply middle-click the title bar again.
Huh.
Edit: Turns out I'm a complete git and the reason I didn't know about this is because it isn't a feature of Windows 7 -- it's actually a feature of DisplayFusion. D'oh!
Rant: Microsoft Telephone Activation
I've blogged about Microsoft Telephone Action before, but now I'm off on a rant....
Click 'Continue Reading' for the wall-of-text!
Office Apps Stuck on Downloading Files from Network Shares
For a while now I was having problems opening Word and Excel (2007 and 2010) documents on my work computer. Most of the time everything would work, but every now-and-again I'd go to open something and Word or Excel would report that it was "Downloading <filename>", and simply get stuck. Although I could click the little 'X' to cancel and close the window, the process for either Word or Excel would stay active, and any attempts to kill it would fail. In the end, I'd have to hard power off the computer to get it to shutdown, and then do a cold boot.
I wasn't really bothered by it until a few of my users started reporting the same problem. I had a look in to it, and after a lot of fiddling, came across two Microsoft Knowledge Base articles that eventually led me to a solution.
By adding the registry value from the first KB article linked above (EnableShellDataCaching), and by removing the Group Policy object that was creating a persistent drive mapping and replacing it with a login script (below) to map the drive, I haven't had any further reports of the problem.
REM Login Script - Paste these lines in to a batch file, and add that .bat file to a GPO
net use z: /deletenet use z: \\server\share
Symantec Endpoint: Good at Giving Me Heart Attacks
Oi. Symantec is definitely giving me a lot to blog about recently.
I logged in to one of our public file servers today for a weekly inspection, and as is someone common was greeted with a dozen reports from Symantec Endpoint 11 of infected files being deleted. It's not uncommon for our clients to open malicious attachments, visit shady websites, and generally make a mess of things, but a combination of good ACL's, Deep Freeze, and SEP 11 on the server have kept things clean.
So, after reading through the alerts and verifying SEP cleaned all of the detected files, I ran Live Update followed by a Full System Scan, as is standard procedure. Out of curiosity, I watched the first part of the scan process, when I noticed it pause on these files:
c:\windows\hide_evr2.sys
c:\windows\9129837.exe
d:\autorun.inf
The first two file names made me worried, and the third a little more so, if only because D: is another RAID array and therefore has no reason to have an Autorun.inf. After a little digging, however, I found that none of these files seemed to exist on the server. Now I started thinking 'rootkit'.
Sure enough, a quick Google later showed that yes, these files are common to a number of different rootkit variants. As such, I busted out my usual toolkit of malware detection/removal utilities and took the server offline.
As I dug deeper in to the server, though, I still couldn't find any traces of the mentioned files. I tried several different rootkit tools, browsing the hard drive contents from a Linux LiveCD, and even a few tools to check ADS (Alternate Data Streams), but had no luck.
At this point, I was fairly convinced that the server was clean, however why would Symantec report those files as present, unless.... Digging a little further in to the results from Google, I found this forum thread: http://www.antionline.com/showthread.php?t=278671 - apparently, during the initial part of the scan, Endpoint doesn't actually report just the files that it's scanning, it also reports the name of the files it's looking for.
So, a little life lesson - don't assume that Symantec will do anything that makes sense. And, when in double, Google is still you're friend - you just need to look harder.
The TL;DR version: The scan status on Symantec Endpoint 11 doesn't just show the actual files on the computer, but it also shows non-existent files that it's looking for. When in doubt - verify manually!
Excluding Multiple Paths with ROBOCOPY
ROBOCOPY is an excellent command line utility that Microsoft began bundling with Windows Vista, and has since been included in Windows 7 and Server 2008 (R2 as well). It makes it incredibly simple to mirror a directory tree, and is great for batch file backups. There are a few quirks with it, however.
When using the /MIR switch, ROBOCOPY overwrites the destination path with everything in the source path. To exclude folders, you're instructed to use the /XD switch. Below is a sample with the correct syntax:
robocopy d:\ n:\Data /MIR /Z /A-:R /R:1 /W:1 /LOG:n:\logs\data.log /XD d:\vms d:\wsus "d:\System Volume Information" d:\tmpbak d:\installs d:\RECYCLER
To break this down, we start with the ROBOCOPY command itself. Following that is the Source Path (D:\) and then the Destination Path (N:\Data). Next is the /MIR switch that tells ROBOCOPY to mirror the existing directory structure and copy everything. The /Z switch sets the job in Restartable Mode, and /A-:R removes any read-only attributes. /R:1 and /W:1 tell ROBOCOPY to Retry copying the file once if it encounters an error, and Wait one second between retries (I've set it this low as the backup runs late at night, as if someone has left a file open it doesn't matter how many retries are attempted).
Following this, the /LOG switch dumps the full output of the copy job to n:\logs\data.log. This includes information on the number of files copied, directories excluded, etc....
Finally, we get to the /XD switch. Note that this is the last included switch - although you can technically have it where ever you want in the command, it's cleaner, and less error-prone if you make it the last switch.
To exclude multiple directories, simply list them with spaces in between. If the path contains spaces (in the example above, I've excluded System Volume Information), wrap it in double-quotes ("). The most important thing, though, is DO NOT EVER, *EVER* include a trailing "\" in excluded paths!
For some reason, ROBOCOPY parses the trailing \ in an odd way. If included in the command, the log will list all of the excluded paths, however it will still copy the data. It won't provide any error messages or other output. For example, if you used the following command:
robocopy d:\ n:\Data /MIR /Z /A-:R /R:1 /W:1 /LOG:n:\logs\data.log /XD d:\vms d:\wsus "d:\System Volume Information\" d:\tmpbak d:\installs d:\RECYCLER
Because there is a trailing \ on "d:\System Volume Information\", the log will report that the excluded directories are d:\vms d:\wsus d:\System Volume Information d:\tmpbak d:\installs d:\RECYCLER, however it will still attempt to copy all of them.
However, if you simply omit the trailing \, ROBOCOPY will correctly parse the list of paths and will ignore them.
MSI “Click BIOS” UEFI on the P45 Platinum
Last weekend, as a result of a bought of insomnia and the inevitable boredom that with it, I started doing what I usually do - check for driver updates, firmware updates, BIOS updates, etc....
When I checked MSI's website, I found that they hadn't released an updated BIOS for my P45 Platinum bored in quite a while. Doing a little digging, I discovered why - they had apparently stopped updating BIOS on that board. The reason?
MSI "Click BIOS" - they're own UEFI implementation.
On their public site for it, http://www.msi.com/html/popup/MB/uefi/about.html, not a lot of information is available. Only two motherboards are currently listed as supported: my P45 Platinum, the P45D3, and another which is 'under testing'.
Doing a little Google'ing, I found that the firmware version they have available for download on the public site, 1.7, is apparently horribly out-of-date. The MSI forums pointed to the MSI FTP server, which unfortunately isn't public. Another quick Google search, however, provided me with a working username and password for it. Once in, I found the latest version (confusingly labeled 'e7512ims.100', which would seem to make it 1.10, or 1.00) and downloaded it.
The flashing process was identical to updating a standard BIOS image, and in no time I was in.
Now, there are plenty of review sites that talk about the GUI of the Click BIOS, so I'm not going to cover that. Instead, I'm going to focus on three things: The EFI Shell, the onboard JMicron IDE/SATA/RAID and Intel SATA/RAID controllers, and finally, booting UEFI-enabled operating systems (Windows Vista and Windows 7).
EFI Shell
The EFI Shell is very, very basic. Once loaded, it shows a list of all attached storage devices and the "Shell> " prompt. From here, you can select a device as you would in DOS or from a *nix prompt (ie, "FS0:"), and from there you can navigate with the 'CD' command and show files with the 'ls' or 'dir' commands. 'HELP' is available, however as there is no "MORE" command to pipe output to, you miss the first few commands listed. This can be overcome by typing 'help a*', which will list all of the commands starting with the letter 'a'.
I tried to execute a few of the EFI applications that were available to me, such as the MEMTEST app included on the Vista and Windows 7 DVD's, however I didn't have any luck. In fact, the only EFI applications I was able to run were the boot loaders from those disks. We'll get to that later, though.
Onboard Storage under UEFI
This is where things get tricky. When trying to install Windows 7 after the UEFI update, I wanted to be able to use a GPT-type drive. Unfortunately, with my Intel ICH10 controller in RAID mode, and the disks I wanted to install to in a RAID 0 array, I was only able to go through the first phase of the install process. As soon as it rebooted, the EFI boot manager wasn't able to boot to the installation. It worked if I changed the controller to AHCI mode, though.
However, as I really wanted the RAID array, so I switched back to RAID mode. However, now my array wasn't working. That's when I noticed that during the POST process, it wasn't showing the prompt to press 'CTRL+I' to enter the RAID manager. It also wasn't showing the prompt for the JMicron controller. What was worse was I noticed my two IDE hard drives weren't being detected, and hadn't been since the upgrade.
Fortunately, a quick poke around in the Click BIOS GUI under the BIOS Settings\Boot Settings area showed where I had gone wrong. In order to be able to see the output from the JMicron and ICH10 controllers, I had to set the following to options:
Option ROM Messages: Force BIOS
Interrupt 19 Capture: Enabled
If these are disbled, Click BIOS goes in to a 'silent' mode and won't display the messages or allow you to access the configuration utilities. And, in the case of the JMicron controller, won't even initialize it.
The down side is, when these are enabled as above, the POST process takes longer, and will jump back-and-forth from the normal POST screen to the boot messages. Additionally, even with these settings, I wasn't able to enter the ICH10 configuration manager with my USB keyboard. I had to unhook it, then connect a PS/2 keyboard, otherwise my key presses were ignored.
Update: Apparently, even with the above settings enabled, Click BIOS randomly refuses to initialize the JMicron controller. As such, my boot order frequently changes and I have to reboot repeatedly until the control is picked up, then enter BIOS and reset the boot order so my RAID array is the first boot device. Rather annoying, I must say.
Booting Windows in EFI Mode
This was annoying. First off, you can't just boot directly from the DVD - you have to do it from the EFI Shell. With the disk inserted, boot to the shell (you can press F11 during POST to get there, or you can do it from the Click BIOS GUI through BIOS Settings -> Boot Settings (although for the GUI method to work, you need to change something and try to exit. On the screen that prompts you to save, you can choose to bypass the startup options and just jump to the shell).
In the shell, watch for what device your DVD is. If you need to figure out which device is which later, you can also use the 'map' command.
In my case, the Windows 7 DVD was FS0:. As such, I typed that, and the prompt changed to 'FS0:>'. I then typed 'cd \efi\microsoft\boot' to get to the boot files. Here's where the big problem started.
To boot, there are two EFI applications available: 'cdboot.efi' and 'cdboot_noprompt.efi'. If I tried the first one, the top line of my screen would show 'Press any key to boot from DVD'. If I did, it would freeze there. If I tried the second, it would just freeze. Curiously, doing the same from the Windows Vista DVD (x64 with SP2 integrated) worked fine.
Apparently, the cdboot.efi used by Windows 7 isn't actually EFI 2.0 compliant. Go figure, huh?
I was finally able to boot from the Windows 7 DVD with a bit of trickery. Here's how:
1) Make a Windows 7 USB stick. Note: it has to be FAT32 formatted, so you need to do it manually. A guide on how can be found here. NOTE: When the guide says to type 'FS=NTFS' as part of the format command, type 'FS=FAT32' instead. MSI didn't include an NTFS driver in Click BIOS, so it is only able to read FAT32 formatted drives.
2) Insert the Windows 7 DVD and and connect the thumb drive. Reboot the computer, then enter the EFI Shell. The reboot is required.
3) In the shell, check the drive mappings. You should have multiple entries, and the first two should be FS0: and FS1:. One of them should be mapped to the DVD ROM drive (you can tell because the line will include 'cdrom' in the device information), and the other to the Removable Storage Device (the USB drive).
4) Select the USB drive. In my case, FS0: was the DVD and FS1: was the USB drive, so I typed 'fs1:' and hit enter). Your prompt should change from 'Shell>' to 'FS1:'.
5) Now type 'cd \efi\microsoft\boot' and press enter.
6) Type 'cdboot_noprompt' and press enter.
7) Wait (this takes a while).
Now you're running Windows 7 setup in EFI mode! Now you can use DISKPART to convert your OS drive to GPT and actually install and boot Windows in EFI mode (I may do a blog post about how to do this later).
A Lesson Learned
The take home from this? Although I eventually was able to get Windows 7 installed and booting from a GPT disk in full EFI mode, it was a real pain in the ass. Also, when I attempted to install the Intel chipset drivers, Windows refused to boot afterwords. As such, I just went back to a standard MBR-type disk and gave up on booting in EFI mode.
Click BIOS is pretty cool, but MSI still has a lot of bugs to work out with it, and Microsoft has a long way to go to make Windows EFI ready. I can only hope that I get in to the Windows 8 beta so I can start submitted EFI bugs!
Tales from Support: The Wallpaper
One of my jobs at QWE Computers was to do on-site visits to homes and businesses throughout the area. The subject of these service calls varied, sometimes being for a network setup, other times for a printer issue, etc.... No two were ever the same, and there were always interesting people to meet.
It had been a rather busy day, and I was headed up to my last call. And by headed up, I mean up. My destination was a gigantic log home in the mountains just outside of town (a half-hour drive constitutes as 'just outside' around here). Upon arriving, I introduced myself, confirmed this was the right place, and was taken to the office with the offending computer.
The system, much like the couple, was old - a Pentium 2 300Mhz with 64MB RAM. The couple were in their late sixties, and also a little short on memory. I was asked to give the computer a once-over, make sure Windows was up-to-date, and load on some anti-virus software - pretty basic stuff. Hitting the power button, I watched the POST screen for a solid thirty seconds, and then the boot logo appeared. I think it looked something like this:

Slightly horrified, but knowing the computer probably wasn't able to run anything else (XP being at Service Pack 2 by this point), and that replacing the computer 'just wasn't in the budget', I continued on, working away.
As I got near the end of the cleanup, I noticed that Active Desktop was enabled. Normally this wouldn't be an issue, however for a computer with 64MB RAM, this simple visual tweak was literally bringing the computer to its knees. I offered to disable it, explaining what it was and that I could just reset the wallpaper. The couple agreed, and I unchecked the 'Use Active Desktop' option. Then my jaw hit the desk.
You see, when Active Desktop is enabled, and you apply a wallpaper, it doesn't replace the existing one. Instead, it places the new one over top. When you disable Active Desktop, it removes that new layer, and you see the wallpaper that was there in the first place.
In this event, that wallpaper happened to the customer's 60-something wife, completely naked, sitting on the floor with her knees up to her chin, with literally everything on display for the world, or at least me, to see.
Scrambling as fast as I could I reset the wallpaper to one of the stock ones, scrawled out an invoice, grabbed the cheque, and practically ran for the door, not making eye contact at all. I don't know what happened that couple, because oddly enough, I was never called back again....



