I’m in the process of converting my home server in to a CentOS SMB server and XBMC combination box. In the process, though, I ran in to a problem where PulseAudio would recognise the HDMI audio capabilities of the video card (after installing the Nvidia binary drivers), but wouldn’t output any sound. After a lot of digging and swearing, I finally fixed it by doing the following:

As a normal user, open a Terminal window and enter alsamixer. Press F6 and then unmute all of the audio channels (do so by selecting them with the arrow keys, and then pressing ‘m’. When done, press ESC to exit.

After this, su - to assume root, and then type aplay -l to get a list of your audio devices. In my case, I’ve disabled the onboard audio, so the only devices are the Nvidia ones. The output will look something like this:

root@wormwood ~]# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 7: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 8: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 9: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0

Note that while there are four devices, the first one (which Pulseaudio selects by default) doesn’t do anything. To get this to work, we need to tell it to use the second device (#7). This isn’t horribly easy. If you have another sound card, note the device numbers listed for it above – you’ll need them in a minute.

Finally we can tell Pulseaudio to actually use the correct devices. Still as root, open up /etc/pulse/default.pa and find these lines:

### Automatically load driver modules depending on the hardware available
#.ifexists module-udev-detect.so
#load-module module-udev-detect
#.else
### Alternatively use the static hardware detection module (for systems that
### lack udev support)
#load-module module-detect
#.endif

Now, comment them all out as I have done above. This prevents Pulseaudio from trying to be smart. Now, scroll to the end of the file and add the following line (if you have more than one audio device, you will need to add it multiple times with the correct card and device numbers that you gathered from aplay above):

load-module module-alsa-sink device=hw:0,7

Now simply do a killall pulseaudio and try to play something. You should have audio output over HDMI now!

Edit: Just a bit of follow-up if you’re having trouble with the sound muting after every reboot. As root, enter the following in a shell:

touch /etc/asound.state

chmod 777 /etc/asound.state

Now, as a standard user, follow the instructions above to unmute the Nvidia device channels via alsamixer. Once you’ve confirmed sound is working again, from a shell (still not as root!) type:

alsactl store

Now go back as root and:

chmod 644 /etc/asound.state

When you reboot, you shouldn’t have to unmute through alsamixer anymore.

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.

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.

Yesterday, I decided to encrypt my Toshiba Satellite C650D laptop with TrueCrypt – I opted for Full System Drive encryption, which involves TrueCrypt adding its own bootloader. After answering the usual questions from the setup wizard, it prompted me to reboot to test the settings. After Windows restarted, I was prompted to enter the password I had specified earlier. The only problem was, when I started typing, nothing happened – I also couldn’t use ESC to bypass the password prompt, or CTRL+ALT+DEL to reboot. My only option was to power off. When I turned the laptop back on, though, I was able to enter the password without issue.

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.

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 came back from vacation the other day to find that some computers on our primary domain (example.local) were unable to access shares on a secondary domain (test.local) located in another building, accessed via a wireless link). When attempting to open the share (or just browse to the Domain Controller), the following error would appear:

Share Error

"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:

DNS Error

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!

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.

More »

I recently moved servers to a new host (a friend of mine had provided me with a free CPanel account on his VPS before this), and the transition had appeared to work rather well. Then, when I checked my blog stats this morning, something seemed off:

Blog Stats

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"

Microsoft Security EssentialsI downloaded the Microsoft Security Essentials Ongoing Beta from Microsoft Connect this evening, and as before it installed normally. However, when I tried to update it to the latest version (the setup file on Connect is very out-of-date) the definitions came in fine but the core product refused to upgrade and only provided the error code 0×80070050.

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

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)!