Network Administrators

Recently I ran into a strange problem with hyperlinks not launching Internet Explorer from Outlook 2010.  Upon clicking on any hyperlink in any email, the system would prompt the user asking what program to use to open this file.  My first thought was this was an Outlook issue, since Outlook can prevent certain files and hyperlinks from opening.  However, after checking the default programs on the server, I discovered the HTTP and HTTP protocols had no association to Internet Explorer, and listed "unknown application" to open them.  Additionally I could not even choose an application to re-associate these protocols.

The Citrix Xenapp Installation is a Windows 2008 64 bit OS running Citrix Xenapp 5.  It turned out to be a known bug in Xenapp 5.  The IMAAdvanceSrv.exe service apparently removes a critical registry entry for Internet Explorer.  The registry key entries located here were both missing:

HKEY_LOCAL_MACHINESOFTWAREClassesIE.HTTPshellopencommand

HKEY_LOCAL_MACHINESOFTWAREClassesIE.HTTPSshellopencommand

By default, the command should be: "C:Program Files (x86)Internet Exploreriexplore.exe" -nohome

I replaced the keys and immediately hyperlinks were working again, however, after about an hour the keys I entered mysteriously disappeared.  Thankfully Citrix has identified the issue and has a resolution involving adding a registry entry found here: http://support.citrix.com/article/CTX107424.  After entering this key, the registry entry for Internet Explorer remained intact.

For x86 servers, add the following key below.  For x64 servers, the key belongs under WOW6432Node.

HKEY_LOCAL_MACHINE/Software/Citrix/SFTA

Valuename: DisableServerFTA REG_DWORD value decimal 1

SkyByte Consulting is committed to excellent Citrix Xenapp support!  Contact us today!

After installing Symantec Endpoint Protection to a Citrix Xenapp Installation, I noticed several repetitive errors appearing in the Application event log.  About every minute, a service or application part of Symantec Endpoint would crash.  These crashes were causing Symantec Endpoint to malfunction and update definitions properly.  We also believe this caused a decrease in system performance across our entire farm.  Several executables were failing and would log an error such as this:

Faulting application name: SescLU.exe, version: 11.0.7000.49, time stamp: 0x4db8fae2

Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec49b8f

Exception code: 0xc0000005

Fault offset: 0x0002e8f4

Faulting process id: 0x15e4

Faulting application start time: 0x01ccffa2c6db522a

Faulting application path: C:Program Files (x86)SymantecSymantec Endpoint ProtectionSescLU.exe

Faulting module path: C:WindowsSysWOW64ntdll.dll

We are running Citrix Xenapp 6 on Windows 2008 R2 servers part of a healthy VMware Vsphere cluster.  I installed Symantec Endpoint 11 RU7 from our SEPM server and had applied Symantec's recommendations for terminal environments.  We were very shocked to hear about performance issues with the hardware it resides on.  Considering how Symantec interacts with the system and its files, such errors could very well cause stability issues for users logged in.

This problem was related to the Citrix Application Programming Interface.  Thankfully this can be disabled for any executable or service experiencing a problem.  The procedure can be found on Symantec's website: http://www.symantec.com/business/support/index?page=content&id=TECH150373

Its recommended to add the entry in both locations 32 and 64 bit servers.

For the 32-bit version

Key: HKEY_LOCAL_MACHINESOFTWARECitrixCtxHook

Value Name: ExcludedImageNames
Type: REG_SZ
Value: rtvscan.exe,smc.exe,sesclu.exe,smcgui.exe,ccsvchst.exe
 

For the 64-bit version

Keys: HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCitrixCtxHook and HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCitrixCtxHook64

Value Name: ExcludedImageNames
Type: REG_SZ
Value: rtvscan.exe,smc.exe,sesclu.exe,smcgui.exe,ccsvchst.exe
 

In addition to these applications, I also added symdelta.exe which was occasionally crashing.  After a reboot, Symantec was functioning normally and the system performance had increased.  An antivirus software is essential to network security.  Configuring it properly on a terminal server is very important to ensure efficiency and functionality are in check.

Last week I ran into a bizarre email sending problem which ultimately was caused by Microsoft Outlook 2010.  All of a sudden a user could no longer send email from their Outlook, but could receive.  The user would immediately receive this undeliverable bounce-back after sending any emails:
 

 
"Delivery has failed to these recipients or groups:
user@domain.com

You can't send a message on behalf of this user unless you have permission to do so. Please make sure you're sending on behalf of the correct sender, or request the necessary permission. If the problem continues, please contact your helpdesk."

This error is typically seen when a user attempts to send an email on behalf of another user without the proper permissions.  This was not the case, the user was trying to just send email as himself.  The first obvious check was if his Exchange permissions were set correctly.  The user was running a fairly new box, running Windows 7 Professional 64 bit with Microsoft Office 2010 Home and Business edition.  Their Outlook was connected to an on-premise Exchange 2010 server, and no other users on the network were experiencing this problem.  While we had performed a Microsoft Exchange Upgrade recently, he had been running normally for several months.  The next step I took was see if he could send from OWA, and he could.  Additionally, he could send from his Android phone connected to his Exchange account.

To confirm the problem was isolated to his machine as a possible network security or software issue, he logged in as himself on another similar machine, created an Outlook profile and was able to send email just fine.  So, the next step I took was recreating his Outlook profile.  Recreating the Outlook profile will resolve many Outlook abnormalities, unfortunately this time it did not help.  Then I backed up the user's profile, and recreated it.  To my disbelief, the problem remained.  My next step was to fully remove and reinstall Office, not a repair install.  This finally fixed the issue, and he was able to send email again.

SkyByte Consulting has recommended Symantec Endpoint Protection and its managing capabilities to it's clients for a variety of reasons.  From the ease of deploying clients to end users and the ability to manage them all from one console makes Symantec Endpoint Protection a great Antivirus and Antimalware solution.  The Symantec Endpoint Protection Manager (SEPM) downloads definition updates from Live Update on a regular basis and then deploys the updates to each endpoint client connected to your network infrastructure.  Symantec releases several revisions throughout the day, so by only having to download one copy of the definitions to the SEPM rather than each individual client, you save bandwidth for other needs.

Recently I discovered a SEPM that had stopped receiving updates.  Rebooting the server had not helped and manually running LiveUpdate inside the SEPM would reply with "Error: LiveUpdate encountered one or more errors. Return code = 4".  According to Symantec, this could be a variety of reasons from network firewall security, IE's Enhanced Security, or a proxy.  I knew this was not the case and I was able to resolve this by following these steps:

1.  Stop the SEPM and SEP Embedded Database in Services.
2.  Uninstall Live Update from Programs and Features or Add/Remove programs
3.  Install Live Update from the SEP setup CD
4.  Open a command window, then browse to:
C:\Program Files\Symantec\Symantec Endpoint Protection Manager\bin
Type lucatalog -update and press Enter.
5. Start the SEP Embedded Database service and then the SEPM service
6. Login into the SEPM and retry downloading updates from Live Update.

I recently installed a CAD viewer as a published application in a Citrix Xenapp installation.  The Xenapp environment is running Windows Server 2008 R2 across all servers in the farm.  The goal was to be able to open .DWG files in this application by double clicking on any .DWG file.   Unfortunately this specific CAD viewer application did not associate itself to any file extensions in the system's registry  Instead, double clicking the file opens the window asking you how you would like to open the file, which would have been a problem.

There are a few ways you can associate a file in Windows Server 2008 R2.  You can choose manually select the program to open and select always open this type of file with this program, or you can associate the file type under default programs in the Control Panel.  Since we are using roaming profiles, these user settings are immediately lost upon log off.  Attempting to associate the file under the administrator account will not apply to all users either.

Furthermore, under the Citrix console you can associate files for published applications within the Content Redirection properties in the published application.  This useful feature applies specific file types to always open with the published application.  The only downside to this is Citrix searches the registry of your Xenapp servers to determine what file extensions can be associated.  The resolution is to manually associate the file type using the assoc and ftype commands on the Xenapp server.

We recently created a brand new Citrix Xenapp 6.0 environment with four Windows 2008 R2 servers in our farm.  40 users will be connecting into the environment with a variety of platforms including thin client technology, mobile PCs, and now mobile tablets and phones.  One of the goals in our Citrix Xenapp installation was to support as many platforms as possible.  With Citrix, that is entirely possible with a few tweaks to get things working right.  With mobile devices becoming the preferred computing device, especially tablet PCs, Citrix access has become a frequent request in recent years.

Citrix offers an lightweight application available for iOS, Android, and Blackberry devices called the Citrix Receiver.  This simple app provides you secure access into your companies Xenapp environment.  You can stream published apps and use your desktop on the convenience of a tablet.

During our testing phase, we ran into an issue with iOS 5 devices not accepting our SSL certificate installed on the Secure Gateway server running Windows IIS6.  We experienced the problem on both the iPad1 and iPad2 and also the iPhone 4 and more than likely it affected all iOS devices.  We had reason to believe it was due to our standard SSL certificate authorized through GoDaddy since we had other environments working but with an SSL certificate through another SA.  The problem occured when an iOS device attempted to launch an app or published desktop.  The connection would fail half way and say:

Connection Error:  You have not chosen to trust "Go Daddy Secure Certification Authority", the issuer of the server's security certificate.  Error Number: 183

A few weeks ago I could ran across a bizarre issue where I could not access a Citrix Presentation server using Microsoft Remote Desktop.  The server was acting as if it was offline or RDP was disabled when you attempted to connect using the RDP client.  I confirmed the server was online and responding to ping commands.  I could even gain access to the server remotely through the ICA client.  I checked the obvious things such as making sure RDP was enabled and any network firewall security settings were not blocking access on port 3389.  Furthermore, I opened a command prompt on the server and executed a netstat -a command.  I confirmed the RDP service was in fact listening on port 3389.  I even rebooted the server but the problem remained.

This particular server was a Windows 2003 Server with Citrix Presentation 4.0 installed.  It had been a couple years since virtualization of this server had taken place to a Vmware vpshere cluster and no major changes had been performed in recent time.  The problem ended up being related to a setting in the Terminal Services Configuration.  I opened the properties of the RDP-TCP connection and noticed it was not bound to any networking adapter, while the ICA-TCP connection was.  I chose and applied "All network adapters configured with this protocol" which immediately resolved the issue.  While I don't know how this setting was changed, I was happy it was an easy fix.

With the release of Internet Explorer 9, I have ran into a few users who can no longer launch their Citrix desktop or published apps from a Citrix Metaframe or Xenapp portal.  With the enhanced network security included with IE9, the published apps cannot launch when using an incompatible Citrix Online plugin.  The launch.ica file loads as a downloaded file but fails to launch the desktop or application.

This problem has been addressed by Citrix and has been resolved with a new plugin that supports IE9.   The new plugins can be downloaded from here: http://www.citrix.com/English/ss/downloads/details.asp?downloadId=2313030&productId=186

Once downloaded and installed you can now launch your applications and desktop in IE9.  One thing to note is you must now click on "open" on the downloaded launch.ica file on the bottom of the IE9 window.  From there the application and desktop launches normally.

1. Open the Device Manager. Click Start > Control Panel > Administrative Tools > Computer Management > Device Manager.
2. Expand Network Adapters. Right-click VMware Accelerated AMD PCNet Adapter or Intel Pro/1000MT. Click Properties.
3. Click the Advanced tab.
4. Click NetworkAddress for VMware Accelerated AMD PCNet Adapter or Locally Administered Address for Intel Pro/1000MT.
5. Select Value.
6. Enter the desired MAC address without the colons (:).
7. Restart the virtual machine to ensure that the change takes full effect over the network.

While attempting to configure Outlook Anywhere using RPC over HTTPs in Outlook, I ran across and issue where the Exchange server's hostname would not resolve outside of the office during setup.  When I attempted to configure Outlook Anywhere on the internal office network, it was successful.  Once Outlook Anywhere was configured properly internally, Outlook would connect outside the office.  However, important Outlook features such Calendar and Tasks were either limited or unavailable. 

This client of ours received a Microsoft Exchange Upgrade to Exchange 2007 running Server 2008 R2.  At first I thought it was either a configuration problem on the Exchange server, or a network security problem on their Cisco ASA firewall.  Using this extremely helpful Outlook and Exchange connectivity tool found here: www.testexchangeconnectivity.com, I was able to track down and resolve the issue preventing me from configuring Outlook Anywhere outside the office.

The test results showed the Exchange server could not be reached on port 6004.  After some research on the Microsoft TechNet Exchange library, I discovered the problem was related to connection requests defaulting to using IPv6 in Microsoft Server 2008.  The simple solution is to comment out IPv6 and add the IPv4 address and local hostname in the Exchange server's host file:

127.0.0.1 localhost
#::1 localhost
xxx.xxx.xxx.xxx mailserver
xxx.xxx.xxx.xxx mailserver.domain.local

Once this was saved to the host file, Outlook was able to resolve the hostname outside the office and all functionality of Outlook was restored!

After converting a Microsoft Virtual server image to a VMware virtual server image using a third party tool, I discovered the number of processors in the VMware configuration were not reflected on the guest OS.  The server was displaying one processor in the task manager, but showed four installed processors in the device manager.  Furthermore, the HAL was configured as a "Advanced Configuration and Power Interface ACPI PC" when it should be a "ACPI Multiprocessor PC" under Computer in device manager.  

The problem was the original configuration included one processor core in it's Microsoft Server virtualization environment.  This carried over during the conversion process to the multiprocessor VMware Vsphere cluster.  Since the server was running Server 2003, it is not easy to switch back and forth between uni and multi processor HALs without potential consequences.  It seemed the only solutions were to run a repair install or rebuild the server.  Since this virtual server contained a Citrix Xenapp installation, I did not want to risk a repair install or worse, a complete rebuild.  I then found a script thanks to this website, which successfully converted the HAL to a multiprocessor PC.  You will need the Microsoft command line utility devcon.  Run the following commands:

Reboot the server and verify it displays "ACPI Multiprocessor PC" under Computer in device manager.  You should see all configured processors in task manager as well.  If the server does not boot, you may need to reconfigure the number of processors in VMware to one, reboot, reconfigure processors back again, followed by another reboot.  I cannot stress enough the need to create a backup of the server before attempting this.  This was a very risky procedure that could have easily corrupted the server to the point of no return.  Thanks to the many VMware virtualization benefits, I created a snapshot of the server prior to running these commands, in case I needed something to fall back on.

Most Microsoft Office users are aware of the new file formats since the release of Microsoft Office 2007.  Each file extension now ends in "x", i.e. .docx, .xlsx, .pptx, etc.  Microsoft thankfully released a converter tool to support the compatibility between older and newer Office platforms.  While this is a great tool, it is still recommended to convert all of your Office documents to the newest version to minimize any problems throughout your organization.

After a successful upgrade to Office 2010 from 2003, we recommended our client convert their files to the newest version since they rely heavily on Excel for their operations.  I downloaded the Microsoft Office Migration Planning Manager 2010, found here, which is a set of tools to help administrators during the transitioning phase.  Included with this bundle is the Office File Converter (ofc.exe), a very lightweight, but very useful command line driven batch converter tool.  Note this tool also requires the Office Compatibility Pack to be installed on your machine, even if you have Office 2007 or 2010 installed.  That can be found here.

Once I installed the compatibility pack, I extracted the contents from the Office Migration Planning Manager.  I browsed to the tools folder which contain the ofc.exe and ofc.ini files.  The .ini file is the control file that allows administrators to configure how the conversion will be performed.  You can configure many options such as converting files from one server but outputting the converted files to a new server.  This will save you timee if you are performing server upgrades. The tool automatically converts any previous Office file to the new version, quickly and efficiently.  

Since all I needed to do was one directory of about 900 Excel files, I simply copied the files to my local disk and ran the conversion. 

As an example, I edited the ofc.ini file to look like this:

[Run]
LogDestinationPath=C:2003 Office FilesLogs
TimeOut = 3
 
[ConversionOptions]
; FullUpgradeOnOpen: if set to 1, Word documents will be fully converted to the OpenXML format
;                    if set to 0 (default), Word documents will be saved in the OpenXML format in compatibility mode
FullUpgradeOnOpen=1
 
CABLogs=0
 
MacroControl=0
 
[FoldersToConvert]
fldr=C:2003 Office Files
 
[ConversionInfo]
SourcePathTemplate=***
DestinationPathTemplate=C:2003 Office FilesConverted


Once your .ini file is setup, you simply execute the ofc.exe file from a command prompt and the conversion will start.  If there is a syntax error in the .ini file you will know right away.  With my .ini file, the files to be converted lived in C:2003 Office Files and were to be outputted to C:2003 Office FilesConverted.  The entire process took approximately 5 minutes to convert 900 Excel files that were about 800KB each.

In conclusion, this is a great tool provided by Microsoft.  I highly recommend using it for batch converting Office files to the newest Office format.  SkyByte Consulting can provide you and your company with the support and knowledge that these major but very beneficial Microsoft upgrades require.  Call of email us today!