Chicago Network Support

Over the past week I have had numerous people tell me they can no longer launch hyperlinks into Internet Explorer.  If you recently installed an Adobe update and/or removed Google Chrome web browser, you may have this problem if you use Internet Explorer.   Many popular pieces of software such as Adobe Reader bundle Google Chrome in the installation.  While bundled software usually can be unchecked in the installer, this can can go unnoticed.

All of the users experiencing the problem were attempting to launch a hyperlink in Microsoft Outlook.  They would receive an error such as "This operation has been canceled due to restrictions in effect on this computer."   This kind of behavior can be traced to a network firewall security setting, or even resolved by setting program defaults in the control panel.  Neither were an issue or fix.

The problem appears to be related to Google Chrome's uninstaller failing to reassociate .html and .htm registry classes back to Internet Explorer.  There is a simple fix, and hopefully will be addressed by Google.

Open Regedit

Expand HKEY_CLASSES_ROOT.html.  Modify the default value key from ChromeHTML to htmlfile.  Do the same for HKEY_CLASSES_ROOT.htm and change the default value to htmfile.

Close and reopen Outlook and you should be able to launch hyperlinks again.

Is Outlook 2010 saying that search isn't available? Getting frustrated? Well don't be! I have some solutions for you. 

After a Microsoft Exchange Upgrade to 2010 and upgrading the clients all to Outlook 2010 for a client I ran into this issue.After looking around on the internet and reading several blogs and forums, I have come up with a solution to this problem. 

Running Windows 7 and upgrading to Outlook 2010 form 2007/2003 -

From what I can tell it appears that the mssphtb.dll file which is used for the windows Search Email indexer in previous versions of Office either doesn't work or is unnecessary for Outlook 2010. There really is no straight forward answer on this. I am thinking that this is the case because the solution to make the Outlook search work again leaves that .dll add-in disabled. So I assume it's not needed. 

The indexing stopping issue seems to occur after upgrading Office 2007 to 2010, because the windows indexing service gets turned off. This must occur during the upgrade process, but doesn't get turned back on by the script. This is purely an observation as I have no hardened proof of this.

Solution -

1. Make sure the Windows Indexing Service is on.
    
2. Goto Control Panel -> Programs and Features -> Turn Windows Features On or Off
    
3. Check mark the Indexing Service check box and hit OK.
    
4. For good measure restart your machine to make sure this fully takes.
    

After the machine boots back up please allow some time for the Indexing Service to rebuild the indexes before you test. I would safely say 1hr or more. After 15min or so you should start to see some emails returned from searches but they may be older ones first. 

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 is a premier provider of Virtualization solutions and technologies.


Recently SkyByte won an RFP for a major suburban park district near Chicago. SkyByte successfully beat out four other Chicago IT firms with our design and project pricing. The park district had approximately thirty aging physical servers well beyond their effective service life. Their server room consisted of two 42U racks full of old server equipment. SkyByte proposed a four server VMware vSphere Cluster connected to a NetApp 2040 SAN. Cisco switches were chosen and NFS was utilized for the storage area network. SkyByte architected a secure DMZ along with multiple production internal networks. The project had the added benefit of centralizing all of the organizations data within the new NetApp SAN. This further improved the organizations disaster recovery options.

SkyByte installed the new VMware vSphere cluster and virtualized all the old servers from P to V. The virtualization candidates were Microsoft Exchange, four Microsoft SQL database servers, file and print servers, application servers and many F5 load balanced web servers.  Upon completion of the project all old server equipment was removed, and a complete 42U rack was removed from the room. 84U U’s of space were reduced to 15U’s. Power and cooling requirements for the data room were reduced by more then 50%. The park district gained fault tolerance, and high availability; the system is designed to continue business operations with a two host failure. The organization also gained much more flexibility within their system to meet the public's needs. Other benefits have been much better performance logging and reporting. The organization has acknowledged system performance was dramatically improved across all servers.

SkyByte has been working with Virtualization technologies since 2003. Over the last several years we have focused our infrastructure practice on server virtualization and server consolidation through the use of VMware vSphere Clusters and standalone ESX and ESXi hosts. He have aligned ourselves with NetApp and EMC for storage solutions. SkyByte has found VMware’s virtualization product suite to be vastly superior to the competing server Virtualization software such as Hyper-V and Citrix XenServer. Specifically the levels of refinement, flexibility, reliability and support are much better with the VMware products.

Contact us today for a free evaluation of what Virtualization can do for your organization. 847.574.6256 or info@skybyte.com

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.

Recently I had the chance to migrate a Forefront Threat Management Gateway 2010 RC environment over to the TMG 2010 RTM SP1. The RC had been developing some issues and it was time to install with the full produciton release. The server was only needed for reverse proxy for a SharePoint implementation.

Our users access SharePoint sites and our InfoPath form in 1 of 3 different ways:

Via the Intranet: http://sharepoint.mycompany.com
Via the Extranet: http://sharepoint.mycompany.com
Via the TMG 2010 Server: https://sharepoint.mycompany.com

The form is set to domain trust, published from InfoPath as a site content type and associated with a SharePoint document library (browser compatible) at https://sharepoint.mycompany.com

After setting up TMG and verifying that people could access the sites externally and internally I turned to testing the functionality of the site and the forms located within.

When accessing externally I noticed that approving published documents tied to the workflow would generate an InfoPath error stating "The form cannot be submitted to the Web server either because your computer is offline or because the host server is currently unavailable. If this problem persists, contact your network administrator." Internally the forms would work flawlessly, but that was due to TMG only handling the external traffic.

This was perplexing because it worked in the previous RC version of TMG. Now it was time for troubleshooting SharePoint and how the TMG communicated the host headers when accessing the forms.

After some looking and testing I noticed on closing the form users were then redirected to https://sharepoint.intranet (the URL that the form is published to in InfoPath) which of course they could not access. I looked around on the Internet and found some articles on this exact problem but they were relating to ISA Server 2004 and 2006.

I tracked it down via View Source on the InfoPath web form. There's a javascript array variable in there called "g_objCurrentFormData", which contains some URL strings. I guess InfoPath is using these as part of the submit process.

If these domain strings in "g_objCurrentFormData" don't exactly match the domain in which the form is being viewed, **including the https!** then the submit will be blocked (....browser-level prevention of cross-domain shennanigans, I suppose.)

Oddly enough the forward slashes are encoded by InfoPath as u002f.... in case you didn't guess.

In our case, the form was hosted at our SharePoint site https://sharepoint.mydomain.com, but the javascript strings showed "http:u002fu002fmydomain.com", i.e. missing the "s". The Link Translation Rule converted these into "https:u002fu002fmydomain.com", which did the trick.

Running Fiddler before and after the Link Translation Rule was defined showed....
Before:
No Fiddler traffic on submit.
After
A POST to the SharePoint domain on submit!

The Solution:

Create a link translation in your Rule for your published SharePoint site with the InfoPath form.

From: http:u002fu002fsharepoint.mydomain.com
To: https:u002fu002fsharepoint.mydomain.com

Also leaving the

From: http://sharepoint.mydomain.com
To: https://sharepoint.mydomain.com

So you should show both entries in your link translation.

Skybyte Consulting is Chicago's premiere IT consulting firm. We provide local area network design, disaster recovery solutions, Cisco IP Phone Support, Cisco ASA Firewall support, Checkpoint support, VPN installation, (SAN) storage area network support and much more!

SkyByte Consulting believes one of the most helpful features we cant seem to live without in Microsoft Outlook is the autocomplete feature of previous names and addresses you've used when composing or replying to emails. For many people this feature is used far more then their contact list. Prior to the release of Microsoft Outlook 2010, the names and addresses for this feature were stored in a .NK2 file located within the user's profile.  With the release of Outlook 2010, the .NK2 was replaced with an autocomplete cache .DAT file.

Its important to know, when performing an upgrade installation to 2010, the installer automatically converts any existing NK2 files for you.  However, in some situations, such as moving a user to a new computer with Outlook 2010 installed, you can manually convert this using a simple run command.

To do so perform the following:

1.  Verify Microsoft Outlook is closed and not running.
2.  Verify "Show hidden files and folders" is enabled in the Folder Options.
2.  Make a copy of the old .NK2 file from the previous Outlook profile.
For Windows 2000/XP, browse to C: Documents and Settings Username Application Data Microsoft Outlook
For Vista/7, browse to C: Users Username AppData Roaming Microsoft Outlook
3.  With Outlook 2010 installed and configured properly, transfer the .nk2 file to the same location from where you copied on the old machine depending on OS.  You may need to enable hidden files and folders on the new machine.
4.  Verify the .nk2 file is named the same as your Outlook profile.  By default the file is named "Outlook.nk2".
5.  Go to start and click run.
6.  Type in "outlook.exe /importnk2" and click OK.
7.  Compose a new email and verify your autocomplete cache is available.

The NK2 file is renamed to "Outlook.nk2.old" during this process.


For more information see Microsoft KB980542.  http://support.microsoft.com/kb/980542


SkyByte is a security based service and solution provider dedicated to the delivery of secure data communications, risk management, data integrity and corporate privacy. SkyByte offers a wide array of IT consulting services such as the design and maintenance of firewalls, VPNs, LANs, WANs, VMware server virtualization, messaging systems and secure wireless networks.

 

Recently SkyByte saw an issue with a Dell Latitude 13 laptop after installing a new SSD hard drive. The symptoms manifested during and after a Windows 7 pro 32-bit install running BIOS A01. The machine would take hours to install Windows 7 and hours trying to start the OS. After much diagnosis and trail and error we narrowed the problem down to the ATA controller. Ultimately the issue ended up being that ACHI (Advanced Host Controller Interface)  needed to be disabled and conventional ATA mode enabled in the BIOs settings. The laptop returned to lightning speed after we made the change and reinstalled Windows 7.