If you find yourself (or a customer, friend, etc.) in this predicament it may be in your best interest to restore the affected keys. While I make no assertion that this is either Microsoft or industry recommended I’ve fixed more than a few systems with this extremely easy technique. Windows 7 and Vista no longer support the old, Windows XP INF tricks so this is what we’re left with.

Attached you’ll find Registry merge files. These were exported from fresh installations of Windows on VMware Workstation 8. For all you IT underlings it will be in your best interest to backup and then delete the following Registry keys prior to merging in the news ones:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Winsock
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WinSock2

• Microsoft Windows Vista SP2 x64 – Winsock Key
• Microsoft Windows Vista SP2 x64 – Winsock2 Key

LETS GET READY TO RUMBLE...or maybe not

Now by old, I mean _old_. OS 4.2 and older. This is when the policy.bin changeover happened. The issue with all the tools out there is that they’re designed to work with 4.3 and up. These tools work very well at removing the policy on these newer models:

- BBSAK
- CrackUtil
- JL Cmder

But alas the problem is you’ve got a 4.2 (or older) phone. Well shit. Time to upgrade!

Check online to see if there’s a 4.3 update available. Or even a 4.5 update like was the case with the 8703e that I stumbled on. Also in my case we threw a Sprint image onto a Verizon phone. So even crossing carriers might work.

So in short, upgrade however you can and then run the policy kill tools.

Bingo bango boom our friend now has a working (if not battered, ugly and old) 8703e to use while he travels to DC.

For instance earlier today I removed a mapped drive, S: (not that it matters), that was originally connected via WebDAV to a server that is now no longer in use.

So long story short, delete the offending drive, log off and then back in. Try the paste operation again and hopefully you’ll have 1980′s technology restored…

Microsoft: WTF?! This is nonsensical behavior.

Add this GUID to the allowed add-on list in Add-on Management:
{6A6F4B83-45C5-4ca9-BDD9-0D81C12295E4}

This allows the “msrdp.ocx” control to run in Internet Explorer.

Don’t forget to do a “gpupdate” or logoff/reboot the computer after you change the Group Policy.

Sound familiar? If so you might need NoMAS (No Master Account SID, I presume), a tool from Microsoft Product Support Services (PSS) that enumerates through Active Directory and finds disabled users that have no msExchMasterAccountSid attribute set.

Wait…what the hell is msExchMasterAccountSid? Good question. The attribute msExchMasterAccountSid more or less tells Exchange/Outlook how to handle permissions on an account. By default a disabled user account has a blank msExchMasterAccountSid, so delegating the account to someone else fails miserably (usually with Outlook hanging for way longer than it should).

What the tool NoMAS does is goes through and find all those (usually disabled) accounts with a blank msExchMasterAccountSid attribute. This is helpful as a top down view of what needs fixing. Once you find accounts with this empty attribute the fix is simply to set the Associated External Account to Allow on the SELF “user” (this all of course under the Exchange Advanced | Mailbox Rights in the Active Directory Users and Computers snap-in).

You can download NoMAS at:
http://archive.msdn.microsoft.com/NoMas

Like all Windows service packs, Internet Explorer installs and other “large” updates I strongly recommend downloading the full install packages instead of using what comes down the pipe in Windows Update. Full packages generally do a more thorough job, at the expense of taking longer to install.

Windows 7 SP1 Full:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c3202ce6-4056-4059-8a1b-3a9b77cdfdda

nslookup -type=AAAA -server=ns1.t-mobile.com ipv6.t-mobile.com

Windows:

nslookup -type=AAAA ipv6.t-mobile.com ns1.t-mobile.com

You can easily leave out the “server” option of either command to use your OS’s configured DNS server(s). In this case we specified T-Mobile’s “ns1.t-mobile.com” name server.

1. In the Services MMC snap-in try restarting the “Symantec Embedded Database” service. Be patient, as it may take some time (to fail).
2. If the service fails to restart forcefully kill the “dbsrv9.exe” process (through Task Manager or similar).
3. Stop/start the service. The service will be in an undefined state, so again be patient. It might take a minute for the service to show the “Start” action.
4. Open Symantec EndPoint Protection Manager and attempt to log in. Hopefully the issue is fixed.