OPSMAN moving

[mitello]

Hello all,

I have an opsman server and I am trying to become more adept at programming. We have a 3300 and a 2000. When I try to move a user from the 2000 to the 3300, if they have a DSS of another user that is still on the 2000, the move fails and asks me if I want to correct it or move it to the detained section. So my question is if I move user A with an appearance of user B and it fails, and I move it to the detained section then move user B, can I then go to the detained section and move user A successfully? If so, can I do that with a whole department that has appearances of each other? Right now I have been deleting the keys from user A before moving it.

Thanks in advance

 

[kwbMitel]

Deleting the keys before moving and then recreating is probably best if you have a lot of key lines, BLF's, or any other non-prime associated keys.

Watchout for Pickup groups, Page groups, Huntgroups, and any other Prime line associated functions.

If at any time the move fails, send to detained, correct issue and re-initiate from detained. You may lose info in the process so be cateful.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[Robusto]

the SX-2000 needs a software option called DSS/BLF.

then you need to cluster the two systems.

then you can program extensions from either system as
a key line appearance on the desktop

 

[MitelInMyBlood]

Even if clustered, key appearances, BLF's (& remote BLFs), call pickup group info, etc. will not survive a station move from one element of the cluster to another, ie, coming from the SX2K to the 3300. As kwbMitel suggests, your best bet is to delete these key appearances, pickup group, hunt group membership, etc. before attempting to do the move.

Personal speedcall keys (buttons on the phone) will survive the move, so will clos/clor, (make sure they're configured identically between elements). USER PROGRAMMED forwarding should survive, but check it afterwards to be sure.

System rerouting may survive the move, but won't work afterwards because the pointers refer to destinations in the call reroute 1st alt/2nd alt tables on the local switch, not on the one you just moved from, so be careful with these as well.

I do not know if a user's predefined list of personal speed calls will survive a cluster move or not. Thankfully none of my 1500 users even know about that feature... wisely we never gave it to them.

Arguably the safest move between elements will be a clean move where you bring only the user and his/her bare extension without features. Once the move is completed then you can set about the task of reinstating their features. Yes, you can have a remote BLF, but my experience with these is "you'll be sorry" because of the propagation delays (the actual condition of the key appearance is not precisely in-synch with the actual condition of the monitored line... the signalling delays will eventually bite you.

Remember Heartbreak Ridge & one of Clint Eastwood's very descriptive phrases from that movie. If you saw the movie you know that "Cluster" is only half a word.

 

[Virtualman9000]

I can chime in here and say that personal speedcalls WILL survive the move between elements. I've done many recently from 2k to 3300. Nothing else seems to live through it. I think mitello's thinking here is that if user B is a key appearance on user A, and user A goes in to the detained user updates until user B is moved, the line appearance of user B on user A's phone will be valid. That DOES work. I suppose with careful planning you could move a department if all the moves were detained and then fixed one at a time. Try it with a few and see - the worst that would happen is you would have to fix them from the detained section.