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.

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.

After the encryption process finished, I rebooted the laptop again, only to find that keyboard input still wasn’t working when I needed to enter the bootloader password. Again, though, after powering it off and back on everything worked fine. On a hunch, I shut down the laptop completely, then turned it back on, and was able to enter the password without issue.

As it turns out, if you have Toshiba’s ‘Fastboot’ feature enabled in BIOS (allows for < 1 second from power button to bootloader, bypassing the BIOS splash screen and, apparently, some hardware initialization steps), TrueCrypt won’t recognize your internal keyboard (unfortunately, I didn’t have a USB keyboard handy to see if that would work) – but only on a reboot. From a cold boot, the keyboard is apparently initialized differently and works fine.

TL;DR Version: If you use TrueCrypt to encrypt your System Drive and have Toshiba Laptop, don’t use the Fastboot option in BIOS or you will not be able to enter your bootloader password when you reboot and will be force to cold boot every time.

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!

"There are currently no logon servers available to service the logon request."

Google’ing did no good, as there were only vague references to DNS issues and WINS servers (the later of which we don’t use). As nothing had changed in the environment recently, I was at a bit of a loss. I could ping the DC (Homer) in question, and even RDP to it, but I couldn’t for the life of me access the share. NSLOOKUP behaved normally, but then I had a thought — the DC that I couldn’t access was also acting as a DNS server (the primary one for test.local) with example.local as a Secondary Zone (which, of course, contained the DNS entries for the computers that were having trouble accessing the secondary domain). When I loaded the DNS manager and clicked on that zone, I was immediately greeted with an error stating the following:

Turns out, there *was* a DNS problem!

The problem was that I had removed a DNS server over a year ago and it was still referenced as the primary DNS server for this zone. For some reason, the Windows DNS service had just now decided this was a problem and stopped grabbing copies of the zone from the functional secondary DNS server.

To fix this, I simply right-clicked on the zone, chose Properties, and then removed the offending server IP from the General tab and updated with the correct servers and order. As soon as I finished, the computers had no trouble accessing that DC again. Magic!

Background
I work for a non-profit organisation that’s primarily funded by the government. As such, we receive only a little funding for ‘technical extras’, and sadly even a cheap Class 2 SSL cert is out of financial reach at this time. The has caused a bit of a problem.

We run an Exchange 2007 server on a Windows Server 2003 box with Active Directory in along side the primary and secondary domain controllers. Our internal network was setup (by my predecessor) as foo.local. Our email, on the other hand, is hosted externally (as our ISP does not allow email servers on business accounts – go figure) on the domain mail.bar.com. Because of foo and bar, a single Class 1 Cert can’t be used – and therein lies the problem.

When I access OWA (Outlook Web App) internally, I can use the internal name of the mailserver (mail.foo.local), which uses a self-signed Class 1 Server SSL cert by the Windows Server built-in certificate authority.  Of course, when accessed externally, my browser flips out because it doesn’t recognize my own certificate authority as valid and the name on the cert itself doesn’t match (mail.foo.local compared to the external domain exchange.bar.com). Although this is technically alright, because I know enough to verify the cert manually, this confuses my users and can potentially lead to man-in-the-middle attacks.

The Solution
IIS only allows one SSL cert per Web Site. Without a Class 2 SSL cert (they allow for multiple domains to be specified) it isn’t technically possible to have two domains SSL-protected. If I apply a valid Class 1 cert for the external domain, the internal Outlook clients will throw the SSL error instead, which is much more of a problem.

Therefore, the solution is two create a second Web Site (with different port assignments, otherwise you need a second NIC and IP address) in IIS and mirror the OWA and ActiveSync Virtual Directories. This is actually easier than it sounds. Note that the following instructions are for IIS on Windows Server 2003, and Exchange 2007.

1. Open IIS, then expand the Web Sites entry.
2. Right-click on the Web Sites entry and choose “New” -> “Web Site”.
3. Choose “Next”, then give it a name (and remember it – I chose “OWA-External”), and “Next” again.
4. If you have a second NIC/IP address on the server, specify it. Otherwise, change Port 80 to an unused port (I choose 82), then click “Next”.
5. Choose a new folder to be the root of the website. It’ll stay empty, so it doesn’t matter where you put it. I created C:\inetpub2. Click “Next” again.
6. Leave the defaults selected (Read), then click “Next” and “Finish”.
7. Right click on the new website (“OWA-External” in this example”) and choose “Permissions”.
8. Add the “Internet Guest Account” for your server (typically, DOMAINIUSR_SERVERNAME) and give it Read, Read & Execute, and List permissions.
9. Click OK and close IIS.

Now that the website is setup, we need to tell Exchange to create the Virtual Directories. If you try to manually create them in IIS by mirroring the settings from the existing entries under the Default Web Site, you won’t be able to access OWA.

1. Open the Exchange Management Shell.
2. Type Get-OwaVirtualDirectory and press Enter. This will show the existing Virtual Directories.
3. Now type New-OwaVirtualDirectory -WebSiteName “OWA-External” (replacing OWA-External with your website name) and hit Enter. It make take a minute or two to process, depending on the speed/load of your server.
4. If you don’t get any errors, type Get-OwaVirtualDirectory again and you should see a new owa entry in the list.
5. Next is to create a new ActiveSync Virtual Directory in the new site. The command to do that is New-ActiveSyncVirtualDirectory -WebSiteName “OWA-External” -ExternalURL “http://exchange.bar.com/Microsoft-Server-ActiveSync” (replacing OWA-External and the URL with your own, of course).

Now open up the Exchange Management Console. Browse to Server Configuration -> Client Access. Under the Outlook Web Access and Exchange ActiveSync, you should now have two entries each – one for the original Web Site (usually Default Web Site), then one for the one you just created.

Now you’re almost done. Back in IIS, open the Properties for the new Web Site and set your SSL port to something other than 443 (unless you have two IP addresses on the server), then install your valid Class 1 SSL cert for your external domain (exchange.bar.com, in this example – I got my Class 1 cert free from www.startssl.com). The only thing left to do now is to port forward. On your router/gateway/firewall/whatever, forward port 443 to your Exchange server’s IP (or second IP if you’ve set it up that way) and, if appropriate the correct port. In my case, I forward port 443 to port 444, as well as port 444 to 444. Both are necessary if you’re using a port other than 443.

Once all this is done, restart IIS on your server and all should be ready. You’ll now have a valid cert internally and externally!

See that last big dip? Guess when that happened!

So I started looking around the site, and sure enough – the main pages displayed fine, however everything else was broken. In fact, anything with a ‘fancy’ permalink was 404′ing.

Once again, a quick Google search lead me to this thread on the WordPress forums. After digging around, I found the problem – in Apache’s httpd.conf file on my new VPS, I needed to change the following line:

AllowOverride None needed to be AllowOverride All

Note, though, that there are two AllowOverride entries in httpd.conf – one wrapped in <Directory></Directory> tags, and one all by itself. The problematic one is the second AllowOverride entry that isn’t wrapped in Directory tags.

TL;DR Version: If you enable fancy permalinks in WordPress, and start getting 404 errors in Apache even with a proper .htaccess file and mod_rewrite enabled, change AllowOverride None to AllowOverride All in httpd.conf – just make sure you do it to the second AllowOverride entry!

Updated! If you’re using nginx instead of Apache, simply add the following to the location section of your nginx.conf file (or the one for your vhost, if you’re doing that):

if (

    !-e $request_filename) { rewrite ^.*$ /index.php last;

}

Updated again! If you’re using ligHTTPD, you can add the following line to lighttpd.conf (although if you are using your own custom 404 error page, you may wish to find another solution):

server.error-handler-404   = "/index.php"

Event viewer wasn’t helpful, a reboot didn’t fix it, and neither did uninstalling/reinstalling. On a whim, though, I decided to try to the upgrade through Windows Update (after enabling Microsoft Update) and what do you know, it worked!

TL;DR Version: If you get the 0×80070050 error code while trying to upgrade MSE through the MSE program itself, enable Microsoft Update via the Windows Update Control Panel and do the upgrade from there.

An HP P4015dn - This morning, the bane of my existence

Note: Make sure to read over the comments on this post – there is some excellent advice there as well.

Windows 7 has been very good to me so far, but this morning I was literally pounding my desk in frustration over a printer issue. I just received two brand-new Dell Optiplex 780′s and was in the process of configuring the printers on them when I happened across this little message:

Windows Cannot Connect to the Printer: 0x0000007e

Now here’s the situation. The computers are running Windows 7 Professional x64. The printer (an HP P4015dn) is connected to a Windows XP x86 machine and shared normally. Of all of our printers, this is the only one directly shared with a computer due to a wiring issue I have yet to correct (although now I’m going to make an effort to fix it). I have several other computers running XP and Vista (x86 and x64) that already print this computer without issue, so I was rather stumped. Then I realized I had attempted to install the Vista x64 Postscript drivers instead of the Windows 7 ones.

Unfortunately, Windows 7 no longer provides a dedicated ‘Printers’ control panel, and the ‘Devices and Printers’ one doesn’t have a Server Properties option to let you manage installed drivers. So, I stopped the print spooler service and manually deleted the drivers from C:\Windows\System32\spool\Drivers. When I tried to re-add the printer, though, I got this message:

Windows Cannot Connect to the Printer: 0×00000006

Hmm. Google wasn’t much help, so I went to an old standby – I mannually added the network printer by choosing to create a local port (silly, I know). Here’s how to get this working:

1. In the Devices and Printers control panel, choose Add a Printer.
2. In the new window, click Add a local printer.
3. On the following screen, select Create a new port, and then choose Local Port from the drop-down list and click Next.
4. When asked to enter a Port Name, use the full path to the printer. For example, if your printer share is called Dave and is a computer with the name PrintSrv1, you would enter \PrintSrv1Dave as the Port Name. If you receive an error saying The network path was not found, check the computer name and share name, then try again.
5. You should be asked to install a driver. Manually download the correct driver (in this case, the HP Universal PostScript driver worked for my HP P4015dn) from the manufacturer’s website and extract it to a folder on your computer. Then click the Have Disk… button in the Add Printer wizard and point it to that folder, then click OK and Next.
6. Wait for it to install the driver.

At this point, the printer should be installed and functional. Print a test page to make sure everything worked alright, and then do a little dance (as long as no one is looking)!

Oh, 'Downloading' message, how I hate thee.

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.

An Office program is slow or may appear to stop responding (hang) when you open a file from a network location

The program stops responding when you try to open or to save a file in an Office 2002 program, in an Office 2003 program and in an Office 2007 program

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: /delete

net use z: \10.0.0.100share