Blog

I’ve been running the Office 2010 beta for a while, although I’ve seen this problem occur on Office 2007 as well. Periodically, I’ll lose my ability to select text with the mouse inside Outlook. It just simply won’t work. Closing and restarting Outlook always fixes the problem, but it’s an annoying problem to have to deal with. After some searching on the internet, a solution from Microsoft popped up. From http://support.microsoft.com/kb/940791 [more]

Problem Description:

You install an automatic update for Microsoft Office Word 2007 on a Windows Vista-based computer and then restart the computer. If Word 2007 was running when the computer was restarted, you experience one or more of the following symptoms:

• The mouse does not work when you use Word.
• You cannot open a Word document from the Search window in Windows Vista.
• You cannot open a Word document from Windows Desktop Search.
• Word crashes when you try to start or exit Word.
• Word crashes when you open the Open dialog box.
• Word crashes when you save a document.
• Word crashes when you close a document.

The fix is simply to open the registry, browse to and delete the following registry subkey: HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\Data

Then close and restart your Word applications (Word, Outlook, etc.). So far, this seems to have fixed my problem, although I’m going to give it another week or two before I call it comfirmed.

At a client site, I have been testing some automated ways to move users from v1 to v2 profiles. All their users are on Windows XP and we are moving them to Windows 7. I was looking specifically for a graceful way to allow interoperability between the profile versions and keep us from having to touch every user profile to copy over data. What I found was a little annoying. There is really only two ways to migrate data from v1 to v2 profiles.

1. Use Folder redirection to share data between the profile versions by redirecting relevant data to a network share that can be used by both profiles.
2. Use the user state migration tool [more]

If you are NOT using roaming profiles, the USMT is the best way. If you are using roaming profiles, the folder redirection is the best way. The gotcha here is to make sure you create the folder redirection policy FIRST on a Windows Vista, 7, or 2008 system BEFORE editing it on a Windows XP or 2003 system. There is something about the way the GPO is created/built that will not allow it to apply to vista, 7 , and 2008 systems if it is created with XP or 2003 first.

I was trying to use Cisco’s Adaptive Security Device Manager (ASDM) to connect to our ASA in the office.  I was getting an authentication error but I knew my credentials were correct and it was working for another engineer.  The Java console contained the error “java.io.IOException: Authentication failure”.  I found several references to proxy issues related to this error, so I went to the Network Settings section of the Java app in the control panel and manually specified our proxy server (including the local bypass addresses) and it started working.  The proxy setting was set to “use browser settings” but obviously this wasn’t working.

Conditions:

1. Machines that used to run ISA Firewall client
2. Uninstallation of ISA Firewall client
3. New PROXY settings configured
4. SEP 11.5 installed.

Many machines began getting errors in the application logs from Event Source: crypt32, Event ID: 8.  The description of the error says “Failed auto update retrieval of third-party root list sequence number from: [more]http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt”.

I eventually stumbled across a few forums that eventually led me towards this issue happening after installing SEP 11.5.  What seemed to be happening is that the machines attempted to update its root certificates from Microsoft Update at two hour intervals.  The machine will attempt to connect using the SYSTEM account, so it is important that this account also has the correct PROXY settings.  It is likely that after removal of ISA Firewall client, the settings for the SYSTEM account were left in the registry pointing to the old PROXY server. 

The SYSTEM account can always be found in the registry at HKEY_USERS\S-1-5-18. I found that on machines that were not working, the registry keys under HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings were pointing to the old PROXY script whereas the working ones were pointing to the correct PROXY wpad.dat configuration file.  I had to pull the settings from a newer system because this registry key is a binary key, so you cannot simply type the value.

Be sure that the machine also has unauthenticated user access allowed through any web filtering appliance to www.download.windowsupdate.com also.  
 
More information can be found at http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/1f626f1854285036802574e4002de4c7?OpenDocument

I created a new tool to add to my arsenal of PGP recovery items. This came up when I really needed to do some file level work on a PC that wouldn’t boot and I couldn’t conduct a repair or get to the files because of the PGP whole disk encryption. I was able to take the Automated Installation Kit for Windows 7 and create a WinPE recovery ISO. From there, I found a PGP document (https://support.pgp.com/?faq=1526) that gave the steps as to how to inject the PGPWDE drivers in order to get authenticated.

Essentially, you can boot to this disk, run the command "pgpwde --disk 0 --auth -p <passphrase>" and from there, you can determine the encryption status, decrypt/encrypt disks, perform file level actions, add/remove passphrase users. One potential use for this, that I did not test, would be to boot to this disk, become authenticated, eject the disk and insert a Windows 7 installation disk, and perform a repair on the OS. The only potential problem I could see with this is if the Win 7 installation wrote over PGP’s MBR, but I’m sure that’s not too difficult to fix. In either case, it could potentially save a few hours of rebuilding time.

I have been having an annoying problem with right mouse clicks and Windows-E keystrokes for some time on my laptop. Finally, I got disgusted enough to spend the time to research and fix. It turns out that these problems are typically related to context handlers that are instantiated when you do the right mouse click on a file/windows background etc. There is a program from NirSoft called ShellExView which will list these programs that are available to the context menus. It allows you to disable a particular shell extension and test to see if that particular shell extension is causing your problem. One of our network engineers also reported that this happened to him when he had a program he removed (the removal process must be defective) and the context menu item was still available but missing.

The Federal Financial Institutions Examination Council (FFIEC) issued an updated Retail Payment Systems Booklet.  The booklet is part of the IT Examination Handbook series and provides guidance to examiners, financial institutions, and technology service providers (TSPs) on identifying and controlling risks associated with retail payment systems and related banking activities.  To download the booklet and associated workprogram, visit http://www.ffiec.gov/ffiecinfobase/html_pages/it_01.html

Public folder permissions can be challenge with Exchange 2007, primarily because Microsoft removed the options from the GUI and replaced them with Powershell commands.  It’s particularly difficult to make mass changes because there’s not a single command to propagate permissions to all subfolders.  However Microsoft does provide Powershell scripts to help with this.  By default they are saved at C:\Program Files\Microsoft\Exchange Server\Scripts.  [more]

More information about these scripts is available at http://technet.microsoft.com/en-us/library/aa997966%28EXCHG.80%29.aspx.

I was working remotely on a customer’s network using a PPTP VPN connection. When my work was completed, I clicked on the network icon in my system tray expecting to find a “disconnect from” option for the connection.  It was not there.  I opened up Network and Sharing Center, but could not find a way to disconnect the session.  Finally, I disabled my network interface card (NIC) and re-enabled it.  That disconnected the session.

I knew I didn’t want to have to disable my NIC every time I used a PPTP VPN connection, so I looked for a solution.  I found an online forum that mentioned that this was a known issue. The workaround for this problem is: [more]

Open up a command prompt window.  At the prompt, type rasdial “connection name” /disconnect and then enter.  That will disconnect the session.  The connection name will need to be in quotations if the name of the connection has spaces in it.  If it does not, then quotations are not needed.  If you need to identify the connection name, you can just type rasdial and then enter.  This will give you a list of all your active connections.

If you utilize the same PPTP connection(s) quite often, you can also create a disconnect shortcut for each connection, which will simplify the process.  Just create a new shortcut and add the listed command string in the location.  Then, when you need to disconnect from the PPTP session, just use the shortcut.