Do you need a network expert?

Cisco IP phone system call handler forwarding calls incorrectly

Monday, January 10, 2011 by Greg Bock
SkyByte Consulting offers Cisco IP phone support and system architecture for many of it's clients.  Just last week I resolved an unusual call forwarding problem with one of the users.  Several months ago we had configured a new call handler in a Cisco Unified IP phone system of a client.  A call handler is a standard pre-recorded greeting with programmed prompts for the caller to choose from.   The call handler was configured to forward to an extension when inputed by the caller with the option to speak to the operator and was operating correctly when the call handler was programmed. 

In this case, when the caller dialed this specific extension, somehow the call was being forwarded to the user's personal cell phone.  This was only occurring through the call handler, and not when dialed from any other internal extension which was strange.  After gathering more information from the user, he stated he had setup his IP phone to forward to his cell phone during a business trip and it had been forwarding ever since even with the phone set to not forward.  I confirmed this by checking the user's IP phone to make sure it was not set to forward.  All of the system's IP phones have the ability to forward calls to voice mail, another extension, or phone number.  This confirmed the system has the setting either cached or configured to forward the calls.

The next step I needed to do was check the settings in both Cisco telephony servers connected to the client's network infrastructure.  This system consists of a CallManager server and Unity Voicemail server.  CallManager contains settings for devices and phones, as well as the settings for call handlers.  Unity controls mainly voicemail and other greeting settings.  The resolution to set his phone to ring his desk phone was performed through the Unity Server.

Solution:

1. Log into the Cisco Unity configuration web page.
2. Search for the subscriber either by name or extension
3. Click on call transfer
4. Replace the phone number with the extension number and change the option to "Yes, ring subscriber's extension".
5. Verify it forwards the call correctly.

Problems with Infopath forms in Sharepoint deployment using host headers & TMG 2010

Thursday, December 9, 2010 by Mario McGuire

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!