One of the things during the mist of either a disaster recovery exercise or performing the real thing is confirmation if you have truly failed over and / or failed back. Running the cmdlet Get-CsUserPoolinfo username does not really tell you, that you have failed over and or failed back. In addition once you have run the Invoke-CsPoolFailover and Invoke-CsPoolFailback cmdlets you can dig around and find the cmdlet logs to see what occurred though the process; but what about a simple notification that you have failed over or failed back and the pool is functioning well. Without such notification we are left wondering, “How do I truly know if I failed over or failed back with my Skype pool?”
We will look at are the following areas:
- Get-CsUserPoolinfo
- Failover
- Failback
Get-CsUserPoolinfo
The Skype cmdlet Get-CsUserPoolinfo can be leveraged to find out what pool a user belongs to; in addition to find out what are the secondary and tertiary front-end servers for the specified user. If we continue to look further, we can also see the backup pool information for the user along with the primary, secondary and tertiary front-end servers for the paired pool as well.
While this information is useful to us, during the mist of a failover, the information does not change. You will not see anything here that tells you, “You are now registered to the backup pool.” Yes, you could look at the configuration information of your Skype client, but running the Get-CsUserPoolinfo cmdlet will not tell you definitely, where you are located at that exact moment.
Figure 1:
Failover
Now I am going to assume that you have just performed a failover to your paired pool, someone is going to eventually ask you one, if not all of the following questions:
- Did you failover the effected pool?
- Was it successful?
- How can you tell?
I will not bring up in conversation about the Central Management Store (CMS); I will save that for a later article. We will just assume that this pool does not contain the CMS and you are just performing a failover. Besides looking at the output of the log file that will be generated when you run the Skype cmdlet Invoke-CsPoolFailover -PoolFqdn pool.contoso.com -DisasterMode –Verbose. The event ID you are looking for to get confirmation that you did indeed perform the failover and it was successful is event ID 32155 in the Lync event logs. Once identified you will see that the event notifies you that the pool failover is complete as seen in figure 2 below.
Figure 2: Pool Failover Complete
Failback
Now just as we have performed the failover and have received confirmation, we will want to do the same thing for the failback. Soon as your effected datacenter becomes stable and online again, you may be asked to failback the users that were in the effected pool. Once you have performed the failback by running the Skype cmdlet Invoke-CsPoolFailback -PoolFqdn pool.contoso.com -DisasterMode –Verbose you are going to ask yourself these questions or someone else is going to ask you the following questions:
- Did you failback the pool?
- Was it successful?
- How can you tell?
The event ID you are looking for to get confirmation that you did indeed perform the failback and it was successful is event ID 32157 in the Lync event logs. Once identified you will see that the event notifies you that the pool failback was complete as seen in figure 3 below.
Figure 3: Pool Failback Complete
A little confirmation is always nice
At the end of the day, failing over a pool and then failing it back can be a little nerve racking, especially when under pressure, not matter if you have 20,000 users on the pool or a few hundred. What we are looking for at the end, is confirmation that the procedure we just went through with either the Invoke-CsPoolFailover or Invoke-CsPoolFailback cmdlet was successful and our users are safe and sound in their respective pool we were trying to locate them on.
