Bug ID #CSCdw59188 causes 404 error in IE when click linking to subscriber

[bjiminez]

We are currently introducing 2 Unity 3.15 servers in a University to replace our existing Octel VM. Each Unity server is configured as a Windows 2000 Domain Controller with Exchange 2000 loaded on each box. Each box is independent of the other in different AD domains and networks, one is for faculty and one for students. Both Unity boxes have the same hostname, unity1, but they are in different domain namespaces, meaning unity1.staff.university.edu and unity1student.university.edu .

Everything work fine accept when it comes to managing the boxes from remote workstations. After you search for a subscriber in the SA, and click on that subscribers name to bring up the subscriber configuration, the URL used to bring up the subscriber config does not contain the FQDN of Unity machine, it only contains the hostname. So we get a 404 error, if I manually replace the host name with the FQDN of the proper Unity box in the linked IE windows , everything works fine.

The bug ID CSCdw59188 recommended to append the DNS search suffix in the TCP/IP stack, but this will not work for us. Both Unity boxes have the same host name, unity1, so it will grab the Unity box in the first namespace it searches. Basically we need the URL for the subscriber config to link to the FQDN or IP address, not the host name. Editing a hosts file, or adding a DNS search suffic will not work for us in this case.

I have read up on the forum and have found previous articles related to this, I have tried changing the Global Location field to the FQDN instead on the host name, then rebooted the server with the same results. Any help you can provide would be appreciated.

Thanks in advance,

Bill JIminez

[Ginger Dillon]

Hello -

Could a local HOSTS file on the remote workstations with the IP addresses of the two Unity servers and their unique FQDNs work as a circumvention here? Another different thought I had was to use Terminal Services from the remote workstation and run the SA from the Unity server.

Best wishes! Ginger

[JeffG1]

It really amazes me how Cisco has decided to address this problem...

Rather then fixing their code and use the FQDN everywhere they tell you to add a host entry to the local machine, or supply a DNS search suffix.

The only place I seem to have this issue is when I search for a subscriber, then click on their name. It is also VERY annoying that the web page opens a NEW browser window for this person instead of populating the browser frame that appears with the first subscriber. To me this seems like it would be a simple fix. When I search anything else in the SA web page I get results in the same browser window…

Now Here is what I have found

In File SaMoveInc.asp located in CommServer\Web\Common\include

There is this line :

highTop.open("http://" + strHomeServer + "/Web/Sa/FrameASP/SubsFrame.asp?" + strExtra);

I removed the strHomeServer Parameter and replaced this with my IP address and it fixed the issue…

I believe this would break any clusters, also who known what else it could break.

So if we are calling in SaMoveInc.asp for a whole bunch of things, why does finding a call handler which users the same code work, but finding a subscriber does not?

If I am not using clusters does any one from cisco know what this would break by placing the ip in there?

[oliviers]

Cicso does plan on resolving the issue in the code. There's some internal notes on the case that mention that. For now the way the issue is being addressed is considered a workaround, not a solution.

From reading through the notes, it doesn't sound exactly like a slam dunk solution. That's probably due to the manner in which viewing subscribers was originally architected. I believe at one time there was the idea of being able to view any subscriber from any server in a networked Unity configuration. The guts behind that mechanism are fairly involved and may complicate the solution for this problem.

As far as editing the file, I can't say what problems it will cause in your situation if any. If it is helping to get around the issue, power that.

[bjiminez]

Thanks for all of your quick responses, its somewhat reassuring to see that I am not the only one in this boat...

In regards to Gingers response, unfortunately putting the FQDN's of both Unity boxes in the host file will not resolve the issue, because the subscriber link from the SAWeb links to the host name of the server not the FQDN. Also, we have been getting by thus far using terminal services and running the Admin pages locally on the Unity box. But we do have a farely large telcom staff, and there are some that I would like to be able to create and delete subscribers through SAWeb, but not have terminal service rights to the box. Thats where I am hitting my roadblock.

Jeff,

Thanks for the reply, I did make the change to the samoveinc.asp file, and changed strHomeServer to the IP address of the Unity box. Once I did this, I could not link to the subscribers page in Saweb, the page would start throwing run time errors from the server console. From remote machines, nothing would happen when I click the search button in the subscriber page. The pop up windows would never even come up.. Can you double check and make sure you did not change it anywhere else as well? For the meantime I changed it back to the previous entry.

Also, any permanent resolve from the guys at Cisco would be a big help...

Thanks,

Bill Jiminez