[cisco-voip] Skype for business Cloud Connector installation problem

[Claiton Campos]

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 configuration.
No C:\Program
Files\WindowsPowerShell\Modules\CloudConnector\Initialize-CcHost.ps1:71
caractere:5
+ Create-BaseVM -INI $ini -VHDPath $vhdFilePath -UnattendISOPath
$unattendISOP ...
+

+ CategoryInfo  : NotSpecified: (:) [Write-Error],
WriteErrorException
+ FullyQualifiedErrorId :
Microsoft.PowerShell.Commands.WriteErrorException,Create-BaseVM

someone already installed CCE once and found an error like this?

Regards,
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Not supported I'm sure..... but what do you think?

[Lelio Fulgenzi]

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 time the servers take to shutdown and restart.


---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph

519-824-4120 Ext 56354
le...@uoguelph.ca
www.uoguelph.ca/ccs
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1



From: cisco-voip  on behalf of Scott Voll 

Sent: Thursday, October 27, 2016 4:50 PM
To: Stephen Welsh; Ryan Ratliff
Cc: cisco voip
Subject: Re: [cisco-voip] Not supported I'm sure. but what do you think?

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 additional 12-16 hours to upgrade.  This was just a 8 to 10 
upgrade.

We don't have that kind of time.  and personally, I like my personal time a 
lot.  so the more I can do during the week leading up to the switch and as 
small as I can make the switch, is what I'm looking for.

Scott


On Thu, Oct 27, 2016 at 1:35 PM, Stephen Welsh 
> wrote:
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 - new version (primary subs)
1 TFTP - new version (primary TFTP)
3 Sub - old version (secondary subs)
1 TFTP - old version (secondary TFTP)

Phone registers to upgraded primary subs, once everything 
working/stable/tested, flip remaining (secondary nodes)

Maybe too complex for this split version to be workable, or not really much 
different than flipping all nodes, but may allow the phones to stay online with 
minimal disruption as long as all external elements strictly follow the 
primary/secondary node configuration.

Thanks

Stephen Welsh
CTO
UnifiedFX


On 27 Oct 2016, at 21:23, Ryan Huff 
> wrote:


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 of Anthony 
Holloway 
>
Sent: Thursday, October 27, 2016 12:02 PM
To: Ryan Huff
Cc: Matthew Loraditch; Tommy Schlotterer; Scott Voll; 
cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Not supported I'm sure. but what do you think?

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 failed to deliver on, 
which is performing your upgrades during production on the inactive partition 
and then switching versions in a maintenance window.  If they would have only 
held themselves to a higher standard, we wouldn't need this complex of an 
alternate solution.

On Tue, Oct 25, 2016 at 2:45 PM, Ryan Huff 
> wrote:
Matthew is correct, copying is listed as "Supported with Caveats" at: 
http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements; The 
caveat being found at 
http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements#Copy_Virtual_Machine

The VM needs to be powered down first and the resulting VM will have a 
different MAC address (unless it was originally manually specified); so you'll 
need to rehost the PLM if it is co-res to any VM that you copy.

Where I have seen folks get into trouble with this is where a subscriber is 
copied, and the user mistakenly thinks that by changing the IP and hostname it 
becomes unique and can be added to the cluster as a new subscriber. I have also 
seen users make a copy of a publisher and change the network details of the 
copy, thinking it makes a unique cluster and then wonders why things like ILS 
wont work between the two clusters (and it isn't just because the cluster IDs 
are the same).

Having said all of that, I would NEVER 

Re: [cisco-voip] Not supported I'm sure..... but what do you think?

[Scott Voll]

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 additional 12-16 hours to upgrade.  This was just a 8 to 10
upgrade.

We don't have that kind of time.  and personally, I like my personal time a
lot.  so the more I can do during the week leading up to the switch and as
small as I can make the switch, is what I'm looking for.

Scott


On Thu, Oct 27, 2016 at 1:35 PM, Stephen Welsh 
wrote:

> 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 - new version (primary subs)
> 1 TFTP - new version (primary TFTP)
> 3 Sub - old version (secondary subs)
> 1 TFTP - old version (secondary TFTP)
>
> Phone registers to upgraded primary subs, once everything
> working/stable/tested, flip remaining (secondary nodes)
>
> Maybe too complex for this split version to be workable, or not really
> much different than flipping all nodes, but may allow the phones to stay
> online with minimal disruption as long as all external elements strictly
> follow the primary/secondary node configuration.
>
> Thanks
>
> Stephen Welsh
> CTO
> UnifiedFX
>
>
> On 27 Oct 2016, at 21:23, Ryan Huff  wrote:
>
>
> 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 of Anthony
> Holloway 
> *Sent:* Thursday, October 27, 2016 12:02 PM
> *To:* Ryan Huff
> *Cc:* Matthew Loraditch; Tommy Schlotterer; Scott Voll;
> cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] Not supported I'm sure. but what do you
> think?
>
> 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 failed to
> deliver on, which is performing your upgrades during production on the
> inactive partition and then switching versions in a maintenance window.  If
> they would have only held themselves to a higher standard, we wouldn't need
> this complex of an alternate solution.
>
> On Tue, Oct 25, 2016 at 2:45 PM, Ryan Huff  wrote:
>
>> Matthew is correct, copying is listed as "Supported with Caveats" at:
>> http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements;
>> The caveat being found at http://docwiki.cisco.com/wi
>> ki/Unified_Communications_VMware_Requirements#Copy_Virtual_Machine
>>
>> The VM needs to be powered down first and the resulting VM will have a
>> different MAC address (unless it was originally manually specified); so
>> you'll need to rehost the PLM if it is co-res to any VM that you copy.
>>
>> Where I have seen folks get into trouble with this is where a subscriber
>> is copied, and the user mistakenly thinks that by changing the IP and
>> hostname it becomes unique and can be added to the cluster as a new
>> subscriber. I have also seen users make a copy of a publisher and change
>> the network details of the copy, thinking it makes a unique cluster and
>> then wonders why things like ILS wont work between the two clusters (and it
>> isn't just because the cluster IDs are the same).
>>
>> Having said all of that, I would NEVER do this in production ... maybe
>> that is just me being cautious or old school, but that is just me. Even
>> without changing network details on the copy, I have seen this cause issues
>> with Affinity. At the very least, if you travel this path I would make sure
>> that the copy runs on the same host and even in the same datastore.
>>
>> === An alternative path ===
>>
>> Admittedly, this path is longer and there is a little more work involve
>> but is the safer path, IMO and is what I would trust for a production
>> scenario.
>>
>> 1.) Create a private port group on the host. If the cluster is on
>> multiple hosts, span the port group through a connecting network to the
>> other hosts but DO NOT create an SVI anywhere in the the topology for that
>> DOT1Q tag (remembering to add a DOT1Q tag on any networking devices between
>> the two hosts and allowing on any trunks between the two hosts).
>>
>> 2.) Upload Cisco's CSR1000V to the host. If you're not familiar with the
>> product it is at the 

Re: [cisco-voip] Not supported I'm sure..... but what do you think?

[Stephen Welsh]

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 - new version (primary subs)
1 TFTP - new version (primary TFTP)
3 Sub - old version (secondary subs)
1 TFTP - old version (secondary TFTP)

Phone registers to upgraded primary subs, once everything 
working/stable/tested, flip remaining (secondary nodes)

Maybe too complex for this split version to be workable, or not really much 
different than flipping all nodes, but may allow the phones to stay online with 
minimal disruption as long as all external elements strictly follow the 
primary/secondary node configuration.

Thanks

Stephen Welsh
CTO
UnifiedFX


On 27 Oct 2016, at 21:23, Ryan Huff 
> wrote:


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 of Anthony 
Holloway 
>
Sent: Thursday, October 27, 2016 12:02 PM
To: Ryan Huff
Cc: Matthew Loraditch; Tommy Schlotterer; Scott Voll; 
cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Not supported I'm sure. but what do you think?

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 failed to deliver on, 
which is performing your upgrades during production on the inactive partition 
and then switching versions in a maintenance window.  If they would have only 
held themselves to a higher standard, we wouldn't need this complex of an 
alternate solution.

On Tue, Oct 25, 2016 at 2:45 PM, Ryan Huff 
> wrote:
Matthew is correct, copying is listed as "Supported with Caveats" at: 
http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements; The 
caveat being found at 
http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements#Copy_Virtual_Machine

The VM needs to be powered down first and the resulting VM will have a 
different MAC address (unless it was originally manually specified); so you'll 
need to rehost the PLM if it is co-res to any VM that you copy.

Where I have seen folks get into trouble with this is where a subscriber is 
copied, and the user mistakenly thinks that by changing the IP and hostname it 
becomes unique and can be added to the cluster as a new subscriber. I have also 
seen users make a copy of a publisher and change the network details of the 
copy, thinking it makes a unique cluster and then wonders why things like ILS 
wont work between the two clusters (and it isn't just because the cluster IDs 
are the same).

Having said all of that, I would NEVER do this in production ... maybe that is 
just me being cautious or old school, but that is just me. Even without 
changing network details on the copy, I have seen this cause issues with 
Affinity. At the very least, if you travel this path I would make sure that the 
copy runs on the same host and even in the same datastore.

=== An alternative path ===

Admittedly, this path is longer and there is a little more work involve but is 
the safer path, IMO and is what I would trust for a production scenario.

1.) Create a private port group on the host. If the cluster is on multiple 
hosts, span the port group through a connecting network to the other hosts but 
DO NOT create an SVI anywhere in the the topology for that DOT1Q tag 
(remembering to add a DOT1Q tag on any networking devices between the two hosts 
and allowing on any trunks between the two hosts).

2.) Upload Cisco's CSR1000V to the host. If you're not familiar with the 
product it is at the core and unlicensed, a virtual router with three 
interfaces by default. Out of the box, it is more than enough to replicate 
DNS/NTP on your private network which is all you'll need. Assign the private 
port group to the network adapters and configure DNS and NTP (master 2) on this 
virtual router.

3.) Build out a replica of your production UC cluster on the private network.

4.) Take a DRS of the production UC apps and then put your SFTP server on the 
private network and do a DRS restore to the private UC apps.

5.) Upgrade the private UC apps and switch your port group labels on the 
production/private UC apps during a maintenance window.

Re: [cisco-voip] Not supported I'm sure..... but what do you think?

[Ryan Huff]

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 of Anthony Holloway 

Sent: Thursday, October 27, 2016 12:02 PM
To: Ryan Huff
Cc: Matthew Loraditch; Tommy Schlotterer; Scott Voll; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Not supported I'm sure. but what do you think?

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 failed to deliver on, 
which is performing your upgrades during production on the inactive partition 
and then switching versions in a maintenance window.  If they would have only 
held themselves to a higher standard, we wouldn't need this complex of an 
alternate solution.

On Tue, Oct 25, 2016 at 2:45 PM, Ryan Huff 
> wrote:

Matthew is correct, copying is listed as "Supported with Caveats" at: 
http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements; The 
caveat being found at 
http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements#Copy_Virtual_Machine


The VM needs to be powered down first and the resulting VM will have a 
different MAC address (unless it was originally manually specified); so you'll 
need to rehost the PLM if it is co-res to any VM that you copy.


Where I have seen folks get into trouble with this is where a subscriber is 
copied, and the user mistakenly thinks that by changing the IP and hostname it 
becomes unique and can be added to the cluster as a new subscriber. I have also 
seen users make a copy of a publisher and change the network details of the 
copy, thinking it makes a unique cluster and then wonders why things like ILS 
wont work between the two clusters (and it isn't just because the cluster IDs 
are the same).


Having said all of that, I would NEVER do this in production ... maybe that is 
just me being cautious or old school, but that is just me. Even without 
changing network details on the copy, I have seen this cause issues with 
Affinity. At the very least, if you travel this path I would make sure that the 
copy runs on the same host and even in the same datastore.


=== An alternative path ===


Admittedly, this path is longer and there is a little more work involve but is 
the safer path, IMO and is what I would trust for a production scenario.


1.) Create a private port group on the host. If the cluster is on multiple 
hosts, span the port group through a connecting network to the other hosts but 
DO NOT create an SVI anywhere in the the topology for that DOT1Q tag 
(remembering to add a DOT1Q tag on any networking devices between the two hosts 
and allowing on any trunks between the two hosts).


2.) Upload Cisco's CSR1000V to the host. If you're not familiar with the 
product it is at the core and unlicensed, a virtual router with three 
interfaces by default. Out of the box, it is more than enough to replicate 
DNS/NTP on your private network which is all you'll need. Assign the private 
port group to the network adapters and configure DNS and NTP (master 2) on this 
virtual router.


3.) Build out a replica of your production UC cluster on the private network.


4.) Take a DRS of the production UC apps and then put your SFTP server on the 
private network and do a DRS restore to the private UC apps.


5.) Upgrade the private UC apps and switch your port group labels on the 
production/private UC apps during a maintenance window.


Thanks,


Ryan





From: cisco-voip 
> 
on behalf of Matthew Loraditch 
>
Sent: Tuesday, October 25, 2016 3:01 PM
To: Tommy Schlotterer; Scott Voll; 
cisco-voip@puck.nether.net

Subject: Re: [cisco-voip] Not supported I'm sure. but what do you think?


I can't see any reason it wouldn't be supported honestly. Offline Cloning is 
allowed for migration/backup purposes. I actually did the NAT thing to do my 
BE5k to 6K conversions. Kept both systems online.



The only thing I can think to be thought of is ITLs, does an upgrade do 
anything that you'd have to reset phones to go back to the old servers if there 
are issues? I don't think so, but not certain.



Matthew G. Loraditch - CCNP-Voice, CCNA-R, CCDA
Network Engineer
Direct Voice: 443.541.1518


Facebook | 

Re: [cisco-voip] Not supported I'm sure..... but what do you think?

[Anthony Holloway]

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 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 service active calls (on ccm, cti, ipvms
> processes, etc) but forces new calls/registrations to another cucm.
>
> Unity Connection does have a nice implementation of this (i.e. 'stop
> taking calls') which makes for completely transparent reboots, etc.
>
> If CUCM had a maintenance mode like feature, we would be able to do these
> things during the day without causing problems.
>
> Justin
>
> On Thu, Oct 27, 2016 at 1:22 PM, Ryan Ratliff (rratliff) <
> rratl...@cisco.com> wrote:
>
>> 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 before you roll it into
>> production?
>>
>> Is it >
>>
>> -Ryan
>>
>> On Oct 27, 2016, at 12:02 PM, Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>> 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 failed to
>> deliver on, which is performing your upgrades during production on the
>> inactive partition and then switching versions in a maintenance window.  If
>> they would have only held themselves to a higher standard, we wouldn't need
>> this complex of an alternate solution.
>>
>> On Tue, Oct 25, 2016 at 2:45 PM, Ryan Huff  wrote:
>>
>>> Matthew is correct, copying is listed as "Supported with Caveats" at:
>>> http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements;
>>> The caveat being found at http://docwiki.cisco.com/wi
>>> ki/Unified_Communications_VMware_Requirements#Copy_Virtual_Machine
>>>
>>>
>>> The VM needs to be powered down first and the resulting VM will have a
>>> different MAC address (unless it was originally manually specified); so
>>> you'll need to rehost the PLM if it is co-res to any VM that you copy.
>>>
>>>
>>> Where I have seen folks get into trouble with this is where a subscriber
>>> is copied, and the user mistakenly thinks that by changing the IP and
>>> hostname it becomes unique and can be added to the cluster as a new
>>> subscriber. I have also seen users make a copy of a publisher and change
>>> the network details of the copy, thinking it makes a unique cluster and
>>> then wonders why things like ILS wont work between the two clusters (and it
>>> isn't just because the cluster IDs are the same).
>>>
>>>
>>> Having said all of that, I would NEVER do this in production ... maybe
>>> that is just me being cautious or old school, but that is just me. Even
>>> without changing network details on the copy, I have seen this cause issues
>>> with Affinity. At the very least, if you travel this path I would make sure
>>> that the copy runs on the same host and even in the same datastore.
>>>
>>>
>>> === An alternative path ===
>>>
>>>
>>> Admittedly, this path is longer and there is a little more work involve
>>> but is the safer path, IMO and is what I would trust for a production
>>> scenario.
>>>
>>>
>>> 1.) Create a private port group on the host. If the cluster is on
>>> multiple hosts, span the port group through a connecting network to the
>>> other hosts but DO NOT create an SVI anywhere in the the topology for that
>>> DOT1Q tag (remembering to add a DOT1Q tag on any networking devices between
>>> the two hosts and allowing on any trunks between the two hosts).
>>>
>>>
>>> 2.) Upload Cisco's CSR1000V to the host. If you're not familiar with the
>>> product it is at the core and unlicensed, a virtual router with three
>>> interfaces by default. Out of the box, it is more than enough to replicate
>>> DNS/NTP on your private network which is all you'll need. Assign the
>>> private port group to the network adapters and configure DNS and NTP
>>> (master 2) on this virtual router.
>>>
>>>
>>> 3.) Build out a replica of your production UC cluster on the private
>>> network.
>>>
>>>
>>> 4.) Take a DRS of the production UC apps and then put your SFTP server
>>> on the private network and do a DRS restore to the private UC apps.
>>>
>>>
>>> 5.) Upgrade the private UC apps and switch your port group labels on 

Re: [cisco-voip] Not supported I'm sure..... but what do you think?

[Justin Steinberg]

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 service active calls (on ccm, cti, ipvms
processes, etc) but forces new calls/registrations to another cucm.

Unity Connection does have a nice implementation of this (i.e. 'stop taking
calls') which makes for completely transparent reboots, etc.

If CUCM had a maintenance mode like feature, we would be able to do these
things during the day without causing problems.

Justin

On Thu, Oct 27, 2016 at 1:22 PM, Ryan Ratliff (rratliff)  wrote:

> 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 before you roll it into
> production?
>
> Is it >
>
> -Ryan
>
> On Oct 27, 2016, at 12:02 PM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> 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 failed to
> deliver on, which is performing your upgrades during production on the
> inactive partition and then switching versions in a maintenance window.  If
> they would have only held themselves to a higher standard, we wouldn't need
> this complex of an alternate solution.
>
> On Tue, Oct 25, 2016 at 2:45 PM, Ryan Huff  wrote:
>
>> Matthew is correct, copying is listed as "Supported with Caveats" at:
>> http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements;
>> The caveat being found at http://docwiki.cisco.com/wi
>> ki/Unified_Communications_VMware_Requirements#Copy_Virtual_Machine
>>
>>
>> The VM needs to be powered down first and the resulting VM will have a
>> different MAC address (unless it was originally manually specified); so
>> you'll need to rehost the PLM if it is co-res to any VM that you copy.
>>
>>
>> Where I have seen folks get into trouble with this is where a subscriber
>> is copied, and the user mistakenly thinks that by changing the IP and
>> hostname it becomes unique and can be added to the cluster as a new
>> subscriber. I have also seen users make a copy of a publisher and change
>> the network details of the copy, thinking it makes a unique cluster and
>> then wonders why things like ILS wont work between the two clusters (and it
>> isn't just because the cluster IDs are the same).
>>
>>
>> Having said all of that, I would NEVER do this in production ... maybe
>> that is just me being cautious or old school, but that is just me. Even
>> without changing network details on the copy, I have seen this cause issues
>> with Affinity. At the very least, if you travel this path I would make sure
>> that the copy runs on the same host and even in the same datastore.
>>
>>
>> === An alternative path ===
>>
>>
>> Admittedly, this path is longer and there is a little more work involve
>> but is the safer path, IMO and is what I would trust for a production
>> scenario.
>>
>>
>> 1.) Create a private port group on the host. If the cluster is on
>> multiple hosts, span the port group through a connecting network to the
>> other hosts but DO NOT create an SVI anywhere in the the topology for that
>> DOT1Q tag (remembering to add a DOT1Q tag on any networking devices between
>> the two hosts and allowing on any trunks between the two hosts).
>>
>>
>> 2.) Upload Cisco's CSR1000V to the host. If you're not familiar with the
>> product it is at the core and unlicensed, a virtual router with three
>> interfaces by default. Out of the box, it is more than enough to replicate
>> DNS/NTP on your private network which is all you'll need. Assign the
>> private port group to the network adapters and configure DNS and NTP
>> (master 2) on this virtual router.
>>
>>
>> 3.) Build out a replica of your production UC cluster on the private
>> network.
>>
>>
>> 4.) Take a DRS of the production UC apps and then put your SFTP server on
>> the private network and do a DRS restore to the private UC apps.
>>
>>
>> 5.) Upgrade the private UC apps and switch your port group labels on the
>> production/private UC apps during a maintenance window.
>>
>>
>> Thanks,
>>
>>
>> Ryan
>>
>>
>>
>>
>> --
>> *From:* cisco-voip  on behalf of
>> Matthew Loraditch 
>> *Sent:* Tuesday, October 25, 2016 3:01 PM
>> *To:* Tommy Schlotterer; Scott Voll; cisco-voip@puck.nether.net
>>
>> 

Re: [cisco-voip] Not supported I'm sure..... but what do you think?

[Lelio Fulgenzi]

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 not compatible with this option.


I also find that no matter how much reading and preparation you've done, the 
upgrade never happens according to the documents. So upgrading offline helps 
figure out the process.


---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph

519-824-4120 Ext 56354
le...@uoguelph.ca
www.uoguelph.ca/ccs
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1



From: cisco-voip  on behalf of Ryan Ratliff 
(rratliff) 
Sent: Thursday, October 27, 2016 1:22 PM
To: Anthony Holloway
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] Not supported I'm sure. but what do you think?

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 before you roll it into production?

Is it >

-Ryan

On Oct 27, 2016, at 12:02 PM, Anthony Holloway 
> wrote:

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 failed to deliver on, 
which is performing your upgrades during production on the inactive partition 
and then switching versions in a maintenance window.  If they would have only 
held themselves to a higher standard, we wouldn't need this complex of an 
alternate solution.

On Tue, Oct 25, 2016 at 2:45 PM, Ryan Huff 
> wrote:

Matthew is correct, copying is listed as "Supported with Caveats" at: 
http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements; The 
caveat being found at 
http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements#Copy_Virtual_Machine


The VM needs to be powered down first and the resulting VM will have a 
different MAC address (unless it was originally manually specified); so you'll 
need to rehost the PLM if it is co-res to any VM that you copy.


Where I have seen folks get into trouble with this is where a subscriber is 
copied, and the user mistakenly thinks that by changing the IP and hostname it 
becomes unique and can be added to the cluster as a new subscriber. I have also 
seen users make a copy of a publisher and change the network details of the 
copy, thinking it makes a unique cluster and then wonders why things like ILS 
wont work between the two clusters (and it isn't just because the cluster IDs 
are the same).


Having said all of that, I would NEVER do this in production ... maybe that is 
just me being cautious or old school, but that is just me. Even without 
changing network details on the copy, I have seen this cause issues with 
Affinity. At the very least, if you travel this path I would make sure that the 
copy runs on the same host and even in the same datastore.


=== An alternative path ===


Admittedly, this path is longer and there is a little more work involve but is 
the safer path, IMO and is what I would trust for a production scenario.


1.) Create a private port group on the host. If the cluster is on multiple 
hosts, span the port group through a connecting network to the other hosts but 
DO NOT create an SVI anywhere in the the topology for that DOT1Q tag 
(remembering to add a DOT1Q tag on any networking devices between the two hosts 
and allowing on any trunks between the two hosts).


2.) Upload Cisco's CSR1000V to the host. If you're not familiar with the 
product it is at the core and unlicensed, a virtual router with three 
interfaces by default. Out of the box, it is more than enough to replicate 
DNS/NTP on your private network which is all you'll need. Assign the private 
port group to the network adapters and configure DNS and NTP (master 2) on this 
virtual router.


3.) Build out a replica of your production UC cluster on the private network.


4.) Take a DRS of the production UC apps and then put your SFTP server on the 
private network and do a DRS restore to the private UC apps.


5.) Upgrade the private UC apps and switch your port group labels on the 
production/private UC apps during a maintenance window.


Thanks,


Ryan





From: cisco-voip 

[cisco-voip] mobile UCCx agents

[Lelio Fulgenzi]

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 software 
>(CAD/Finesse). Same thing goes for Jabber.


I was hoping that we could get this to work with the phone agent on a Cisco 
wireless phone, but while the 7925 is a supported phone agent device in UCCx 
v9, the new 8821 wireless phone is not listed as a Finesse Phone Agent 
compatible device.


Considering they do a lot of transferring to other extensions, any cell phone 
solution would also require mid-call enterprise feature access is my thought.


Am I missing something obvious here?


---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph

519-824-4120 Ext 56354
le...@uoguelph.ca
www.uoguelph.ca/ccs
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Not supported I'm sure..... but what do you think?

[Ryan Ratliff (rratliff)]

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 before you roll it into production?

Is it >

-Ryan

On Oct 27, 2016, at 12:02 PM, Anthony Holloway 
> wrote:

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 failed to deliver on, 
which is performing your upgrades during production on the inactive partition 
and then switching versions in a maintenance window.  If they would have only 
held themselves to a higher standard, we wouldn't need this complex of an 
alternate solution.

On Tue, Oct 25, 2016 at 2:45 PM, Ryan Huff 
> wrote:

Matthew is correct, copying is listed as "Supported with Caveats" at: 
http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements; The 
caveat being found at 
http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements#Copy_Virtual_Machine


The VM needs to be powered down first and the resulting VM will have a 
different MAC address (unless it was originally manually specified); so you'll 
need to rehost the PLM if it is co-res to any VM that you copy.


Where I have seen folks get into trouble with this is where a subscriber is 
copied, and the user mistakenly thinks that by changing the IP and hostname it 
becomes unique and can be added to the cluster as a new subscriber. I have also 
seen users make a copy of a publisher and change the network details of the 
copy, thinking it makes a unique cluster and then wonders why things like ILS 
wont work between the two clusters (and it isn't just because the cluster IDs 
are the same).


Having said all of that, I would NEVER do this in production ... maybe that is 
just me being cautious or old school, but that is just me. Even without 
changing network details on the copy, I have seen this cause issues with 
Affinity. At the very least, if you travel this path I would make sure that the 
copy runs on the same host and even in the same datastore.


=== An alternative path ===


Admittedly, this path is longer and there is a little more work involve but is 
the safer path, IMO and is what I would trust for a production scenario.


1.) Create a private port group on the host. If the cluster is on multiple 
hosts, span the port group through a connecting network to the other hosts but 
DO NOT create an SVI anywhere in the the topology for that DOT1Q tag 
(remembering to add a DOT1Q tag on any networking devices between the two hosts 
and allowing on any trunks between the two hosts).


2.) Upload Cisco's CSR1000V to the host. If you're not familiar with the 
product it is at the core and unlicensed, a virtual router with three 
interfaces by default. Out of the box, it is more than enough to replicate 
DNS/NTP on your private network which is all you'll need. Assign the private 
port group to the network adapters and configure DNS and NTP (master 2) on this 
virtual router.


3.) Build out a replica of your production UC cluster on the private network.


4.) Take a DRS of the production UC apps and then put your SFTP server on the 
private network and do a DRS restore to the private UC apps.


5.) Upgrade the private UC apps and switch your port group labels on the 
production/private UC apps during a maintenance window.


Thanks,


Ryan





From: cisco-voip 
> 
on behalf of Matthew Loraditch 
>
Sent: Tuesday, October 25, 2016 3:01 PM
To: Tommy Schlotterer; Scott Voll; 
cisco-voip@puck.nether.net

Subject: Re: [cisco-voip] Not supported I'm sure. but what do you think?

I can’t see any reason it wouldn’t be supported honestly. Offline Cloning is 
allowed for migration/backup purposes. I actually did the NAT thing to do my 
BE5k to 6K conversions. Kept both systems online.



The only thing I can think to be thought of is ITLs, does an upgrade do 
anything that you’d have to reset phones to go back to the old servers if there 
are issues? I don’t think so, but not certain.



Matthew G. Loraditch – CCNP-Voice, CCNA-R, CCDA
Network Engineer
Direct Voice: 443.541.1518

Facebook | 
Twitter | 
LinkedIn 
| 

Re: [cisco-voip] Not supported I'm sure..... but what do you think?

[Anthony Holloway]

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 failed to deliver on,
which is performing your upgrades during production on the inactive
partition and then switching versions in a maintenance window.  If they
would have only held themselves to a higher standard, we wouldn't need this
complex of an alternate solution.

On Tue, Oct 25, 2016 at 2:45 PM, Ryan Huff  wrote:

> Matthew is correct, copying is listed as "Supported with Caveats" at:
> http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements;
> The caveat being found at http://docwiki.cisco.com/
> wiki/Unified_Communications_VMware_Requirements#Copy_Virtual_Machine
>
>
> The VM needs to be powered down first and the resulting VM will have a
> different MAC address (unless it was originally manually specified); so
> you'll need to rehost the PLM if it is co-res to any VM that you copy.
>
>
> Where I have seen folks get into trouble with this is where a subscriber
> is copied, and the user mistakenly thinks that by changing the IP and
> hostname it becomes unique and can be added to the cluster as a new
> subscriber. I have also seen users make a copy of a publisher and change
> the network details of the copy, thinking it makes a unique cluster and
> then wonders why things like ILS wont work between the two clusters (and it
> isn't just because the cluster IDs are the same).
>
>
> Having said all of that, I would NEVER do this in production ... maybe
> that is just me being cautious or old school, but that is just me. Even
> without changing network details on the copy, I have seen this cause issues
> with Affinity. At the very least, if you travel this path I would make sure
> that the copy runs on the same host and even in the same datastore.
>
>
> === An alternative path ===
>
>
> Admittedly, this path is longer and there is a little more work involve
> but is the safer path, IMO and is what I would trust for a production
> scenario.
>
>
> 1.) Create a private port group on the host. If the cluster is on multiple
> hosts, span the port group through a connecting network to the other hosts
> but DO NOT create an SVI anywhere in the the topology for that DOT1Q tag
> (remembering to add a DOT1Q tag on any networking devices between the two
> hosts and allowing on any trunks between the two hosts).
>
>
> 2.) Upload Cisco's CSR1000V to the host. If you're not familiar with the
> product it is at the core and unlicensed, a virtual router with three
> interfaces by default. Out of the box, it is more than enough to replicate
> DNS/NTP on your private network which is all you'll need. Assign the
> private port group to the network adapters and configure DNS and NTP
> (master 2) on this virtual router.
>
>
> 3.) Build out a replica of your production UC cluster on the private
> network.
>
>
> 4.) Take a DRS of the production UC apps and then put your SFTP server on
> the private network and do a DRS restore to the private UC apps.
>
>
> 5.) Upgrade the private UC apps and switch your port group labels on the
> production/private UC apps during a maintenance window.
>
>
> Thanks,
>
>
> Ryan
>
>
>
>
> --
> *From:* cisco-voip  on behalf of
> Matthew Loraditch 
> *Sent:* Tuesday, October 25, 2016 3:01 PM
> *To:* Tommy Schlotterer; Scott Voll; cisco-voip@puck.nether.net
>
> *Subject:* Re: [cisco-voip] Not supported I'm sure. but what do you
> think?
>
>
> I can’t see any reason it wouldn’t be supported honestly. Offline Cloning
> is allowed for migration/backup purposes. I actually did the NAT thing to
> do my BE5k to 6K conversions. Kept both systems online.
>
>
>
> The only thing I can think to be thought of is ITLs, does an upgrade do
> anything that you’d have to reset phones to go back to the old servers if
> there are issues? I don’t think so, but not certain.
>
>
>
> Matthew G. Loraditch – CCNP-Voice, CCNA-R, CCDA
> Network Engineer
> Direct Voice: 443.541.1518
>
> Facebook  | Twitter
>  | LinkedIn
>  |
> G+ 
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On Behalf
> Of *Tommy Schlotterer
> *Sent:* Tuesday, October 25, 2016 2:49 PM
> *To:* Scott Voll ; cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] Not supported I'm sure. but what do you
> think?
>
>
>
> I do a similar, but supported process. I take DRS backups and then restore
> on servers in a sandbox VLAN. Works well. Make sure you check your phone
> firmware