Lync 2013 Workloads–ZoomIT version

I was doing some light reading today, and ran across this up on NextHop.  Specifically, I think the ZoomIT version is flat out awesome!

http://zoom.it/mafE#full

Take a look.  Very good stuff.

YMMV

Move Lync 2013 Universal Groups

This process is unsupported.  This process has only been tested in lab and in one production environment.  If you try this, and it goes sideways on you, you are on your own.  This process is unsupported, undocumented, and full of risk.

Scenario

You have OCS 2007 R2 and Lync 2010.  You want to go to Lync 2013.  You inherited the AD and the entire OCS/Lync environment from a previous regime.  You have one AD forest with multiple child domains. You discover that the Lync Universal Groups are not in the default root domain container ou=users,dc=corp,dc=domain,dc=com.  You may have discovered this when Forest Prep fails to run because it finds the universal groups in a child domain and dumps out with an error message about using enable-csforest with a –groupdomain attribute.  See here.  Or you may have discovered that a previous administrator installed the default universal groups into a child domain.  And for a variety of business and technical reasons, you really want/need that specific child domain to go away.  Oh, and both the R2 and the Lync 2010 are in production.

What to do now?  If you manually run the enable-csadforest with a groupdomain attribute set to the existing child domain then remove that child domain, Lync will surely fail.  But you need those universal groups to move.  And UofG and UofB give you NOTHING.  Talking to your peers will reveal that moving those universal groups is not supported.  There is nothing in the documentation to provide guidance – other than to state that the groups belong up in the forest root domain.

I recently had this very scenario.  And I had to move those groups.  Here is what I did (more correctly, what we did).

And remember I have been very upfront about this being unsupported – don’t do this if you are not totally sure it will work for you – or if you are not confident in your skills to run through an entire implementation project from start to finish in a very short time frame to restore services.

Process

Back up your AD.  You do this regularly already, right?!  BTW, when was the last time you did a restore of that backup?  A backup is only as good as its’ ability to be restored.  Another great reason to run a lab.

Get management approval for a Plan B which involves services being out for xx days while things are nuked, scrubbed, and rebuilt.  Prepare for throwing away the configuration container – in the case of my lab – this DN:

Go through all these groups and record all their memberships:

In my case, with R2 involved, services on the R2 servers were running as logins that belonged to the RTCcomponentUniversalServices groups.  In addition, the RTCUniversalServerAdmins might have a few gems hidden in there.

Go to each server in the R2/Lync environment (including non-domain member Edge Servers) and make sure you know exactly how things are running and under what authority.  Lync makes this easy – Network Services; R2 can be more problematic.

Go read up on ADMT.  Active Directory Migration Tool for those of you who may not know.  A great piece of kit.  You can download it here.  If you don’t have it already, download it, install it, play with it, lab out your actions.

Backup your user databases.  If you have to rebuild from nothing, after you get your users restored, you can use DBIMPEXP to restore your users’ data.  In my case, I got very lucky – the customer was willing to bake the entire mess if Plan A did not work out.  So I got to skip this – I strongly suggest that you do not.  You can read up on the R2 DBIMPEXP here.  The Lync 2010 instructions are here.

If you have Lync 2010, then I suggest you run an export-csconfiguration and get that zip file to somewhere safe.  If you need it, you can use it to just put things back together the way they were.  You do have the entire system documented don’t you?  If you have R2, then the same is needed, but it doesn’t really exist except in the above backup guidance for R2.  I sure hope you know all your FQDN’s, IP’s, and have copies of all your certificates – especially the public certificates.

If you have Enterprise pools, then you need to go to the SQL server that hosts your databases and make SURE you record what database has what RTC group for login, and what rights.  You are going to need this.  While ADMT, with an intra-forest move, will retain SID history, the SQL server won’t magically change.  So you will need to duplicate ALL the Lync/R2 perms that are listed per R2/Lync database.  For example, in our case, global\RTCUniversalServerAdmins needed to change to corp\RTCUniversalServerAdmins.  I got lucky – we had a killer DBA who scripted the entire thing.  SQL does not need SID, it uses the UPN, looks up the account, and sees if matches what it has in its’ tables.  Again, I think I got lucky on the SQL side, and I am sure I am not explaining this all that well.  But take a look at this:

For this one database, there are three groups that need to change – again in my case from global\rtc* to corp\rtc*  and don’t forget to look at the SQL security node and observe that the groups in question may have differing rights per database and per group.

SQL has two spots – the security node

and the users per database

You need to pay attention to both areas, security login and database user,  and get the groups correct.

Go back and read about extending AD schema for Lync.  Remember that you might be doing this step if you need to nuke that configuration container.  Do this for Lync Forest Prep and Lync Domain Prep also.  Just make certain you know.  All three subjects are covered here.

OK.  You got yourself documented, backed-up, SQL handled, ADMT installed.  And you have all your actions mapped out, written down, recorded, and prepared.  In my case we also prepared a somewhat detailed plan of what we were going to do in case Plan A failed, and the support we were going to need to make a whole new environment from scratch.

Make sure that ADMT is set to maintain SID history; for an inter-forest group move, it really should do that already, but you cannot be too safe. Then move the following groups using ADMT.  Move them to ou=users,dc=domain,dc=com – your domain naming structure might be a bit different, but you get the idea.  The default “users”  OU in the forest root domain.

Make sure your SQL security logins and database rights are correct.

Patience.  Wait for your AD to converge.  In my case, it took a bit. Full convergence was about 16 hours, but the domains I was worried about took about 30 minutes.

Reboot your affected servers. 

My environment came right up and was happy.

Remember what I said about this being unsupported.

YMMV

Lync 2013 Remote Admin with PowerShell

Scenario

You would like to use your desktop/laptop to administer your Lync 2013 environment, or you need to supply some RBAC access to a specific administrative group – i.e., voice admins.  Additionally, you don’t want to give remote server access to everyone.  In this article, we will take a look at what is needed to accomplish this.  But, before you begin, read this, which is a TechNet blog on how to do this with Lync 2010.  Then read MVP Curtis Johnstone’s blog on this, and then this other blog from TechNet.  Maybe I am a bit dense, but it took me all three to put this together.  If you are looking to do this for Lync Online, read this. and then this.

Requirements:

Lync 2013 is 64-bit.  No getting around this.  What this means is that you cannot deploy the Lync 2013 Administrative tools to an x86 machine.  If you have a squeaky new Windows 8 x64 machine, you are all set.  But if you have an x86 or x64 Windows 7 machine (probably the vast majority) – you will need to do some preparation. 

At any rate, you need to ensure that your Win7 is at SP1.  Then you need to install .Net 4.0 – the entire thing, not just the client side.  You can get the .net 4.0 here. You may also attempt to use .net 4.5; but for this exercise, I used the 4.0.  After you get done with these installs, you will of course want to think about re-running Windows Update to pick up the myriad patches that will ensue.  Next, you are going to need PowerShell V3.  You can get that here.  In my little world, I had a heck of a time getting PowerShell v3 to install on my Win7 x86 VM.  I ended up having to throw it (the VM) away and start from a fresh install.  YMMV.

Once we have that in place, you can proceed with setting up for one of two scenarios:  x64 or x86.

If you have x64, then you can simply open the Lync 2013 Deployment wizard (in my lab the Lync setup is located on a mounted ISO: d:\setup\amd64\setup.exe ) and install the admin tools.

If you have x86, you are going to be limited to running just PowerShell in remote mode.  Which is the whole point to this article, eh?  Let’s take a look at what needs to be done so that you can bask in the goodness that is remote PowerShell and Lync 2013 administration.  Remember that using credentials that equate to a RBAC role of, say, CSUserAdministrator, will result in only those cmdlets that support that functionality.  You can read up on Lync RBAC here.

If your servers are on your network, fine.  If you are really remote, you will need a VPN of some sort so that you can connect yourself to the network subnet in question. Once you have the network connection part figured out (and no, I cannot help you with that), you are ready for this:

# get creds for remote environment

$credential = get-credential "domain\johnw"

# set session options to bypass the PKI checks - I trust the far side

$sessionoption = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck

#create new session

$session = New-PSSession -ConnectionUri https://somelyncfrontendserverFQDN.domain.com/ocspowershell -Credential  $credential -SessionOption $sessionOption

# assuming the above line worked, import the cmdlets needed for Lync

import-pssession $session

A few notes:  You are going to have to have some credentials – no getting around that.  I also tend to go straight at an FE, not to the Load Balancer.  The $sessionoption line causes the Front End server IIS internal services certificate to be basically ignored, so if you connect to a domain server from a non-domain workstation, you should be OK.  The actual script line for my connection was:

$session = New-PSSession -ConnectionUri https://ls2013e2.tsoorad.net/ocspowershell -Credential  $credential -SessionOption $sessionOption

Don’t overlook the “https”  - http will not work.

Operations

Here is the script in action on an non-domain member, x86, Windows 7 SP1 workstation:

Asking for credentials

Credentials accepted, session established, and fetching the Lync cmdlets from the server

Just to show we have what we really want, here is the CS* cmdlets…

 

Remember that from your reading through the references I give you up above, not ALL of the Lync cmdlets will work.  Synthetic transactions, for instance, need to run directly on the server.  For a refresher on that information, see this.

But, to prove that we can control Lync Server remotely, a quick list of my lab CS users:

YMMV

Lync 2013 using DFS

 

It is well documented that you can have a Lync file share on a DFS share.  You can read about that right here.  But what is missing in that documentation is the syntax for creating the file store in the Lync Topology Builder.  As many times as I have done this task, I always forget.  Then I have to work my way through it and figure out the syntax.  And the documentation does not help when it comes to the Lync. Well, no more. 

YMMV

Lync File Share and Database size Estimator

My thanks to Pat Richard for helping with the math, the look/feel, and for everything else he does.  See Pat here

Have you ever wondered just how much space you need to plan for when deploying Lync?  The file share and the databases can consume some serious space if you set things wrong.  Would you like to input some numbers and see what you might be looking at down the road a piece?  Concerned with coming up a tad short? Want some ammo to convince the powers-that-be to allow you to twiddle the settings a bit and reduce the impact of having 730 days of Lync Monitoring and Archiving data on a drive somewhere?

Well, I have a (partial) answer.  The Lync 2013 File Share Space Estimator.  A quickie little tool to provide you some answers. 

YMMV

IE11 Send to OneNote Borked

Do you use OneNote and send things from IE to OneNote? Have you updated to Win8.1 and IE11? Have you noticed that your IE11 and OneNote 2013 are no longer compatible and in fact you get a nasty message about restarting OneNote and configuring it when you try to send things to OneNote?

OneNote needs to set itself up before you can send to it.  Please run OneNote and then try sending again.

Of course, starting, stopping, reinstalling, playing with, or doing anything else with OneNote does not resolve this.  However, the fine folks at http://www.onenotegem.com/ have provided a simple explanation and solution.  See this right here:  http://www.onenotegem.com/2/post/2013/09/how-to-use-send-to-onenote-or-bring-to-onenote-in-ie-11-in-win81.html

YMMV