Hi all,
I´m trying to set up a cloud connector edition in my environment to link
the office 365 with my CUCM via sip trunk, but during install the CCE i get
the error.
Create-BaseVM : The configuration of the operating system has taken longer
than usual. Please check the virtual
machine network co
This is exactly the reason I did my upgrades off line and swapped out the
hardware during the maintenance window.
That being said, it still took some time to do all the swapping. Just looking
at my notes from the last upgrade and it was about 2-3 hours. Much of that was
due to the amount of t
I'm going to start with, we don't have a complex deployment.
2 CM
1 UC
1 UCCX
1 CER
1 call recording server
~2000 phones over ~8 sites
our last upgrade we tried PCD (joke) spent 4 hours on it before just doing
it manually. Will be very hard pressed to every use PCD again.
Then it was an additio
I’ve not done CUCM project work in quite a while, so may be completely off, but
what about making this scenario supportable:
Complex cluster say, 1 Pub, 6 Sub, 2 TFTP
Install new software to inactive partition on all nodes, once complete reboot
part of the cluster:
1 Pub - new version
3 Sub -
You are right Anthony, this is a complex solution to avoid the reboot (and
rolling the dice that nothing breaks in the first boot of the new version) in a
switch-version however; if that is your goal as you state.
-R
From: avhollo...@gmail.com on behalf
Unless you only had a single CUCM node (which BE6KS limits you to, and BE6K
customers are a fit for). In which case, a truly seeamless way to "flip"
it would work in all scenarios.
On Thu, Oct 27, 2016 at 3:14 PM, Justin Steinberg
wrote:
> The upgrades take too long is part of it. Especially i
The upgrades take too long is part of it. Especially if the upgrade is an
RU upgrade, because it means that both the patch install/upgrade and the
switch needs to take place in a maintenance mode.
The missing piece in my opinion is a way to put CUCM into a maintenance
mode where it continues to s
Change freezes aside (which are manageable), if we were able to upgrade the
system onto the secondary partition, switch during a maintenance window, and
switch back if there were any issues, that would be great.
But too often, we see the upgrade requiring new underlying OS upgrades which
are
We've had a request come in to see if we could make our UCCx agents mobile and
by mobile I'd say farther than any wireless headset could help with.
>From what I understand, there's really no solution for this. Any solution
>using a cell phone (extend/connect) would still require desktop agent
Honest question, what exactly is it about the current implementation that fails
to deliver on this?
Is it something in the design of the upgrade process?
Is it that the upgrade takes too long to be done during any reasonable
maintenance window?
Is it that you have to test the new version befor
If only there was an upgrade process wherein you install the new version to
an inactive partition, and then could switch to the new version when you're
ready. /sarcasm
But seriously though, everyone in this thread is essentially coming up with
their own clever way of replicating the promise Cisco
11 matches
Mail list logo