Blog: Networking

Initially worked with a customer to see if we could reproduce the problem in Worldox with a known "working" file.  We were able to reproduce the problem, so we started work on the user's profile.  I had the customer log off and then disabled the users roaming profile for both the NTprofile and TSprofile.  I renamed the existing user folder in Documents and Settings on Citrix2 so a new profile would get created.  After this I had the customer login to test Worldox with the "clean" profile.  Worldox worked with the clean profile, so we knew something was wrong with the user's settings. 

I looked through the registry settings and profile directory for the working and broken profiles to try to find differences.  I tried several minor file and registry changes to see if we could get Worldox to work under the original user profile.  None of the changes seemed to work.  There wasn't much related info in the registry, so I was sure the problem was file related.  It seemed especially to be something related to the document templates/addins in Word not working properly.  I tried replacing and removing the Word templates in the users Documents and Settings folder, but this didn't seem to change the behavior at all.  The templates were actually still loading, even after I removed them.  [more]

I found (in the working profile) that the addin that had the macro for inserting the DocID was named swInnova.dot.  When I would open Word in the broken profile, that particular addin was the only one of about 8 missing!  This certainly seemed to be the problem, but I couldn't figure out why that addin wasn't loading while all others were.  After some digging I noticed the addins were being loaded from the users home folder on H:\ rather than the Documents and Settings folder.  I tried to update the addins in this folder, but Word still wouldn't load the swInnova.dot addin.  I decided to change the path to the addins back to the standard location in Documents and Settings and when I did this Word loaded the addin properly.  I then tested Worldox and it worked too.  So, it seems there is something in the swInnova.dot addin that is keeping it from being run from a network location (can only be run locally?).

Last month, I was working a maintenance window for a customer that has VMware View 4 installed. During the window, I would install all the updates on the master image, snapshot it, and recompose the pool using the updated image. During the recompose, View would shutdown all the machines needing the update, delete them from the inventory, copy out a new replica disk, recreate all the VMs, attach them to the replica disk, and complete the setup process. This particular recompose could not delete one of the machines. The other machines finished the process normally and were ready to go, but this one machine simply timed out during the recompose process.

During my troubleshooting, I ended up killing the task and trying to delete the machine through the View console. No luck. I could delete the machine from the vSphere client, but then how would I clean it up from inside View? [more]

http://kb.vmware.com/kb/1008658

This article provides the steps to manually remove a linked clone entry from VMWare View. The basic steps include:

1. Remove the VM from the ADAM database
2. Remove the linked clone reference from the View Composer database
3. Delete the machine from vCenter

At that point, you can re-enable provisioning and everything should start working as normal once again.

If your virtual disk is at or close to the maximum size allowed by the file system, you might be unable to take snapshots due to overhead added by the snapshot process.  This failure occurs when the snapshot file at its maximum size would be unable to fit into a datastore. 

The failure depends on the size of the virtual disk. All virtual machines having disks with a maximum supported size by VMFS may experience this error. Overhead for the snapshot is roughly about 2GB for a disk size of 256GB. If snapshots are to be used, consider the overhead while deciding the size of the disks.  Follow the link below to view the maximum file sizes forthe different versions of VMFS.

After upgrading the Adobe Reader to version 10.1.0 for a customer,  some users began to see prompts for accepting the EULA.  This seemed to be pretty random because not all PDF files were causing the behavior.  I did a quick Google search and found the following link: [more]

http://patrickhoban.wordpress.com/2011/07/09/124/

Apparently if you have the letter "CR" (must be in this order, capitalized and together) in the file name it will trigger this behavior.  The link above explains what registry key is missing and how to fix the problem.

I recently travelled to a customer location wehre 80% of the employees use Windows XP Embedded Thin Clients. With the new XenApp 6 farm, it requires the latest version of the Citrix Client 12.0 or higher to be able to use all the functionalities of the new farm.

Now this became tricky as some older models (T20’s) had 512KB of Hard Drive space and 512KB of RAM.  I was happy to see that the the newer versions, T30 and T40, both had 1MG.  Adding to this storage surplus, all the images had Citrix plugins ranging from versions 10 to 11.  We also wanted to help IT support out and install a Bomgar Button to these machines. [more]

After some trail and error we finally found a work around to the installation of the Thin Clients.

1. Changing the environmental variable to run the installation off the USB keys
2. Loading a file that Bomgar created on Local Settings/App Data to the All Programs folder for all users to be able to launch the button
3. Registry fixes to disable Icons and rename the Thin Clients so they pass through the correct machine names.

All these changes, had to be made in the administrator account and all changes required a reboot of the machine for the changes to take place.  All in all, I believe I became a very thin client myself.

This is pretty straight forward, but comes up from time to time.  A customer called to say their screen is smaller (lower resolution) than it used to be after Windows Updates.
 
Notes about Terminal Server resolution:

• You cannot change the resolution while in a terminal server session.
• The Display tab in the RDP options before you connect is usually set to “Full Screen”.  It can be set to lower resolution sizes than your current PC or Thin Client settings, but not higher.

In order to fix the problem, close the terminal server connection.  Change the resolution size as needed on the local PC or Thin Client, and then reconnect to the terminal server.  The new resolution settings will be passed through automatically if the display settings are still set to “Full Screen”.

I recently needed to recover a long forgotten WPA encryption key from a friends Windows XP laptop.  Unfortunately the wireless router password and the ISP credentials were MIA also, so changing the key or resetting the router were not options.  After some searching I found WirelessKeyView from Nirsoft (http://nirsoft.net/utils/wireless_key.html).  This is a simple EXE download that displays the WEP or WPA key for all networks on the laptop.  For Windows XP it can only get the 64 digit hex key because XP doesn't save it in clear text.  However this will work fine when joining the network.  On Windows Vista and Windows 7 it will retrieve the key in ASCII.

I was working on updating servers when I came across SQL Server 2005 SP4 patch failing to install.  I was able to locate the installation logs in the SQL Server folder.  The reason for failure was that it could not add user NT AUTHORITY\SYSTEM to local group that just happened to be a domain group.  I wasn’t sure if this server used to be a domain controller, but it can have an effect on SQL Server installations as indicated by http://support.microsoft.com/kb/925976. [more]

I started combing through the registry under the Microsoft SQL Server path as listed in the above KB article to see if I could spot any of the keys.  Inside of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.3\Setup, I saw registry key SQLGroup with a SID that belonged to the domain group listed in the SQL install log.  The way you tell what the SID is mapped to is using a tool called PsGetSid from sysinternals.

I then decided to look up the SID for the local Administrators group using the PsGetSid utility, and then I changed the SQLGroup key data to the SID of the Builtin\Administrators group.  I restarted the SQL services to make sure they could restart after the change.

This time, the install worked and the log was clean.  I did see that NT Authority\System shows up in the local Administrators group on the server.

I had been working with a customer to move all their file shares to a new server and implement Distributed File System (DFS). All looked to be working as it should, except one user’s My Documents was still pointing to the old file share. It was also taking approximately 7-8 minutes to login. I ran the Group Policy Results wizard against the terminal server she was accessing and her user account. I verified that group policy was applying to her account but it was failing to apply folder redirection. I made sure no other users were having the same issue. [more]

I started reviewing the Group policy events and found the error causing the problem redirecting her userdocs. I opened the path that was shown in the error message and found a Word document named  "A Hot Site is defined as a fully operational offsite data processing facility equipped with both hardware and system software to be used in the event of a disaster or for disaster rec.doc".  I was able to copy the file to another location and remove it from the path. I then attempt to connect as the user, the login process completed quickly and the My Documents redirection was working as should. I renamed the file and placed it back in the users My Documents.