So, one of the big issues I’ve had with the Windows 8 Consumer Preview is that Microsoft now not only forces you to use Digitally Signed Drivers (this isn’t new, as Windows 7 requires them as well), but also checks to see if the driver has been modified and will fail to install if it has.

This is a problem for anyone who needs to modify a driver .INF to support their device (*cough*Android ADB Drivers*cough*). Fortunately, there is a (slightly complicated) workaround.

To get started:

  1. From the Metro Start Screen, open Settings (move your mouse to the bottom-right-corner of the screen and wait for the pop-out bar to appear, then click the Gear icon).
  2. Click ‘More PC Settings’.
  3. Click ‘General’.
  4. Scroll down, and click ‘Restart now’ under ‘Advanced startup’.
  5. Wait a bit.
  6. Click ‘Troubleshoot’.
  7. Click ‘Advanced Options’
  8. Click ‘Windows Startup Settings’
  9. Click Restart.
  10. ???
  11. Profit!

When your computer restarts, select ‘Disable driver signature enforcement‘ from the list. You can now load your modified driver. Reboot again once the driver is installed and all will be well.

Our accountant’s computer has been dog slow for the last six or so months, so after going through the lengthy process of spec’ing a new system and getting the purchase approved, I was finally able to get her a replacement. The new system, with massive amount of RAM and a screaming processor (with a nice SSD to top things off) truly is a thing of beauty, however we ended up running in to a rather large problem.

Because the new system runs Windows 7 x64, we had to upgrade our slightly-old copy of Pervasive SQL 10 to Service Pack 3. Although this seemed to work fine with ACCPAC initially, we quickly discovered all was not well.

Case in point, when trying to print an invoice with a custom Crystal Reports template, ACCPAC would simply throw the following error:

not enough memory for operation

Searching Google got me nowhere. The few references to that error and printing only spoke of issues with Terminal Server environments, and none of the suggested steps worked. After a few hours of fighting, though, I had the bright idea to try using one of the stock invoice templates.

Go figure, it worked.

As it turns out, the CR templates we were using dated back at least six years, and had been created with a copy of Crystal Reports 7 (dating from 1999!). So, we downloaded a trial copy of Crystal Reports 2011, re-saved the templates, and the memory error disappeared without a trace. There were a few issues with the templates (some fields refused to populate), but some manual adjustments (read: copy and pasting sections for the working stock ACCPAC templates) solved that as well.

TL;DR Version: If you get the above memory error when trying to print from ACCPAC using custom Crystal Reports templates, try re-saving them with a newer version of CR. Apparently that’s all it takes.

My biggest complaint about Symantec End Point is that the manager console is slow. On a dual quad-core server with 16GB of RAM, it simply crawls. Sometimes, even when the system load is basically zero, the console is almost unusable. I did a little digging and found that the manager console is, in fact, written in Java –  that explains a lot.

Fortunately, because it’s written in Java there’s a little trick you can you to speed things up a little, assuming you have a decent amount of free RAM. The manager console is typically launched through sesm.bat, which is located (in a default install on an x64 server) in “C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\bin\”. Open that .bat file in notepad, and you’ll see this:

@start “SESM” “C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\jdk\bin\javaw.exe” -Xms128m -Xmx1024m -XX:MinHeapFreeRatio=30 -XX:MaxHeapFreeRatio=40 -Dscm.console.conf=”C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\tomcat\etc\conf.properties” -jar “C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\tomcat\webapps\scm\clientpkg\scm-ui.jar”

Note the bit that I’ve highlighted above in red. Boost that up a little (I set it to 512m), save, and then re-open the management console. You should notice a significant difference in how fast the console operates now.

There are a number of articles out there about how to bulk-update permissions on calendars in Microsoft Exchange, most of them pointing to the PFDAVAdmin tool. The problem, though, is that you have to read the requirements for it very carefully. Case in point:

PFDAVAdmin "could not expand"I ran in to this when trying to run the tool from my Server 2003 x64-based Exchange 2007 server. It happened again when I tried to run it from a Server 2008 x64 box, and from my Windows 7 x64 workstation.

As it turns out, PFDAVAdmin requires .Net Framework 1.1 to be installed. It isn’t recommended to install that directly on to your Exchange Server as it can cause issues with .Net 2.0, so I simply installed it on my Win7 x64 box, ignored the Compatibility Warning, and that was it – PFDAVAdmin worked perfectly.

That’s one heck of a long post title, but it at least describes the issue. Here’s the setup:

  • 1x Windows Server 2008 R2 with Hyper-V/AD/File Server roles, and two shared folders. Server has dual onboard NICs, one with full access to the client network below, the other to a separate network to allow the server to be managed remotely (no gateway configured on this NIC).
  • 18x Windows 7 x86 clients
  • Standard network setup (read: no VLANs, bridging, etc…. Just one network switch).

The previous server used by these clients worked perfectly. However, upon replacing the server with the one above, my users began noticing an odd issue. If they copy one or more files/folders to a share that is visible to all of the computers, the file(s) don’t immediately show up on all of the computers – usually 3/4 of the computers will see the file(s). On the 1/4 that don’t, users either have to wait ~10 minutes before the files will appear, or they can reboot to force a refresh. Simply pressing F5, or right-clicking in the shared folder and choosing ‘Refresh’ doesn’t work – only waiting or rebooting does.

In terms of a solution, I’ve seen a number of suggestions, but none seem to work. The server has dual-onboard Broadcom Gigabit NICs, and a number of forum posts have suggested disabling Checksum Offload and Large Send Offload, but this made no difference. Neither did disabling IPv6 on the client and server side. Disabling firewalls on the client and server side made no difference, nor did this post suggesting a few registry settings to change.

What did fix the issue, though, was disabling SMB2. Once all of the clients were connecting using the old SMB protocol the issue disappeared. I have no idea why SMB2 is an issue as I haven’t take the time to troubleshoot further with SMB2-specific settings, however this at least has things running normally.

TL;DR Version: If you have clients connecting to a Windows Server 2008 R2 box and the contents of file shares aren’t refreshing immediately or until reboot, disable SMB2 on the server.

Yesterday, while running a large lump of Windows Updates, one of my Windows Server 2008 x64 boxen decided to start boot-looping in the most annoying way. After applying a group of around ten updates and restarting, the server rebooted to the Welcome Screen and hung on the message “Please wait for the Windows Modules Installer” before eventually giving up and rebooting. After that, it booted back to the Welcome Screen and this time displayed the “Configuring Updates Stage 3 of 3 0%” message. All was well, I thought, until two minutes later when the screen went black and the server (gracefully) rebooted again, and then proceeded to loop under the same conditions, regardless of which startup mode is selected (Safe Mode, Last Known Good Configuration Mode, etc… will all produce the same results).

The news, unfortunately, isn’t good. Google was little help in the case, as most of the suggestions didn’t work. The only one that did was the suggestion to rename pending.xml in C:Windowswinsxs, however this comes with a

VERY BIG,
ALL-CAPS,
RED-LETTER WARNING:

By renaming said .xml file, your server will boot. It will still briefly display the Configuring Updates message, however the login screen will appear very shortly after. The problem is that, because there are updates that have been partially installed and aborted, Windows Update is now borked (attempts to run it will only result in a 0x8000FFFF error code, which is a generic code for “Something is broken, but we don’t know what”). Based on my own experience, and that of others, there is really no way to fix it. Sorry. Microsoft KB article 946414 that suggests that this error state can be fixed by deleting the PendingXmlIdentifier value from HKEY_LOCAL_MACHINECOMPONENTS, however it doesn’t work in this case, as the entire Windows Update backend is full of half-completed operations that can’t be cleared or rolled back.

In short, if this has happened to you, I regret to inform you that your server is basically FUBAR – the only upshot of this is that as the server will now boot entirely to the desktop, and (unless something is really broken) all services should be working (note: I did have to reboot any Hyper-V virtual machines that were suspended during the reboot in order to regain network access to them). As such, you should be able to do whatever is needed to backup the server before reformatting it. Even in the event you could get Windows Update working again, I wouldn’t trust the server in a production environment.

TL;DR Version: If this happens to you, rename c:windowswinsxspending.xml using a Windows DVD to boot from, and then backup the server in prep for a reinstall.

Last month our in-house web-dev/graphic-designer moved across the country and I ended up taking over most of her responsibilities. This afternoon our General Manager asked me to put together a news paper ad, so I fired up Adobe Illustrator and grabbed a copy of our branding guide. After figuring out that I needed a few variants of Helvetica, I proceeded to hunt through the metric ton of fonts in Illustrators type menu, only to find all of my Helvetica fonts were missing.

Thinking this odd, I popped in to Microsoft Word and saw that yes, all of my fonts were there. Photoshop, though, wouldn’t show a number of them either. In fact, all of the missing fonts were Type 1.

As it turns out, Adobe doesn’t play nice with Type 1 fonts, and requires that you place them in following folder:

C:Program FilesCommon FilesAdobeFonts

Important: If you’re using a 64-bit version of Windows, place them in:

C:Program Files (x86)Common FilesAdobeFonts

Once you’ve copied the fonts to that folder (note that if you already have them in another folder, you can just add a shortcut to them instead), restart the Adobe product and it should show all of your fonts!

I was trying to assist another admin with a login issue on a Windows Server 2008 terminal server when I encountered a slightly different login error than the one he was describing. When attempting to connect to the terminal server with a user not in the Domain Administrators security group I received the following message:

“The requested session access is denied”

The problem, it turns out, was me. When connecting, I used a desktop shortcut for Remote Desktop Connect that had the “/admin” switch applied, which instructs Remote Desktop to connect to the Console session, which is restricted to administrators only. Using a regular shortcut without said switch solved the problem.

D’oh.

I’ve only used Microsoft SteadyState a few times, but it’s a great product if you can’t afford the per-seat licenses for Faronics Deep Freeze. So when I was given the task of putting together a small lab environment with old computers and no funding, SteadyState was the first thing that came to mind.

Unfortunately, when I went to download the latest version of it, 2.5, I found this notice on the download page:

ANNOUNCEMENT: Windows SteadyState will continue to be available for download through December 31, 2010. Support for Windows SteadyState will continue to be available through the Microsoft Knowledge Base portal through June 30, 2011.

This announcement does not affect your right to continue to use Windows SteadyState.

Wait, what? Further digging revealed almost no information other than a vague statement saying that SteadyState wouldn’t be updated to support Windows 7. Additionally, while the system requirements state that Windows XP SP3 is supported, there are no references to IE8 — only IE7. Even worse is the list of Windows Vista supported versions — RTM and SP1 only.

I decided to try it out on a Virtualbox VM running XP SP3 and Internet Explorer 8 (although it technically isn’t supported), as that’s what my little lab will be running, and the results were actually pretty surprising. SteadyState actually works quite well with IE8 – all of the restrictions/settings function as expected, and it’s very easy to lock everything down.

So if you’re looking for a free alternative to Deep Freeze, and running Windows XP, then SteadyState is the way to go – just make sure to grab it before December 31st of 2010, or you’re out-of-luck. If you’ve moved on to Windows 7, though, prepare to pay up for a few Deep Freeze licenses (which, to be fair, are worth the cost if you can work it in to a budget).

Update: Microsoft has published a posting on the Windows Team Blog about why SteadyState wasn’t updated for Windows 7. As some of the comments say, the whitepapers provided fall short of what most admins who use[d] SteadyState want — disk protection that isn’t available in Windows 7.