Setup is Unity UM 4.03 with Call Manager 3.33 sr4a.
Application is Viewmail for Outlook 4.03b
At the main site I can have outlook open, select the deskphone next to a pc as the playback device, and be able to play a message through the phone.
At a remote site, when I attempt to set up the phone as a playback device, the initial text box requesting the directory number, unity server, and domain fails. It indicates a permissions issue.
The remote site users are in their own container in the same domain that the unity server is in. I don't see how this should make a difference or where I can fix the permissions issue if there is one.
Voicemail from the phone alone works just fine.
The permissions problem is likely access to the local registry - VMO setup doesn't directly connect back to the Unity server during setup like that - it does, however, write information into the local registry for keeping track of the server name and dial number to send to call the local phone.
Either the local system is locked down harder than usual (we're using the local user's registry keys, not system or the like) or perhaps you're using a thin client (i.e. Citrix) that's giving you fits here?
I don't have any crazy kind of group policy implemented, just a few settings to make sure I can access the computer remotely and that they can't hose the network settings. The user is definitely logging into the domain, and I am not using a thin client....
The remote site locations are using a different anti-virus client than the main site. I will look into that a little further.
I am currently working in a mixed NT4 and win2k environment, all of whom have Unity accounts. There is no problem at all with the users who are logged into machines belonging to the AD domain, however when we are using NT4 workstations (not in the domain) it takes over a minute for Unity to ask for the correct credentials username/password/domain. Is there anyway of spoofing the credentials, rather than sending the username/password/computername, send username/password/domain. If this is not possible, is there anyway we can reduce the time in which it takes for Unity to prompt us for the correct information.
Thanks in advance,
Do you mean the dialog box that asks for the Username, Password and Domain?
Are you logged on to the PC using the NT credentials associated with the subscriber's Unity account?
I enter info into both the initial dialog box for extension, unity server, and domain.
The subsequent dialog box is for username, password, and domain. I have tried entering the username and password for the account, the unityadmin info, the domain admin info. Nothing is accepted
I am logged on as the domain user that has both the exchange account as well as the unity vm box.
One one user I tried making him a local machine admin as well with the domain level username, and that did not work either.
If I understand your problem correctly, you have no problems with the dialog box that asks for the Unity server and Extension. However, the dialog box that asks for user credentials keeps popping up, no matter what credentials you supply - is that correct?
TRaP uses NTLM authentication, so if the Unity server is not able to autheticate the supplied credentials, the dialog box will keep popping up, until you supply valid credentials. Look at the
event log (Security log) on the Unity server and check if the user account you are using is listed. If yes, it should have a rejection reason.
Could you also gather TrapConnector traces (all levels) from the Unity Diagnostic Tool and email them to me?
Sorry for the delay; I am only now getting back to this.
I have installed UnityVMO4.04 on two computers. I now get a new error that is probably related to the old one.
The first time I attempt to play a message it rings the phone, then an error pops up on the screen: "Unknown problems are preventing the completion of the call". Subsequent attempts just get the error message, no ring. I have tried this on two computers and same result.
There are no errors in the unity security log based on this, but there is an application log error:
Event Type: Error
Event Source: CiscoUnity_PHGreeting
Event Category: Error
Event ID: 153
Time: 6:42:22 PM
The Unity mailbox for the recipient with alias - Installer for outside caller messages is not availble. Possible reasons could be that the mailbox was deleted, or is this is a Exchange 2K implementation, the RUS service is not running late or is not scheduled right.Technical details - The smtpaddress field in the gloabal subscriber view for the subscriber is either blank or NULL. 0x80004005
What is the OS/Outlook version?
Here are some possible causes for this error:
1. The user is not logged on to the PC using his/her Unity credentials. If your Unity credentials are unitydomain/myusername you should log on to the PC using unitydomain/myusername, for the telephone playback functionality to work.
2. There is a DCOM issue. The telephone playback functionality uses DCOM. With Unity 4.03 and any version of VMO, Unity makes a DCOM call to the PC to retrieve the stream to play. Some third party security software such as VPN/anti-virus/firewall software block incoming DCOM calls to the PC. Disable third party security software and see if it makes a difference.
3. The PC is not reachable by name/ip from Unity.
Windows XP Pro, Outlook 2003
1. Definitely logged on with domain/username, and set up outlook with the same user account.
2. Norton Antivirus is the only security software....McAfee was on previously, but was uninstalled before I installed ViewMail. I can telnet to the client pc from unity on TCP ports 135 and 445, so the remote PC is at least answering on the DCOM ports.
Is it possible that there is a group policy setting that is preventing remote DCOM calls to the PC?
I did have the Default Domain Policy/Computers/Windows/Security/Local/Access this computer over the network group policy setting limited to domain admins only. I just changed it back to the default setting...maybe that will help.
3. Can ping the pc from unity using only the pc name.
I think 3 might be the culprit here. Unity should be able to reach the PC using the IP address. Here is how this works:
Outlook/VMO hands the IP address of the PC to Unity as the source of the audio stream and then Unity tries to establish a DCOM connection to that IP address to fetch the stream. So, if the IP address is not reachable, we have a problem. Can you configure your network so the IP address of the PC becomes reachable from Unity?
The other option is to upgrade to Unity 4.04. When VMO 4.04 is used with Unity 4.04, Unity fetches the audio stream from Exchange, instead of from Outlook. So, there is no DCOM call made from Unity to the PC. (see bug CSCee03366).
OK...I think 3 is not the culprit. I _am_ able to ping the pc from unity using either the dns name or the ip address.
I see how upgrading to Unity 4.04 would be better. I have now been able to replicate this same problem at another site :(
Thanks - I will go with the upgrade.
I too am having the same issue using the IP Phone as the record mechanism. When you click the red record button, the phone rings. When you answer it, you get the "Unknown..." message mentioned above. I too can ping the PC from Unity. I am using Unity 4.0(3) and VMO 4.0(4).
I don't know if you've still got these problems, but they can usually be fixed with a registry update on the client PC.
You can either navigate the registry and add the DWORD string yourself, or make a registry file to do it for you. Fire up notepad and from the paragraph below copy the lines (including the blank line) between the lines of asterisks to the clipboard, and paste them into notepad:
Windows Registry Editor Version 5.00
Make sure that in your notepad session, the words 'Active' and 'Voice' are separated by a space and not a line break. Click on File, Save as. Navigate to a folder of your choice. In the 'file name' box, put VMO-fix.reg. In the 'save as type' box, choose 'All files' instead of Text Document. Click on save.
Now take that VMO-fix.reg file to the client PC and launch it, it will add the DWORD string to the registry. Reboot the client for the change to take effect.
I would suggest upgrading to VMO 4.05 rather than tweaking the registry. The bug that the above registry update addresses has been fixed in 4.05.