03-06-2012 05:46 PM - edited 03-17-2019 10:53 PM
VCS expressway is showing this warning message:
Alarm: Directory service failure
Description: the directory service database is not running
Action: Restart the system.
I have restarted the device many times but the error continue, and i can´t connect movi client from the internet to the VCS expressway, whne i tried i have received the error message: connection rejected by server.
any advice to fix this issue?.
Note: VCS Control is working fine with provisioning and movi.
03-06-2012 11:37 PM
Hi Nelson,
First recommendation to upgrade the software to same version or to a latest version. And see if that fix the issue.
If that also doesn't fix it, then we have manually purge the provisioning and start opends service.
However since you mention that this error is on expressway so i want to know why you are doing provisioning on expressway. Its always recommended to use only one provisioning server in the network which is normally VCS-Control.
And you configure expressway to proxy all the registration to control.
Thanks
Alok
03-07-2012 12:12 PM
Hi Alok. my VCS-E has la last firmware version X7.0.3.
I have olny configure provisionning in the VCS-C, however the issue is when i try connect movi user in the VCS-E i can´t login and i have received this message: coonect rejected by server.
also I see "The directory service database is not running" alarm in the VCS-E.
03-07-2012 01:25 AM
Nelson,
can you confirm that only the VCS-C is doing provisioning, e.g is TMS only doing replication with the VCS-C, or have you set up replication with the VCS-E as well?
Does your VCS-E have a 'Device provisioning' option key installed?
If your VCS-E is NOT doing provisioning, you will most likely be able to get rid of this problem if you
a) Remove the Device Provisioning option key from the VCS-E (if it exists)
b) SSH to the VCS-E, log in as root and execute the command
tmsagent_destroy_and_purge_data
and follow/read the on-screen instructions and warnings carefully.
Once you have performed the steps above, reboot the VCS-E and re-test.
Regards
Andreas
03-07-2012 12:19 PM
Hi Andreas,
yes, I only have configured TMS only with VCS-C and it is working fine.
Does your VCS-E have a 'Device provisioning' option key installed?
yes, it has
i have one question?:
Why do i need to remove "Device Provisioning option key" from the VCS-E. can it affect any function or feature?
03-07-2012 01:57 PM
The device provisioning key is used for "device provisioning" (movi/ex/...) and also delivers the
phonebook to these provisioned devices.
But it can only be used if its properly configured which it is not in your case on the VCS-E.
As you have configured it anyhow only to the VCS-C sounds that the VCS-C is properly working.
As your exact deployment is unknown, if you ask a tech guy "can something happen" he will
most likely say "yes, sure there is always something which can happen" :-)
I would define having a system in a inconsistent state and a deployment which is not proper
are issues with a higher probaility to cause bigger problems.
Who set it up? If he can not clearly answer the question why it shall run there, it needs to be removed.
The standard deployment is having it running on one place and this would be the VCS-C.
If you want to know more, please look at the "TMS_Provisioning_Deployment_Guide"
Quote:
Provisioning should only be enabled on Cisco VCS Control units. If Movi is registered to a VCS Expressway, provisioning requests will be automatically forwarded to the Cisco VCS Control associated with the Expressway via the appropriate traversal zone.
Note: If provisioning is enabled on a VCS Expressway or any other VCS that does not need to have provisioning enabled, be sure to disable it by using the process specified in Removing provisioning from a VCS.
Hope that answers your question.
Task for you: Please use the stars underneath the postings to rate the postings!
Please remember to rate helpful responses and identify
03-08-2012 12:02 AM
Nelson,
only the VCS/VCS's which are doing TMS Agent Replication with your TMS should have the Device Provisioning key installed. (Device Provisioning is also required if FindMe is to be used in a cluster of VCS's.)
The reason for this is that installing the Device Provisioning key on a VCS causes two SIP routes to be created on the VCS. These SIP routes are used to intercept provisioning requests and phonebook requests (In the form of SIP SUBSCRIBE and SIP INFO, respectively) from provisioning clients such as Movi and E20.
In your scenario, where your VCS-C is doing TMS Agent Replication with TMS, your VCS-E should proxy these provisioning requests to the VCS-C rather than intercept them itself, and if your VCS-E has the Device Provisioning option installed, it is likely to intercept these requests rather than proxying them to the VCS-C, which will cause problems.
The alarm you referred to in your initial post is related to the provisioning database (OpenDS directory service) on the VCS-E not starting properly, while in your case there shouldn't even be a need for that database to be running since your VCS-C is doing all of the provisioning work.
I would therefore recommend that you remove the Device Provisioning option key from your VCS-E and reboot afterwards, as that should clear that alarm up for you.
You can also manually check if a VCS has these provisioning SIP routes installed or not by connecting to the VCS via SSH, logging in as 'admin' and executing the command
xconf sip routes
On a VCS which has SIP routes installed, the output will look something like
xconf sip routes
*c xConfiguration SIP Routes Route 1 Method: "SUBSCRIBE"
*c xConfiguration SIP Routes Route 1 Request Line Pattern: ".*@(%localdomains%|%ip%)"
*c xConfiguration SIP Routes Route 1 Header Name: "Event"
*c xConfiguration SIP Routes Route 1 Header Pattern: "(ua-profile|phonebook).*"
*c xConfiguration SIP Routes Route 1 Authenticated: Off
*c xConfiguration SIP Routes Route 1 Address: "127.0.0.1"
*c xConfiguration SIP Routes Route 1 Port: 22400
*c xConfiguration SIP Routes Route 1 Transport: TCP
*c xConfiguration SIP Routes Route 1 Tag: "Provisioning"
*c xConfiguration SIP Routes Route 2 Method: "INFO"
*c xConfiguration SIP Routes Route 2 Request Line Pattern: ".*@(%localdomains%|%ip%)"
*c xConfiguration SIP Routes Route 2 Header Name: "Content-Type"
*c xConfiguration SIP Routes Route 2 Header Pattern: "application/tandberg-phonebook\+xml"
*c xConfiguration SIP Routes Route 2 Authenticated: Off
*c xConfiguration SIP Routes Route 2 Address: "127.0.0.1"
*c xConfiguration SIP Routes Route 2 Port: 22400
*c xConfiguration SIP Routes Route 2 Transport: TCP
*c xConfiguration SIP Routes Route 2 Tag: "Phonebook"
OK
while on a VCS which does not have SIP routes, the same command will give an empty result such as
xconf sip routes
OK
As far as I am aware, all VCS-C devices which are shipping these days have the Device Provisioning option key pre-installed, while I'm unsure if this is also the case with VCS-E devices.
Regards
Andreas
03-13-2012 07:34 PM
I Andreas,
I have followed the steps tha you send me:
a) Remove the Device Provisioning option key from the VCS-E (if it exists)
b) SSH to the VCS-E, log in as root and execute the command
tmsagent_destroy_and_purge_data
after that I reboot the VCS-E and the Alarm: Directory service failure, it not showing and I can connect movi client from the internet to the VCS expressway.
Thank you for your advice.
I have one question: what are the configurations for Default Zone, DefaulSubZone, And traverzar Zone in both VCS-C and VCS-E for Authentication Policy (Do Not Check Creds, Treat as Authenticated, etc)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide