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 strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Migrating extensions from Peripheral Sub Cabinet (Shelf 2 Copper) to a new Cabinet (Shelf 1 Fiber)

Status
Not open for further replies.

Bahamex1

Technical User
Jul 30, 2013
19
BS
Hi All.

I have a challenge that I need to make as painless as possible.

My customer (a Hotel) with a 3300 Controller running MCD 4 has two peripheral Cabinets off a dual FIM Module (Cabinet 2 and Cabinet 3) which host Administrative extensions and Extended Peripheral Cabinets off the two Per Cabinets (Shelf 2) via Peripheral Interconnect Cards (copper) which host guest room extensions (Digital and analog).

Cabinet 2 Shelf 2 took some sort of hit and after replacing the cabinet with a new one and powering it up, noticed that some other cards are also not working, including the Peripheral Interconnect Card.
I do not have a spare Peripheral Interconnect Card but I have a FIM, a Peripheral Switch Controller card and a second Dual FIM Module on the controller which is being used to connect to an NSU and the Second FIM interface is free.

My Plan is to convert the replacement Cabinet to a Peripheral Cabinet (as opposed to Extended Peripheral Cabinet) using Fiber but that means I will have to change the PLIDs of all the programmed guest room extensions in that Cabinet (12 cards). So from 2 2 1 1 to 5 1 1 1 for example (if Cab 4 is being used by the NSU already).

Someone told me I should Program the new cabinet with the exact types of cards and then program bogus extensions on it. Once filled up, I should do a move swap command for each extension to move it over. This sounds like a lot of work still if I have to do it one-by-one nearly 200 times.

Please tell me there is another way to accomplish this that is simpler.

Your feedback will be greatly appreciated.
 
I think the recommendation is valid, that's what I'd do. Likely set it up with *ext so I could swap without guessing.

You may find other opinions.
 
Thank you jpruder.

Any other opinions out there?
 
Just wanted to update the thread to let you know that I did the migration manually as it was suggested to me.

The only obstacle I encountered was that the extensions that were registered as "Guest room extensions" were not swappable, so I had to take them out of the Guest room list, swap them and then enter them again.

Also, the digital Superset 4025s had an old AIM programmed that was no longer in use. Those ones would also give you an error if you tried to swap them because the AIM could not be move swapped. Luckily I was able to delete those old modules and do the swaps for those too.

Everything ended in 6.1.x.x and I deleted what was moved to 2.2.x.x

Not as tedious as I thought it would be thanks to range programming.
 
A little late to the party but...

As these were room phones with very basic programming and all being the same it is likely it would have been quicker/easier to simply delete and recreate.

That being said, the move swap retains all features and names so that is sometimes worth keeping

One HUGE caveat with the move swap command that really doesn't apply in this case but is worth mentioning to anyone thinking of using it. If you EVER want to use the old port again you MUST verify that the message waiting indicator is not active against the port or you will have serious regrets.

One nice trick I used for swapping 40XX sets that are of different types was to create temporary extension of the same type and do a 3 way swap
e.g.
Port 1 is 4015
Port 2 is 4025
Port 3 is blank
Create port 3 as 4015 and swap with port 1
Change set type on port 1 to 4025
Swap port 2 with port 1
Change set type on Port 2 to 4015
Swap port 3 with Port 2
Delete port 3


**********************************************
What's most important is that you realise ... There is no spoon.
 
I also do the three way when set type is different. I know in some older versions when using the move swap any blfs were hosed. I don't think that is the case anymore. Also if using pick up groups, record the value prior because that stays with the port
 
Good information kwbMitel and jpruder.

Hopefully others will be able to use it.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top