Search This Blog


Monday, February 24, 2014

Windows 7 .reg Files and Login Scripts Don't Mix

So, I spent far more time than I should have beating my head against the wall tying to solve what should be a simple matter.

A hardware device stores it's settings in HKCU. Dandy. Domain users need to have these settings applied at logon since the settings can easily be wiped out by an update to the related software application that writes to the device. Great. No problem. The original solution in place since Windows 2000 was to reference a .reg file from a login.bat file. The batch file would first map the network location as a drive, then load regedit.exe /s settings.reg to adjust the settings. Quick, dirty, worked flawlessly (with occasional updates to the .reg file as the hardware driver was updated). Windows XP worked fine with this solution.

Now the landmine. On a Server 2003 forest/domain, introducing Windows 7 clients. Now, writing to the registry triggers UAC, freaks out users, and happens to fail miserably. OK, should be an easy fix, move the registry settings to Group Policy Preferences. After all, that's what it's for, right? Well, it fails. Again, no error message, no indication of what's going on, it just does nothing. OK, fallback position, create a login script in a GPO policy to reference regedit.exe /s settings.reg and load that way. Nope, not gonna happen. OK, try something different, reg import settings.reg should bypass UAC and allow the settings to import. Nope. Basically, it comes down to once the user logs in, they can not write into the registry no matter what.

But, there's a way around it, and it works beautifully. PowerShell. The ability now exists in Group Policy Management to set a PowerShell script to run at login. Here's a sample of what I did, and just for fun, some of the settings are in hex stored in a binary key apparently just because the vendor could do it that way. Thanks a lot. So, I installed the device, used RegShot to get a snapshot of the settings, set the device up the way it should be, and the second RegShot showed me the affected keys. I exported the relevant parts of the registry and used Notepad++ (I LOVE Notepad++) to quickly reformat the file into something I could paste into the PowerShell script. Much faster than typing out 120 hex entries by hand.

Set-Location HKCU:
New-Item -Path .\Software -Name VendorName -Force
New-Item -Path .\Software\VendorName -Name DriverVersion -Force
New-ItemProperty -Path .\Software\VendorName\Version `
-Name "KeyName" -PropertyType DWord -Value '0000004' -Force
New-ItemProperty -Path .\Software\VendorName\Version `
-Name "KeyName2" -PropertyType String -Value `
"C:\Folder\Subfolder\filename.txt" -Force
New-ItemProperty -Path .\Software\VendorName\Version `
-Name "KeyName3" -PropertyType Binary -value `
([byte[]] (0x49,0x00,0x6f....0x6e)) -Force

So, there it is. The backtick (`) is a line continuation character for PowerShell, in the original script each entry is on one line. The -Force at the end basically tells PowerShell to delete the entry if it already exists and re-create it. This means that you have to be careful to establish the path to the parent keys first before working with the subkeys, but it also means that you can be assured of the correct settings being applied even if a user has monkeyed with the the settings at some point. Save the file as a .ps1 file and import it in the GPO under User Settings, Policy, Windows Settings, Logon Scripts. Just for kicks I also signed the script with a cert that is imported as a trusted publisher so that I can re-apply as needed without the user having to logoff, but it works fine in the GPO without code signing.

Wednesday, January 2, 2013

Linux, Windows, and FreeBSD Multi-Boot

OK. I've seen lots of questions about how to do this, but no answers that worked. (For me, at least.) So here it is. Just for the sake of making life a little more fun, The setup I'm using has three separate hard drives.

Drive 1: 2TB drive with Win7
Drive 2: 1TB drive with Ubuntu 12.10
Drive 3: 80GB drive with FreeBSD 9.1-RELEASE.

First, install Windows to the first drive. If Windows is installed later, it will mess with the boot sector causing more work. Once Windows is installed, install Linux to the second drive and set GRUB2 to install to the first hard drive boot sector. Verify that this is all working and apply all updates available, especially on the Linux side to make sure GRUB2 is up-to-date.

Now the fun begins. Install FreeBSD to the third drive. Do not allow it to change any boot sectors, and when the install finishes boot into Linux again.

Once you've booted into Linux, verify that the drives are identified the way you think they are. (Win on /dev/sda, Ubuntu on /dev/sdb, and BSD on /dev/sdc).

Open a command prompt and (at the risk of offending editor purists) type the following:

$ sudo nano /etc/grub.d/40_custom

Add the following after the comment block:

menuentry "FreeBSD" {
        insmod ufs2
        set root=(hd2)
        chainloader +1

Save and exit the file.

Next you need to tell GRUB2 to rebuild the menu:

$ sudo update-grub

Reboot and try it out. You should now be able to boot into all three systems seamlessly.  

Monday, July 16, 2012

GLPI and updated Fedora

After updating Fedora to release 16, all the automatic actions in GLPI stopped working. Apparently somewhere along the line all the cron jobs got deleted.

Log into the GLPI server and check:
#crontab -u apache -l

If the list is empty, here is a way to fix it. Be sure to adjust the file locations for the environment:
#crontab -u apache -e

This will open vi. Press i to enter insert mode. Type in the following each entry all on one line(use the second line only if you are syncing with OCS-NG as well).

*/1 * * * * /usr/bin/php /usr/share/glpi/front/cron.php &>/dev/null
*/1 * * * * /usr/share/glpi/plugins/massocsimport/scripts/ &>/dev/null

Write and quit.

Additionally, there's a good chance the crond service is not enabled. Perform the following:

#systemctl start crond.service
#systemctl enable crond.service

Check the Automatic Actions screen in GLPI, make sure the tasks are set to run in CLI mode. Refresh the screen to make sure everything is working as expected.

Friday, October 7, 2011

Need to edit a Word "Protected" Document?

So, what happens when a VP forgets the password he or she used to "protect" a Word document from being changed? They panic. Then they blame I.T. for failing to warn them of the danger of a lost password. Yeah, one of THOSE days....

Never fear, however, this is a password scheme from the same folks that gave us LANMAN. There is a way around it.
  1.  Open the document normally. Save it as a web page.
  2. Open the web page version in your favorite text editor (Notepad++ works well).
  3. Read through all the awesome tags that get embedded, including one nifty tag labled <w:UnprotectPassword> with a hex string after it. "Could it really be that simple?", I hear you cry. Yes. It really is that simple.
  4. Open the original "protected" document in your favorite hex editor. Search for the string you pulled from the web page version. (Remember little endian. If the string was 12345678 then search for 78563412)
  5. When you find the string, change it to 00000000. Save the file.
  6. Re-open in Word. Turn off protection and, if it asks, don't enter a password, just leave it blank.
Congratulations. It really is that simple.

Wednesday, July 27, 2011

More ESXi 4 Patching

This is really a follow-up to my previous post about patching an ESXi server. Between release 4.0.0 and 4.1.0 VMware removed a tool from the vSphere Client installer. I'm not sure why but hey, that's why they make the big bucks. If you install the vSphere Client 4.0 it gives you the option of installing the vSphere Host Update Utility. This is a nifty little tool that is exactly what it sounds like. It allows you to connect to a single ESXi server and update it with a nice simple GUI. No need to install the CLI package which has the Perl dependencies. However, as I said, the vSphere Client 4.1 installer no longer has this utility so if you don't already have it installed, you're out of luck. Partially. The good news is you can still get it, at least for now. It takes a lot of digging through VMware's download site to find.

Now, on a slightly different note. I ran into a slight conundrum with vSphere. Here's the scenario:
  • A single ESXi server at location 1, a single ESXi server at location 2, and a single ESXi server at location 3.
  • The licensing is for vSphere Essentials. All servers are dual-processor so there's no room for an extra server floating around.
  • Location 1 is the backoffice, so that server has the VM with 2008R2 running the vSphere Server on it. The Update Manager add-on is installed.
How do you patch the server at location 1? You can't do it through vSphere because it will crash your server in the middle of the process. You can't migrate the vSphere Server to another ESXi server because it's Essentials and they are across WAN links. Here is the only answer I've come up with so far:
  1. Connect the vCenter client to the ESXi server at location 1 directly, instead of the vSphere Server. Ignore the warning about it being managed.
  2. Shut down the vSphere Server manually.
  3. Patch using one of the two standalone server methods.
  4. When the ESXi server is back up, connect directly to it again.
  5. Check the settings for the vSphere Server and bring it up.
  6. Continue patching the two remote servers from vSphere.
It's a pain. If anyone has any better solutions short of upgrading to high availability, I'd love to hear them.

Saturday, June 18, 2011

BackTrack 5 and startx crashes HARD

Well, this one wasted a few hours before I finally found the answer in the BT5 forums. Thanks to freesom and snipes420. Here's the problem, running BT5 from a USB stick or DVD works just fine. GNOME has no problems, KDE might require deleting a few cache files (thanks to fnord0):

rm /root/.kde/cache-root/icon-cache.kcache
rm /root/.kde/cache-root/plasma_theme_Volatile.kcache
rm /root/.kde/cache-bt/icon-cache.kcache
rm /root/.kde/cache-bt/plasma_theme_Volatile.kcache

and possibly:

rm -rf /var/tmp/kdecache-<username>

Where things get nasty is when you try to install BackTrack to the hard drive. It'll install and boot wonderfully, but when you try to run startx you end up with a black screen and a flashing Caps Lock light. The only way out is a hard shutdown. This is apparently happening on a number of different machines, the one I experienced it on is a Toshiba Portege R700-S1312. It's a great little laptop, especially since I've been getting 8-9 hours of life out of the battery.

So, here's the fix:
  1. Edit the file /etc/default/grub
  2. Find the line: GRUB_CMDLINE_LINUX_DEFAULT="text splash nomodeset vga=791"
  3. Change it to: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.modeset=1 vga=791"
  4. Save and close the file.
  5. Run update-grub to refresh grub.
  6. Reboot
Everything should work happily now. Good luck.

Wednesday, May 4, 2011

Office File Validation Woes

This was a painful one. Microsoft recently released a patch that enabled Office File Validation for Office 2003 and 2007. Great idea, but there is one small problem. If you're in an environment that lives or dies by Excel spreadsheets from a network location and those spreadsheets were created with an older version of Excel, the enabling of OFV causes great pain and suffering. Basically the problem is that it suddenly takes 15 minutes to open a 300K file. Multiply that out to 1 or 2 MB files, and several different spreadsheets throughout the day per user and the IT department suddenly becomes extremely unpopular!

The good news is that you can make it go away. The bad news is that it has to be done per user/per machine. Create a GPO and in the User Configuration section have it add the following registry location:


Change the <application> to Excel, Word, or Powerpoint depending on which application you need to disable validation for.

In that location, create a key with the value name EnableOnLoad, type REG_DWORD, and set the value data to 0. (That's a zero.)

No need to reboot or logoff, it takes effect immediately.

Microsoft has released a marginally well-hidden TechNet article about the issue here: