Lync 2013 Test Plan

For some reason, the concept of conducting full function tests prior to ending the Lync POC or pilot project has come up again and again.  Those pesky customers just keep insisting. 

Usually, the customer has already come up with a fairly exhaustive test plan on their own and all I need to do is help them revise or add expectations. If they have not developed their own test plan, I first point them to the Lync 2013 RASK. 

The Lync Rollout and Adoption Success Kit can be found here.  If you poke around the semi-convoluted structure you will eventually divine the logic, but you are probably better at that than I am.  At any rate, eventually you will find stumble upon this link:  http://www.microsoft.com/en-us/download/confirmation.aspx?id=37031 which is the download page for the Lync 2013 Rollout and Adoption Success Kit (RASK) Resources package.  A very nice piece of kit.  This download has the following format:

I have taken the liberty of showing the location of the subject for this article – the “Sample Pilot Test Plan.xlsx”.  What you see below is a modification of that fine piece of work. In its’ base form, the RASK test plan has saved me many hours of skull sweat – and most likely saved my customers many hours as well.  For a simple Lync deployment, you may be able to use it as is.

But the real value of the RASK test plan is to get your head into the game.  Accordingly, my modifications are just that, MINE  - as needed for a project, and then modified past that to serve as my personal baseline test plan.   

If you were to run a full system test and that included HA and DR, you would also iteratively fail Front End Pool members and run full-tests per this matrix with each pool member offline in turn.  And then you would need to create the same set of tests with perhaps one Edge Server offline and then consider your other environment details. And then loop through for each pool member off in turn et cetera. You may end up with a matrix with a considerable number of test cells to complete. I one time did a project where the core HA/DR test matrix resulted in 900+ individual test cells.  Each cell was one complete test that contributed to the overall upper level test.  Fun! But in the end, if someone asks you, you can show them, yes, we tested.

I try very hard to accomplish the testing inside out and and using this order of tests:

1. Test the FE pool level -  this may include monitoring, archiving, persistent chat, and Office Web Apps Servers
2. Test the Edge (Edge servers and reverse proxy)
3. Test mobility clients
4. MPOP scenarios

Resist the urge to use real users.  Gin up a set of test accounts, per pool, and use those accounts for the testing.  If you MUST use real accounts, be in control of the testing flow or you will be like this when things don’t go exactly right and the testers start veering off into the own little interest area.

So, without further ado, here is a sample what I use as my baseline in screen cap format – a download link can be found at the bottom of this article. 

 

Here is the download link.

YMMV.

A duplicate name exists on the network

There I was, doing some menial tasks associated with validating a full HA, multiple geographical site deployment.  We had just got the final Edge pool up, and were checking mobility client connections and functions.  In walks my client counterpart and he wants to deploy the monitoring server databases.  Previously the customer had modified the topology to include monitoring per pool, published the topology, and had reported that the databases did not install.

Easy-peasy says I.  So we opened the Topology Builder and worked through the process to deploy just a database.  We carefully chose our target server, changed the default locations for the data and the logs. For those readers who are dying to know how to accomplish this after having the pools already installed, here is a quick primer using Topology Builder.

(by no means is this an authoritative guide to installing monitoring databases – if you need that see this)

Adelante!  From the Topology Builder….

Select the SQL server you want, make sure it is highlighted, then click on advanced.

If your DBA does not care, you can leave these fields blank, if the DBA does care, then you will need to get with him/her and figure this out:

At this point, you are ready to go:

…and we were rewarded with the following announcement.

“You were not connected because a duplicate name exists on the network.”

In defense of our failure, the error message was in a very nice color of red.  In honor of that detailed bit of programming, you will note that I have colored my error message in the same brilliant hue.

We were using a service account that was a domain admin, had local logon rights to the target SQL server and was an SA equivalent on the target SQL server.  We double checked membership in the CSAdministrator and RTCUniversalServerAdmins groups. The SQL server was pingable.  The environment is using an alias for the SQL server FQDN.  So we verified that the FE pool member from which we were running PowerShell could see and ping the SQL server by FQDN, IP, and CName.  All good.  We also did a little judicious DNS peeking to make sure that a duplicate name did not exist.

So we tried the process again, but this time I brightly used the PowerShell cmdlet.

Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn SQLServer.FQDN –Verbose

Failure, but the verbose option gave us another pretty red error with a bit more information…

WARNING: Install-CsDatabase failed.
WARNING: Detailed results can be found at "C:\Users\SVC_Lync\AppData\Local\Temp\5\Install-CsDatabase-201de519-f3ac-4f0f-a221-b0cacc897e27.html".
Install-CsDatabase : Command execution failed: You were not connected because a duplicate name exists on the network. If joining a domain, go to System in Control Panel to change the computer name and try again. If joining a workgroup, choose another workgroup name.

Not so good.

Having already checked permissions and names and DNS, we then turned to Bing’ing and the ubiquitous Google-fu.  After some detailed searching, some boring reading, and superfluous checking of various settings, I stumbled across this on Mark Menasi’s forum.  While it did not exactly apply, it was certainly worth a shot (after all, nothing else was working).  After a little discussion in which we decided on a plan to unwind this registry hack if results did not meet expectations, we did the following to the demon SQL server in question:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
Value name: DisableStrictNameChecking
Data type: REG_DWORD
Radix: Decimal
Value: 1

We then were successful with the install-csdatabase cmdlet.  LCsCdr and QoEMetrics databases are installed and we have data flowing.

YMMV.

Where is my Lync PIN Stored?

I don’t know why this question came up, but a client asked me today: “where does Lync store the user’s conference PIN?” I hate questions to which I don’t know the answer.  A few ideas came to mind; a co-worker suggested that the PIN was in SQL somewhere.

So I went looking.  Dang!  and looked.  And poked.  And prodded.  But finally!

RTCLocal instance, RTC database.  The table is dbo.UserPinMembership.

But, when you look at it, the actual PIN appears to be a one-way hash (like AD storing passwords). 

So, even after you find the magical user PIN, do not attempt to edit this value directly or you will probably be sorry.  Instead, use the PowerShell cmdlets provided for that purpose.

Take a look at

Set-CSClientPin

Get-CSClientPinInfo

and if you are really adventurous,

Set-CSPinSendCAWelcomeMail which can be used sort of like this for the one-offs, or you can read a csv and set everyone at once.

Set-CsPinSendCAWelcomeMail -UserUri "sip:jweber@domain.com" -From "helpdesk@domain.com" -SmtpServer vmailbox.domain.com -Subject "your PIN" -Pin "135791" -Force -Verbose -UserEmailAddress jweber@domain.com

But trust me, don’t try to change or set the PIN using direct SQL edits.

YMMV.

Project Failures

Disclaimer: I have no idea who authored this blog, or which organizations website hosts the blog. 

As I read through the following article, I was faced with the classic introspection question: how does each of these apply to me?  http://calleam.com/WTPF/?page_id=2338

In the midst of some business process research I ran across this and it proved to be very interesting reading.  As a consultant, I participate in both sides of the sales process and on all sides and phases of project delivery.  I found comparing the failure attributes to projects in which I participated was very insightful.  Not every reason listed may apply to every project – but the level of detail and the implied attention to detail required of the consulting engineer is an excellent starting outline for necessary professional skills, and demonstrates the depth and breadth of knowledge and experience required to successfully deliver IT projects.

YMMV