My helpdesk tried to do a name change in EM today and got a DANI error during validation. According to the top solution on the Avaya web site, there is a Sig Server patch to fix the issue, cs1000-bcc-7.50.17.16-77. I can't find this patch on the Avaya ESPL site. Do I have to open a ticket with my provider (and have them open one with Avaya) to get this patch? Or give me guidance to do an ESPL patch search to get this. Running an ISSP still gives me the bad version of the file.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
EM CS1000 7.5 DANI validation error patch
- Thread starter curtismo
- Start date
The latest bcc patch I see out on the ESPL is cs1000-bcc-7.50.17.16-75. So if 77 is the fix that probably means it is a VO patch and you will need your Vendor to request it. It's probably best to update the complete Service Pack while your in there.
intelligentium
Vendor
yes you may have to open a ticket with Avaya i guess.
Or if you have an Avaya SSO login ID, may be you can try chatting with someone on their Live Agents on Chat, look at their support websites right top corner.
Or if you have an Avaya SSO login ID, may be you can try chatting with someone on their Live Agents on Chat, look at their support websites right top corner.
- Thread starter
- #5
![[shadessad]](/data/assets/smilies/shadessad.gif "[shadessad] [shadessad]")
- Thread starter
- #7
Tried the Live Chat for the first time. Was able to get to a product specialist who was able to download the needed cs1000-bcc-7.50.17.16-77.i386.000.ntl file to my desktop. I patched the EM Sig Server, retrieved/reconciled the database and issue fixed.
- Thread starter
- #9
Through the command line pload and pins commands to install this file (38 meg). I have used both the EM Patch Manager and CLI; currently I just do all of my patching through the CLI (pload/pins/spload/spins). Just seems like I have more control over the process and can watch for prolems during the patching, like one issue I noticed during this patching round where emWeb wasn't getting upgraded due to "corruption" (per the Avaya Solution - I call it a s/w bug) so was able to fix. Easier for me to push out the current 1.2Gb Linux SU with WinSCP to the 20 remote sites I have, most with just a T-1.
Yep, I agree, through the CLI is the way to go. You can actually see what is going on. However I have been cautioned that in 7.5 the SP must be done through Patch Manager. Can you either confirm or deny this? Some say you must do it through the Patch manager and others have said the CLI method is fine. I have an ATAC group I have to work with so I typically do what they say. However you can get bad information even from them. 2 guys and 2 different answers, you know what I mean.
- Thread starter
- #11
Can't say yay or nay on using the CLI to install the SP; I've done both 6.0 and 7.5 patching the way I was shown by our provider's technicians. I haven't had any issues before, other than what is documented in SOLN153611, Install failure of SP, emWeb patch. And even though a different solution # says "Due to installation of emWeb patch without patching manager emWeb-RPM corrupted," it's ironic that the problem is fixed by changing what appears as a typo in a configuration file from "emWeb_6_0" to "emWeb_6-0"; that sounds more like a bug to me.
intelligentium
Vendor
It is a general recommendation to patch through the Patching Manager.
But i do it through the CLI everytime. There was an issue with CLI as curtismo said.
Not sure if you can view the below
But i do it through the CLI everytime. There was an issue with CLI as curtismo said.
Not sure if you can view the below
Interesting to see the different recommendations. I was told on 7.5 to do the 3 base patches through CLI and the SP had to be done through Patch Manager or it would break it. Sounds like I have gotten some bad info from our support group.
not bad info, just different info.
I was told by GNTS back when I did my first install, to load the SP instead of the 3 patches because there are actually 11 patches that will get loaded in a base Signaling Server. I had them online and they loaded the SP after the initial Linux OS load, then loaded the Applications, then loaded the SP again. It went from 11 installed patches, to 28-31 installed patches (depending on applications loaded). I have never had an issue doing it this way and actually have a cool 19 SMG environment running pretty clean, aside from some QOS issues on the network.
I asked about the 3 initial patches and GNTS said, you could do it that way to, but they prefer the other way, but they always load CLI and not through the GUI.
What to do..what to do.. because if have sites where techs have loaded the 3 patches first and they have no issues either.
I was told by GNTS back when I did my first install, to load the SP instead of the 3 patches because there are actually 11 patches that will get loaded in a base Signaling Server. I had them online and they loaded the SP after the initial Linux OS load, then loaded the Applications, then loaded the SP again. It went from 11 installed patches, to 28-31 installed patches (depending on applications loaded). I have never had an issue doing it this way and actually have a cool 19 SMG environment running pretty clean, aside from some QOS issues on the network.
I asked about the 3 initial patches and GNTS said, you could do it that way to, but they prefer the other way, but they always load CLI and not through the GUI.
What to do..what to do.. because if have sites where techs have loaded the 3 patches first and they have no issues either.
It says right on the ESPL website to load the 3 base patches prior to the Service Pack. I always load the 3 base patches through the CLI, Deploy it and then do the SP through Patch Manager. Never had any trouble doing it this way. But I do prefer the CLI method so I can actually see what is going on.
- Thread starter
- #18
My assumption on the reason to load the three single patches first because these fix some prerequesite issues prior to installing the consolidated service pack, even though these are included in the SP. For example, there appears to be a space issue on the /VAR partition and installing the SP. After loading this set of three patches space free space appears to dramatically increase. I am guessing at some point Avaya will say that you just need to confirm that these are the minimum patch levels required for these modules prior to SP install.
- Status
Similar threads
- Question