Blog: Networking

I recently ran into some problems where the Adobe Reader process (Acrord32.exe) was using the maximum available CPU resources constantly. Even after Adobe reader program is closed, the process remains running in the background continuing to use all of the available CPU resources. Through research I found that the issue has been reported on Windows XP, Windows 7, Windows 2003 (TS and Citrix), Windows 2008 R2 (TS and Citrix). The issue only seemrf to occur when version 10.1.3 was installed as a new installation and not upgraded from a previous version (according to some people’s notes).

The Adobe Reader default install allows "Adobe to display in-product marketing messages while you work in the program". When you launch Reader. the "open recent documents" window that shows during launch includes ReaderMessages along the bottom of the window or may be displayed as you view PDFs. These message are downloaded from Adobe and probably stored in the ReaderMessages file stored within each user’s APPDATA portion of the profile. I'm guessing there is corrupt content in one of Adobe recent messages causing Reader to stay in memory or use high CPU once the application is closed. [more]

To stop the issue, disable the Messages from Adobe by modifying the following settings.

1. Select Edit - Preferences – General
2. Uncheck “Show me messages when I launch Reader”
3. Check “Don’t show messages while viewing a document”
4. Close Reader (and manually kill process if necessary) and reopen 

Note that the following settings are ‘per user’ and must be set by each individual user. To address the issue on a global level, consider doing the following:

• Modify the Reader 10 customization transform file to include the necessary registry keys to disable the settings (would require a reinstall of the application)
• Modify the Default user profile to include the necessary registry keys to disable the settings (would only affect new users logging into the server, current users profiles would have to be removed for the settings to take place)
• Import the registry values using group policy or a login script; if using windows 2008 R2 servers, group policy preferences will import the registry settings very easily

Here are the registry key values that need to be set:

• HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\10.0\IPM]
  • DWORD "bShowMsgAtLaunch" to 0
  • DWORD "bDontShowMsgWhenViewingDoc" to 1

I had needed to make a change to a customer’s WPAD file to add a direct access  location. I made my changes and tested it only to find out that it didn’t work. I decided that I would check and make sure the client could access the WPAD file, so I tested access to HTTP:// SERVERNAME/ WPAD.dat. I was able to see the changes I had saved in the file.  However, the client still didn’t seem to be following the rules. I tried changing the  Automatic Settings in Internet Explorer Proxy settings to use HTTP:// SERVERNAME/ WPAD.dat specifically as the proxy script to use.  As long as I had the Automatic Settings unchecked and the path to the WPAD file defined in the script box, it worked. However, I needed to make sure it would work with Automatic Settings instead. [more]

What I found out was that a client gets it’s instructions about the location of the WPAD file to use through DHCP option 252. Upon checking the settings of this option, I found that it was using HTTP://WPAD/WPAD.dat instead of SERVERNAME. The DNS entry for WPAD was an alias that pointed to SERVERNAME. I went back to the web browser and went to HTTP://WPAD/WPAD.dat.  I discovered that it did not have the changes that I had made even though HTTP://SERVERNAME/WPAD.dat was correct.  On the WPAD server, I restarted IIS and checked it again.  This time, both WPAD.dat files had my changes and the Automatic Settings began working successfully.

It appeared to me what happened was that IIS was serving a cached version of the WPAD.dat file when browsers tried to connect to the DNS alias while the actual server name was not cached. 

You should avoid using the same LUN on more than one VMware vCenter environments. If this rule is not followed, deleting a datastore from one vCenter will cause it to appear as "dead" on the other vCenter when using the following command: esxcli storage core device list [more]

If a rescan HBA's is performed at this point, all management tools may become unresponsive.  To avoid this, the LUN needs to be marked as disabled, rescanned, then removed from the disabled list:

1.   esxcli storage core device set -steate=off -d <NAA ID> (whatever the worldwide name is for that LUN)
2. rescan HBA's 
3. esxcli storage core device detached remove -d <NAA ID>

If everything is already unresponsive, "localcli" may be substituted for "esxcli."

I had upgraded a terminal server from Office XP to 2010 recently and users were getting pop up warnings about autodiscover.domain.com and remote.domain.com names not matching the certificate.  Exchange happened to be setup with both external and internal autodiscover URLs pointing to an external domain address. 

In order to resolve this issue completely, I had to change the internal URLs used by autodiscover in four places.  The URLs need to be configured using the Exchange Power Shell.  The commands I list basically get the value first, and then set the value.  [more]

This article helped me find most of the commands: http://www.msexchange.org/articles_tutorials/exchange-server-2007/management-administration/configuring-exchange-server-2007-web-services-urls.html

Get-AutoDiscoverVirtualDirectory | fl
Set-AutoDiscoverVirtualDirectory -internalUrl “https://internalname/Autodiscover/Autodiscover.xml” -identity “<IDENTITY>”  

Get-ClientAccessServer | fl
Set-ClientAccessServer -Identity "<IDENTITY>” -AutodiscoverServiceInternalURI "https://internalname/Autodiscover/Autodiscover.xml"  

Up to this point, this fixed the SCP URL and allowed the Autodiscover E-mail test to return data.

I had to change the following internal URLs on these services also:

Get-WebServicesVirtualDirectory | fl
Set-WebServicesVirtualDirectory -Identity "<IDENTITY>" -InternalUrl "https://internalname/EWS/Exchange.asmx"

Get-UMVirtualDirectory | fl
Set-UMVirtualDirectory -Identity "<IDENTITY>" -InternalUrl "https://internalname/UnifiedMessaging/Service.asmx"

I was setting up a new volume on our MSA2324fc for an Alpha system to access. The Alpha has been running on an existing volume on the MSA for about a year. I got to the point where the Alpha could see the new volume from the console, but the OpenVMS operating system could not see it.  I verified everything was set up identically on the new volume, except I noticed that the "Volume Description" field was blank on the new volume. It was set to "9" which was the logical unit number on the old volume.  [more]

I could find no way to change this in the web based UI, so I tried connecting to the MSA with telnet. The show volume command listed the volume description, but I noticed a command "set volume <NAME> ovms-uid <ID>." I tried setting that to 4, the LUN of the new volume, and that showed up in the volume description field. Then the OpenVMS operating system could see the new volume.

 I never  thought the contents of a description field woudl have mattered, but it did in the case.

I was assigned recently to a task that had been started by another network engineer. The initial problem started when software updates were applied to the server. The network adapter lost its driver and wasn’t able to talk to the network, let alone the world. He was able to restore network connectivity by reinstalling that driver and resolving other network issues that had arisen, but was unable to fix an issue where network drives were not mapping to the server in the time he had available to him.

When I took a look at it the next morning, all signs led to the network card going bad and needing to be replaced. However, as I was continuing to troubleshoot, I noticed that they had the Network Threat Protection module for Symantec Endpoint Protection (v. 11.0.4) installed. I created a rule on the firewall to open all traffic between sources on the 10.0.0.0/8 network and immediately people were able to map network drives and start working.

I had trouble in renaming a mapped drive. Windows Explorer allowed me to right click on the drive and select rename. However, I discovered while I could delete letters from the name, I couldn’t enter any letters. So, I was left with an accidental abbreviation for the drive name.

I decided I would remove the misnamed drive and redo the mapping. I was surprised to see when I re-mapped the drive and typed in my preferred drive name, it reverted back to the accidental abbreviation.

I searched for a solution and learned about registry entries for Windows Explorer called MountPoints2. I found the accidental abbreviation in the “LabelFromReg” key. Editing the key to the correct name fixed my problem. As an aside, my research also indicated using this registry key will solve some issues which had existed in XP regarding the length of the mapped drive names.

When working with a Jack Henry application that required the use of a ‘localhost’ reference, it was discovered that the loopback (127.0.0.1) address in the HOSTS file seems to be commented out by default in newer OS’s (Windows 2008 R2, Windows 7).  The solution in this case was to just uncomment the entry in the HOSTS file.

MS TECH RESPONSE: At some point in the future, as the world transitions from IPV4 to IPV6, IPV4 will be eventually be disabled/uninstalled by companies that want to simplify network management in their environments.
With Windows Vista, when IPv4 was uninstalled and IPv6 was enabled, a DNS query for an A (IPv4) address resulted in the IPv4 loopback (which came from the hosts file). This of course caused problems when IPv4 was not installed. The fix was to move the always present IPv4 and IPv6 loopback entries from the host into the DNS resolver, where they could be independently disabled."

The Polycom CX600 phones currently deployed in the office are all running a special OS of the Lync Phone Edition. As will all Microsoft Products, updates are periodically released to the software to enable new functionality or fix buggy or security issues. The Lync server provides an easy way to deploy the updates out to all systems, but usually you would want to deploy it to a test device first to make sure that everything will install and function as intended. Lync also provides the ability to create a test device that can be used for updates.

1. Open the Lync Server Control Panel
2. Clients -> Test Device
3. New Test Device
4. Enter some descriptive name for the device and then type the phone’s MAC address or Serial number in the "Unique identifier" field.
5. Wait.
6. A lot.

Any updates that you have installed (regardless of the approval status) will now be automatically installed on your test device. Once you’ve determined the test device functions as intended, you can approve the updates for everyone. According to many sources, the update check-in happens within a minute or two after the phone goes idle and installation within 10 minutes after that. From our (impatient) testing, however, this didn’t appear to be the case. Granted, your mileage may vary and we may just be very impatient people.