Blog

A customer called with a  laptop that would not connect to any mapped drives.   Investigating found that attempting to map via name would not work but mapping via IP did work.  DNS was working properly and the file server would ping by name or IP.  Logged in with an administrator account and all mapped drives came up properly.   Finally discovered that this machine had not been on the domain for some months and there were old cached credentials for the file server in stored credentials.  These are stored by path so it was using those credentials by default when attempting to map by name but not when mapping by IP.  Removal of these stored credentials allowed the mapping to complete properly. 

Read Articles without Clutter:  There is a new “Reader” button on Safari, under IOS 5 (ipads, iphones), that allows you to read the web page textual data without the surrounding clutter (advertisements).  This button is located in the url window as shown below.  There is similar functionality for other browsers supplied by Readability:  http://www.readability.com/. [more]

When opening an attachment directly from within Outlook you could get an error message saying that it can’t create the file and to that you need check the permissions on the folder you want to save it in. In most cases the permissions on the folder isn’t the issue but the fact that the folder is “full”. When you open an attachment directly from within Outlook it will first save a copy to a subfolder of the Temporary Internet Files folder. Cleaning out the folder will solve the issue.

How to Empty Outlook Secure Temp folder

The subfolder name Outlook creates (on installation of Outlook) in the Temporary Internet Files folder is quite random. In Outlook 2003 and previous, the name starts with OLK and is followed by up to 4 random numbers or letters. In Outlook 2007 and Outlook 2010, this folder is called Content.Outlook and then has a subfolder which is named with 8 random numbers and letters. Getting to the Temporary Outlook Folder can still be accomplished in 2 easy steps though. [more]

Step 1: Locate the folder
The folder location is stored in the registry in the following key;
• Outlook 97
HKEY_CURRENT_USER\Software\Microsoft\Office\8.0\Outlook\Security
• Outlook 98
HKEY_CURRENT_USER\Software\Microsoft\Office\8.5\Outlook\Security
• Outlook 2000
HKEY_CURRENT_USER\Software\Microsoft\Office\9.0\Outlook\Security
• Outlook 2002/XP
HKEY_CURRENT_USER\Software\Microsoft\Office\10.0\Outlook\Security
• Outlook 2003
HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Security
• Outlook 2007
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Security
• Outlook 2010
HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Security

Step 2: Get to the folder and delete content
1. Open the OutlookSecureTempFolder registry key from the location provided in Step 1.
2. Copy the path from the key.
3. Open Explorer.
4. Paste the address in the Address Bar and press Enter.
5. Delete the content of the Outlook Secure Temp Folder.

I have been working on update the Xerox DocuShare client to a new version for one of our customers. They were previously using DocuShare version 5 and it was installed via GPO. They wanted to upgrade to version 6.5.1 and wanted it to be pushed out to their terminal servers using Microsoft System Center Configuration Manager (SCCM).

I removed the software from the server by removing the software package from the GPO with which it was installed. I started testing the install by doing a manual install of the new version. Xerox also provided an administrative installation option to create a custom MSI package. The following command is used to create the custom install package: msiexec.exe /a <path>\DSClient.msi. I noticed that there was no option to customize the directory to which the program installs, so I called Xerox. Xerox also said there was no command line switch for this. The old version was installed at D:\Program Files and the new version was forced to be installed at C:\Program Files. After installing the product using my custom MSI, each time I would restart the server I would get the messages below twice. If I clicked no on these pop-ups, the program would run correctly, but each user would get the prompts at each logon. [more]

I had a case open with Xerox for several weeks and they tried numerous data collections and custom MSI configurations to try and find the problem. I got to thinking about the problem one day and found there was a simple solution. I started searching the registry to see if any remnants of the old GPO installation were found. I found that there were several registry keys related to Xerox that were pointing to D:\Program Files\Xerox, but my new install needed to be on the C drive. These keys were left behind by the GPO uninstall. Xerox does not have a registry cleaner like several other vendors have. What was happening was that the program was trying to reconfigure itself each time it started because it could not find the files to start the DocuShare client. The registry key that ended up being the key to this was HKEY_USERS\.DEFAULT\Software\Xerox\DocuShare Client. After I deleted that key, the install worked perfectly.

The moral of this story is to check to make sure that nothing is left behind from an uninstall, especially if you are changing the directory to which the program files are installed.

Office 2010 applications have a Quick Access Toolbar at the top left of each window (default location).  You can right click on this and choose "Customize Quick Access Toolbar" to add additional buttons.  There are some items that are not in the ribbon at all.  One example of this is the Message Options in Outlook.  It is not in the ribbon on the main Outlook window.  Adding this to your Quick Access Toolbar in your Outlook main window will allow you to look at the Internet headers and other information without opening the message.  You can also customize the ribbon, adding new tabs and anything you want, but that is a little more complicated.

The other day I had an issue come up with a customer where VSS (Versative Storage Server) integrated file system backups stopped working for some unknown reason. Usually, a reboot fixes these types of issues, but backups continued to fail after a reboot. I started a support call with the backup vendor and after seeing the error logs, the support tech seemed fairly sure he knew what the problem was. This error is usually caused by a malformed path within the registry. So he had me run the following commands on the server and send him the output. [more]

vssadmin list writers >> c:\writers.txt
vssadmin list providers >> c:\providers.txt
vssadmin list volumes >> c:\volumes.txt

diskshadow /L c:\shadow.txt
list writers detailed

After reviewing the text files created, he found the malformed path:

- File List: Path = c:/windows\hpsum_1327455089, Filespec = hpsumserverw32.exe

To correct the issue, I searched the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\ for “c:/windows\hpsum_1327455089” and corrected the path to “c:\windows\hpsum_1327455089” . After doing this, the backup ran fine. Further research uncovered the root cause. During the last maintenance window, HP System Update Manager was used to update the HP System Management Homepage on these servers. This malformed registry key was created by HPSUM during the upgrade.

I found out last week how easily one can get a certificate from GoDaddy with a SAN (Subject Alternative Name) for a non-registered domains name. This would include domains that end in .dom or .local that do not have a public registrar. Since GoDaddy cannot retrieve a WHOIS record for the domain, their authorization email only needs to be approved by the account that requests the certificate. This vulnerability removes a significant barrier for a man-in-the-middle attack, since the certificate would be trusted and the name would match the URL requested by the users.

Additionally, Office 365 AD Sync (needed for password synchronization) will not work with these type of non-registerable DNS names in a UPN suffix. While the UPN suffix can be changed to be different than the domain name, the problem would not exist for domains that use names like “internal.registereddomain.com”.

We were receiving the following error on one of our customers Netapp SANS:
Autosupport (WEEKLY_LOG) cannot connect to url support.netapp.com/asupprod/post/1.0/postAsup through proxy (Could not find hostname '""', hostname lookup resolution error: Unknown host)

So I tried to check the auto support proxy configuration setting:
netapp> options autosupport.support.proxy
autosupport.support.proxy    ""

After many attempts to remove “” from the proxy server configuration, I finally broke down and contacted support.  The technician also tried a number of things to change the configuration and ultimately found the solution after he asked one of his colleagues.  The way to get rid of the "" is a little counter-intuitive.  You simply apply the following command: [more]
netapp> options autosupport.support.proxy ""
which yields you the following result:
                autosupport.support.proxy

Fight fire with fire, I suppose.

Also, NetApp has a pretty cool tool that shows you the progress of you SnapMirror syncs. (SAN to SAN replication)

NetApp SnapMirror Progress monitor:
http://now.netapp.com/NOW/download/tools/smpm/

I was troubleshooting a printing issue recently for a remote user. She connects to the network over AnyConnect VPN and then RDPs to a terminal server. Her local printers needed to be mapped through to the server so that she could print during the day. The problem was that the printers would show up, but it wouldn’t print. After considerable troubleshooting (including removing and re-adding printers and drivers) I stumbled upon a breakthrough. On the terminal server, the file ntprint.inf in C:\Windows\System32 was missing. Replacing this file from another server 2008 R2 machine allowed her to print successfully.