So the other, I finally got around to making things easier for myself. Rather than try to convince everyone to leave their signatures alone, and rather than go around to everyone’s computer and have them login so I can change their signature, I sent out instructions on how to set your signature in Outlook (in Options, under the Mail Format tab), and then hammered out a few lines in to the existing login script:

REM Copy email signature

c:

cd \

if exist %appdata%\Microsoft\Signatures goto COPY

md %appdata%\Microsoft\Signatures

:COPY

cd  %appdata%\Microsoft\Signatures

del *.* /q

copy Q:\Marketing\EmailSignatures\%username%.* .\

The first two lines (after the Remark) make sure that the script is in the root of the C: drive (other parts of the login script not listed here move around, and as we’re deleting files later on with a wildcard it’s worth it to make sure we’re in the right place).

Next, it checks to make sure that the Signatures folder exists. If you’ve already been in to the Signatures area in Outlook it will create the folder for you, however if this is the first time the user is logging in and their profile is just being created, that folder won’t be there, so we make Outlook create it.

After that, we delete the contents of the folder — I can do this because I know that our staff should only be using the one signature. If you’re in an environment where that isn’t the case, this is a Bad Idea.

Finally, we copy the new signature off the shared drive. In this case, we have a plain-text signature and and HTML version, and the filenames are prefixed with the users username, so I can make use of the username environmental variable to automatically select the right files.

The first time the script runs users had to go back in to Signature Options and select the new signature, but after that, because the filename doesn’t change, Outlook will remember the selection and staff will always have a copy of the (correct, consistently-branded) signature.

Like I said, very basic, and there are a few improvements that could be make to the batch script, but it works well enough for me.

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.

To use this, copy the section below to a text file and save it as ChangePass.ps1 - note that you will need to allow scripts to be executed before this will work. Information about running .ps1 as a scheduled task is available here.

#Import the Active Directory Module
Import-Module ac*

#Grabs a random line from WordList.txt (enter the full path, in quotes if the path contains a space)
$pwd = Get-Content C:\Script\WordList.txt | Get-Random

#Uncomment the next line to print the selected password to the console
#Write-Host $pwd

#Convert the selected password to a Secure String so it can be accepted by the commandlet
$secure = convertto-securestring $pwd -asplaintext -force

#Set the password – replace username
Set-ADAccountPassword -Identity username -NewPassword $secure -reset

#Write the password to a file so the staff will know what it is – add your own path
$pwd | Out-File “C:\Share\Todays Password.txt”

So when the script is down, the text file located in C:\Share (or whatever you’ve changed it to) will contain the password. Be aware that this file will be overwritten every time the script is run, so don’t edit the file – you’re changes will be lost.

Fast forward to today. I was messing around on that system and discovered that I left that one particular GPO in place. I fired up the Group Policy Management tool and removed the link to that GPO, did a gpupdate /force on that system, rebooted and went about my business. A few minutes later, I discovered that GPO was still in effect. I double-checked that the GPO wasn’t linked to that OU anymore, and that inheritance was still blocked, and did another gpupdate /force, but to no avail. A quick check of HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\History showed that yes, the GPO was still being applied.

I did a little head scratching, and then found the answer. As it turns out, after linking the GPO to the other production OUs, I selected the ‘Enforce’ option. By doing that, even after unlinking a GPO from an OU it will continue to be applied. I simply disabled the ‘Enforce’ option, ran yet another gpupdate /force, and all was well.

TL;DR Version: If you unlink a GPO from an OU, update the system, and the GPO is still being applied, disable the ‘Enforce’ option on that policy and do another gpupdate.

A few notes:

1. Make sure you have the latest firmware for your DIR-825 Rev. B. At the time of writing, it’s version 2.05(NA).
2. You will need to enable “WAN Ping Respond” – this can be found under Advanced -> Advanced Network. You can safely disable this after you finish complete the process and your tunnel is working. This is needed so that Tunnel Broker (TB, from here on out) can confirm your public-facing IP address and link it to your tunnel.

So, that out of the way, once Tunnel Broker has confirmed your tunnel is available, login to your router and do the following:

1. Under the main Setup tab, click IPv6.
2. Click the Manual IPv6 Internet Connection Setup button. Do not use the wizard.
3. For the IPv6 CONNECTION TYPE, choose IPv6 in IPv4 Tunnel.
4. In the Remote IPv4 Address box, enter the Server IPv4 Address provided by TB.
5. In the Remote IPv6 Address box, enter the Server IPv6 Address provided by TB.
6. The Local IPv6 Address is the Client IPv6 Address from TB.
7. Under the IPv6 DNS SETTINGS heading, choose Use the following IPv6 DNS servers and enter the Anycasted IPv6 Caching Nameserver provided by TB in the Primary IPv6 DNS Server box (TB did not provide me with a secondary DNS address).
8. Finally, uncheck Enable DHCP-PD under the LAN IPv6 ADDRESS SETTINGS heading.
9. Leave the settings under the ADDRESS AUTOCONFIGURATION SETTINGS heading as their defaults.
10. Click the Save Settings button at the top of the page and let the router do it’s thing. It will take some time to ‘measure the internet connection’ – this is normal.

You’re almost done. At this point, if you go to the Status tab and choose IPv6 from the options down the left side of the page, you should see the TB information you entered, and Network Status should say Connected.

The rest of the work depends on your operating system. I use Windows 7 on my main PC, which natively supports IPv6 (as does OS X and most *nix distros). As IPv6 is enabled by default, I simply had to open an Elevated Command Prompt and type:

ipconfig /release

ipconfig /renew

After it finished thinking, ipconfig spat out the new network configuration which included the correct IPv4 and IPv6 addresses. I opened Firefox and browsed to http://ipv6.google.com – success! Everything works! You can also confirm that IPv6 is working by using the nslookup tool from a command prompt like so:

C:\Users\Laslow>nslookup
Default Server:  ordns.he.net
Address:  2001:470:20::2

> xbox.com
Server:  ordns.he.net
Address:  2001:470:20::2

Non-authoritative answer:
Name:    xbox.com
Addresses:  2a01:111:f009::3b03
65.55.42.140

>

As you can see, the IPv6 nameserver came back with an IPv6 AAAA record (2a01:111:f009::3b03) and an IPv4 A record (65.55.42.140) for xbox.com.

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.

Fast forward to three years ago, just before I was hired. The then-sysadmin was getting flak for the VPN being slow, so he installed a pair of wireless routers on the roofs of the buildings and linked the two networks. However, instead of getting rid of DomainB, he simply left it in place.

Fast forward to now. Due to cost issues, the contact in the remote office was physically moved to our main building. As such, their network equipment and servers came with them, which created cramped quarters in an already cramped space. As such, I set about doing what should have been done years ago – migrating users from DomainB to DomainA.

There was a group of client computers that needed to go through a round of updates anyways, so those were simply re-imaged and joined to a separate, restricted network (DomainC) used for our clients only (this had been another pet peeve of mine – due to costs, the clients in that office were put on the same network and although they had their permissions restricted, it was still a concern in my mind). The main problem, though, was the staff workstations. Not only were they setup on DomainB, put PrimaryDC.DomainB was also an Exchange 2003 server, and TertiaryDC.DomainA was our primary mail server running Exchange 2007. The first step was to manually export the mail for the twelve staff members and create their DomainA accounts, and then get them setup on the DomainA Exchange server. Once that was up and running, the Exchange 2003 install was shutdown. Although it took a while to manually transfer the mail by exporting to .PST files and then importing it again, it was the cleanest way to do the move (and also encouraged users to clean out their mailboxes).

The last step was to actually get the users logging in to DomainA rather than DomainB. That’s where ADMT (Active Directory Migration Tool) comes in.

ADMT comes in a few ‘current’ versions. 3.0 if the server it’s running on is Server 2003, 3.1 if it’s Server 2008, and 3.2 if it’s Server 2008 R2. The source domain (B) was running on Server 2003 boxes, but the target domain (A) was running mostly on Server 2008 boxes, so I installed ADMT 3.1 on one of those.

After getting it installed and playing around with it on a test VM, I learned a few things that helped me get all of the staff workstations migrated with minimal issues:

• Setup a Two-Way Trust between the domains first, but be aware that if users are already authenticating on both domains by using store credentials, that may break unless you also setup permissions for users of both domains on effected shares.
• Double-check your DNS configuration. If both domains have separate Forward Lookup Zones (which they probably do), make sure that the DNS servers in both domains are setup to perform Zone Transfers between each other, and then check to make sure that all A and PTR records are actually correct and current.
• Make sure that the user you are logged in to on the server running ADMT is in the Domain Admins group on the target domain, and the Administrators group in primary DC on the source domain.
• Change the DNS servers that the computers to be migrated are using to the servers on the target domain. This is important, or after the computer migrations are complete you may run in to issues when logging in (for me, Active Directory decided to continually lock out user accounts of migrated users because of a missing A record in the source domain’s DNS zone).
• If you have any local firewall software running on the workstations that are to be migrated, either temporarily disable it or add exceptions for the Netlogon Service, File and Printer Sharing, and Windows Management Instrumentation (although the last may not strictly be needed – it was hit-or-miss for me).
• Run the following command on the workstations that you’re migrating: net localgroup “Administrators” “DomainAdomain admins” /ADD (changing DomainA to your target domain). This is important, as local admin rights are needed for the computer migration steps.
• If users from your source domain are using resources on your target domain and using stored credentials to authenticate, delete those stored usernames/passwords from the workstation (in most cases, open Control Panel, then User Accounts, and click ‘Manage Network Passwords’ on left). Then, once you have migrated the user accounts, give those accounts permission to access the required resources.
• During the migration, if you are trying to migrate a computer account and you continually receive an error like ERR2:7666 Unable to access server service on the machine ‘computer.domain’.  Make sure netlogon and workstation services are running and you can authenticate yourself to the machine.  hr=0×80070005. Access is denied., and you’ve run the command above on the machine to give Domain Admins from the target domain local admin rights, you may need to remove the computer from the source domain, rejoin it to the source domain to re-establish the trust relationship, and then try the migration again.
• After the migrations are done, make sure to go back to the DNS servers on your target domain and verify that the migrated computers’ PTR records reflect the new domain suffix (eg, changed from ‘workstation1.domainB.’ to ‘workstation1.domainA.’ (and leave the trailing . in, or you’ll have trouble!).

And that’s it! ADMT worked like a charm, and after using it to migrate and merge user accounts, and then migrate the computer accounts, everyone was off DomainB with out the hassle of needing to manually join DomainA and reconfigure the user accounts. By performing both the user account and computer account migrations, once the process was done users just had to login to their computers using ‘DomainAUsername’ instead of ‘DomainBUsername’ and everything was left exactly like it had been, right down to the desktop wallpaper.

And now I’m free to decommission two old servers.

They aren't subtle, either.

As pointed out by @lukec on Twitter earlier today, Microsoft apparently paid to be listed as the top result when you search for ‘firefox’ on Twitter. What an odd coincidence, considering Firefox 4 was just released.

I gave the user full rights to the share, and assigned it Owner status as well (all through the Security tab, as standard), and then configured the GPO as appropriate. After rebooting the client computer, however, I checked the Documents folder only to find that it was still pointing at the default location. A quick peek in to Event Viewer revealed the following error:

Failed to apply policy and redirect folder “Documents” to “\serversharefolder”.

Redirection options=0×80009211.

The following error occurred: “Can not create folder “\serversharefolder”".

Error details: “Access is denied.”.

Which was very strange indeed, as a brief check confirmed that yes, the domain user did in fact have full access to both the folder and the share.

Then, something I saw (and stupidly, ignored) when setting up the GPO came back to me. I fired up the GPO editor and and browsed back to the Documents folder redirection section (User ConfigurationPoliciesWindows SettingsFolder Redirection). After double-clicking the Documents option, and then switching to the Settings tab (shown below), I noticed the top two boxes (“Grant User Exclusive Rights to Documents” and “Move the Contents of Documents to the New Location”) were selected by default. Given that this was an ‘Access Denied’ error, I figured one of these two settings must be at fault, so I unchecked them.

After rebooting the client computer, the Documents folder redirected to the Home Drive as expected.

Here’s where it gets stupid, though. On the ‘Target’ tab in the Documents properties window (visible in the screenshot above), if you have the ‘Target folder location’ set to ‘Redirect to the users home directory’, it explicitly adds a note that says “This settings ignores the value of the ‘Grant User Exclusive Rights to Documents’  option on the settings page.

Apparently not, Microsoft. Apparently not.

TL;DR Version: If Folder Redirections aren’t applying correctly, Event Viewer is showing ‘Access Denied’ messages, and you’re using Home Folders specified in the user account, disable ‘Grant User Exclusive Rights to Documents’  option on the settings page of the GPO.

Being cheap (and considering that the onboard card did just fine), I opted for a Soundblaster X-FI Xtreme Audio PCI-E (SB1040). I didn’t do a lot of research before making the purchase, which I probably should have, because the ‘X-FI’ in the name of the card is an out-right lie. As it turns out, this is the only card in the X-FI line to use a legacy Audigy-series processor instead of an X-FI one.

As such, there’s a rather large issue with driver support. I was able to install the latest driver from Creative’s website (Web Update 2), and the audio-out worked fine, however I couldn’t get my microphone to work. At all.

On the back of the card, there’s a blue port for Line In which doubles as the Mic port (known, apparently, as a FlexiJack or Flexi-Jack). By default, Windows 7 detects it as only a Line In port with no option to change it. There’s supposed to be an option in the Creative Console Launcher, however the driver update from the website doesn’t install that. No matter, there was a separate download for that. Unfortunately, even after installing it there wasn’t an option to change the Line In jack to a Mic jack.

As it turns out, there’s a specific way to get it working that no one blog or forum post out there has managed to nail down. Here’s the trick.

1. Download and install the latest driver from Creative (1.04.0000)
2. Reboot.
3. Download and install the Creative Console Launcher (Beta – 2.61.49).
4. Reboot.
5. Open the Creative Console Launcher (should be in the Start Menu under All Programs -> Creative)
6. Click on the last icon (shown below) called ‘Jacks’.
7. On this screen you should be able to change the ‘FlexiJack’ mode to Microphone (also shown below).

The Two Missing Options

That should be it! If this doesn’t work, there’s one more thing to try. Remove all of the Creative software, then install Windows 7 Service Pack 1 (at the time of writing this, still in Release Candidate form) and try the above again – I already had the SP1 Release Candidate installed when I did this, so it may or may not be required.

Good luck!

Update: I ended up returning this card because it lacks some very basic features that even generic onboard Realtek audio chips have, like Stereo Mix and Microphone Boost support. If you’re thinking of buying this card, think again!