Move Your Lync/Skype Users Faster

Hypothesis and Assumption

The other night during an upgrade, I had to move 35,000 Lync users from one pool to another Skype for Business pool.  Because it was an upgrade, this wasn’t a simple Invoke-CSPoolFailover situation.  Running a Get-CSUser  | Move-CSUser command suggested the move time was going to be just short of 8 hours, well outside of our maintenance window and well into the morning where users would arrive and potentially notice.

I’ve long suspected that multi-threading the move would help, and I typically run the move across many servers out of hope and superstition, but I could never say for sure if it was real or my imagination that users seemed to move faster.  Since the back end is mirrored, all of these threads on all of these servers are really ultimately beating on the same back end server, was that the bottleneck?  This night was a good night to find out if it was faster for sure.

Testing

I have six servers in the new Skype for Business pool, breaking the users equally across all of these servers, running 4 threads per server I was able to complete all moves within 2 hours.  A HUGE 4x improvement.

I was still curious, was it because I split it across six servers, or was splitting it across multiple threads enough?  I set up a lab with a similar number of users and ran the moves there.   There were four groups of users with names starting with A, B, C, or D respectively.

Running the following command would take about 40 minutes in each direction:

Download Measure1.txt
1
measure-command {Get-CsUser -Filter {Registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com}

However splitting the command up on the same server into four threads sped the move time up so the moves completed on an average of 14 minutes total, nearly 3x faster.

Download Measure2.txt
1
2
3
4
measure-command {Get-CsUser -Filter {FirstName -like 'a*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com}
measure-command {Get-CsUser -Filter {FirstName -like 'b*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com}
measure-command {Get-CsUser -Filter {FirstName -like 'c*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com}
measure-command {Get-CsUser -Filter {FirstName -like 'd*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com}

Splitting the move across four servers didn’t seem to improve the performance much over the existing tests, though in fairness my lab is limited and runs on a single virtual host.  I’d love someone to test further with a real environment, and I will myself, but these large moves don’t happen every night so I’ll need some time before another very large test can occur.

Conclusion

  • Is it worth splitting user moves into multiple processes?  YES!
  • Is it worth splitting across multiple servers?  I strongly suspect so.
  • Is it worth trying to find the point of diminishing returns?  Probably not, we’re talking about hours of time and not days, every system is different so while it’s a fun exercise, it’s somewhat fruitless and therefore not published here.
  • Is it worth creating a script that can programmaticly divide the users to be moved into perfectly equal parts for each thread because you’re a PowerShell nerd?  Not likely, I fought this with myself… we’re again talking about hours of time here, not days.  That said, here’s a sample that splits it up by first name and opens threads in new PowerShell windows, just cut and paste a chunk into an Administrative Skype for Business Management Shell window and let it do the rest of the work for you.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'a*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'b*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'c*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'd*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'e*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'f*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'g*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'h*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'i*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'j*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'k*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'l*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'm*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'n*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'o*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'p*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'q*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'r*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 's*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 't*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'u*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'v*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'w*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'x*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'y*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"
start-process powershell -ArgumentList "Get-CsUser -Filter {FirstName -like 'z*' -and registrarpool -eq 'sourcepool.domain.com'}|move-csuser -target destpool.domain.com;pause"

And for fun, here’s an image of me running the measure-command with results in my own lab:

Capture

Reminder: Quarterly Skype for Business Users Groups

This is your quarterly reminder that the US Skype for Business (they’re re-branding!) Users Groups are coming up.

These are always fun and valuable, and a great place to network with your peers and make those relationships.  I’ll be there as well as many experts, there will be a deep dive into monitoring applications and an open forum so please feel free to ask any questions you may have.

Head over to skypeusersgroup.com and find your group on www.meetup.com.

  • October 20th – Chicago, IL
  • October 20th – Cincinnati, OH
  • October 20th – Philadelphia, PA
  • October 21st – Los Angeles, CA
  • October 27th – Nashville, TN
  • October 21st- Silicon Valley, CA
  • October 29th- Kansas City, MO
  • November 3rd- Detroit, MI
  • November 3rd- Boise, ID
  • November 4th- Milwaukee, WI
  • November 4th- Seattle, WA
  • November 5th- Portland, OR
  • November 9th- New York, NY
  • November 10th- Charlotte, NC
  • December 3rd- San Francisco, CA
  • December 3rd – Atlanta, GA
  • December 10th- Baltimore, MD

Skype for Business iOS is Available! Calm Down.

The Skype for Business iOS app was released this morning to much fanfare… I’m as excited as anyone, however I had to calm down a bit as I quickly realized some critical features that I used regularly with the Lync 2013 app using didn’t make it into the RTM version.  This is somewhat of an issue because the Skype version is an update that replaces the Lync 2013 version, there’s no going back and there’s no running them in parallel.

IOSad

Some of the most notable features missing are:

  • There is no option to set call forwarding settings.
  • There is no option to transfer a call.
  • You cannot view PowerPoint presentations unless within a desktop sharing session.
  • No group IMs.

These shortcomings are outlined here and will hopefully be addressed soon:  https://support.microsoft.com/en-us/kb/3102247

Futhermore, other issues have been spotted such as the client automatically adding a +1 (or +whatever your country code) and are mentioned here: https://support.microsoft.com/en-us/kb/3101663

I’ve personally been seeing miscellaneous crashes as well, though to be fair, many of my apps have been crashing since upgrading to iOS9, so I can’t say this is Skype related for certain.  Still, because of the official issues referred to in the article, I’ve been advising helpdesks to notify their users to hold off on the update if any of these features will cause a serious hindrance to their work.  If these features don’t affect you, it’s a pretty cool app and I’m excited to have it finally on my phone.

 

Awarded MVP for Skype for Business 2015

It’s October 1st, and I am honored to (once again) be awarded as a Microsoft MVP for Skype for Business for 2015.  Reflecting on the last year, the biggest benefit of the program really has been the opportunity to meet and chat directly with people involved in the product group as well as the close comradery of the MVP community.  One of the most surprising things is simply how vocal the MVPs are about product issues and improvements that are needed, it’s not all a Microsoft love-fest like you might have imagined.  You should know that the MVPs are in your corner, standing in front of Microsoft, unashamedly pushing and fighting for many of the ideas seen on lync.ideascale.com and skypefeedback.com.  🙂  It’s not so surprising when you consider we’ve dedicated ourselves to the solution, are vendors and implementors, and are extremely passionate about what we do.

Capture

Update: the award hit has been received and unboxed.  New pin, new card, new plaque, more stickers, and the glass disk to fit on the existing award.  If you want to see what the first award looks like, click here.

IMG_2788

Good to Know: Explaining Exchange UM Diversion Header Preference

What’s the Issue?

Here’s another one that I’ve personally fought a few times with clients that use Exchange 2007, 2010, or 2013 Unified Messaging with Avaya, Cisco or other PBX systems.  We’ve also seen it come up a few times on TechNet.  After bouncing around within voicemail, calls don’t end up where we might expect them too.  An example call flow is as follows:

  1. A call comes into an Exchange UM Automated Attendant.
  2. The caller presses a key to be transferred to User A.
  3. User A doesn’t answer.

The question is: when User A doesn’t answer, what do you expect to hear?  Do you expect to go back to the Automated Attendant or do you expect to hear User A’s voicemail?  With Microsoft Exchange, you’ll go back to the Automated Attendant, while many used to other more traditional voicemail systems are expecting to hear User A’s voicemail.   Why is this?   Simply, it’s diversion headers.

What’s a Diversion Header?

If you’re not familiar with diversion headers within your SIP packets, they’re defined a bit in RFC 5806. In a nutshell they’re used to signal a change to the ultimate endpoint that will receive a call.  We see these used heavily in voicemail systems.  When a call is routed to voicemail, the SIP INVITE is sent to the voicemail subscriber access or dial plan number with a diversion header specifying the phone number that corresponds to the mailbox.  To see this, let’s say a call comes in from the phone number 555-555-5555 to a user with phone number 888-888-8888, the Exchange dial plan has the phone number 88895 assigned.   The SIP INVITE would look like the following:

 INVITE sip:88895@10.19.10.21;user=phone SIP/2.0 
 Via: SIP/2.0/TCP 10.19.10.131:5060;branch=z9hG4bKac214495832;alias
 Max-Forwards: 70
 From: <sip:555555555@10.19.10.131>;tag=1c213481216
 To: <sip:88895@10.19.10.21;user=phone>
 Call-ID: 213439323315201145819@10.19.10.131
 CSeq: 1 INVITE
 Contact: <sip:555555555@10.19.10.131:5060;transport=tcp>
 Supported: em,100rel,timer,replaces,path,resource-priority,sdp-anat
 Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
 Diversion: <tel:8888888888>;reason=no-answer;counter=1;screen=no;privacy=off
 User-Agent: Mediant 1000/v.6.60A.030.010
 Content-Type: application/sdp
 Content-Length: 231
 v=0
 o=AudiocodesGW 212414200 212414170 IN IP4 10.19.10.131
 s=Phone-Call
 c=IN IP4 10.19.10.131
 t=0 0
 m=audio 8330 RTP/AVP 0 101
 a=ptime:20
 a=sendrecv
 a=rtpmap:0 PCMU/8000
 a=rtpmap:101 telephone-event/8000
 a=fmtp:101 0-15

The issue comes in when the call bounces around and the diversion headers stack up.  Let’s look at another invite.  This time, a call comes in from the phone number 555-555-5555 to an automated attendant with phone number 666-666-6666, the Exchange automated attendant has the phone number 88895 assigned.  The caller hits a key and the call is transferred to a user with the phone number 777-777-7777.  The 7777 number doesn’t answer and is sent back in toward Unified Messaging.  The INVITE coming back in now looks like this:

INVITE sip:88895@10.19.10.21;user=phone SIP/2.0
Via: SIP/2.0/TCP 10.19.10.131:5060;branch=z9hG4bKac1145709558;alias
Max-Forwards: 70
From: <sip:555555555@10.19.10.131>;tag=1c1145125933
To: <sip:88895@10.19.10.21;user=phone>
Call-ID: 1145084972315201145825@10.19.10.131
CSeq: 1 INVITE
Contact: <sip:555555555@10.19.10.131:5060;transport=tcp>
Supported: em,100rel,timer,replaces,path,resource-priority,sdp-anat
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
Diversion: <tel:7777777777>;reason=no-answer;counter=1;screen=no;privacy=off
Diversion: <tel:6666666666>;reason=unknown;counter=1;screen=no;privacy=off
User-Agent: Mediant 1000/v.6.60A.030.010
Content-Type: application/sdp
Content-Length: 233
v=0
o=AudiocodesGW 1143825135 1143825105 IN IP4 10.19.10.131
s=Phone-Call
c=IN IP4 10.19.10.131
t=0 0
m=audio 6990 RTP/AVP 0 101
a=ptime:20
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Exchange sees the last diversion header and sends it right back to the Automated Attendant listening on 666-666-6666 and we’re back in the menu.  The telephony team may have instead preferred that Exchange looks at the first diversion header and transfer to the 777-777-7777 user’s voicemail.

How Do You Change It?

Within Exchange, there is no method to alter this.  With most session border controllers or IP gateways, such as Sonus, AudioCodes, etc, you do have options.  Some of these come in the form of checkboxes, sometimes you’re working with SIP message manipulations.   Armed with this understanding and your own SIP trace files, you should be able to work with your gateway or PBX vendor to find a solution.  I have intentionally left instructions to manipulate the SIP messages in various systems out of the article as a misstep can cause disaster for a production systems, please work with your vendor for more specific help.

 

Create your Skype QoS Settings with PowerShell

For those out there using Group Policy on your Lync or Skype for Business servers to configure QoS, I wanted to make sure you’re aware of a method to set your QoS markings via quick and easy PowerShell commands using Net-NewQoSPolicy.  This PowerShell command is available in Windows Server 2012 R2 and up, which you’ll see most new deployments using, and Windows 8.1 and up, which isn’t always rolled out completely in an organization.

Elan Shudnow created his authoritative QoS blogs a while back, which I live by and we will be referencing today.  The 2013 versions are here:

Because I highly recommend the reading of these articles, and I reference them regularly myself, we will be using the same ports the Elan uses in his articles within our PowerShell commands.  Specifically, that means using the following non-default ranges:

  • Modifying application sharing from the default range of 49152-65535, which overlaps with audio and video ports, to the more unique range 40803-49151.
  • Modifying client ports from the default of any high port 1024-65535 to the following:
    • Client Audio Ports: 20000-20039
    • Client Video Ports: 20040-20079
    • Client App Sharing Ports: 20080-20119
    • Client File Transfer Ports: 20120-20159
    • Client Media Ports: 20160-20199

To set these values, the following two commands should be run from the Lync or Skype for Business Management Shell:

Set-CsConferenceServer -Identity <Front End Pool FQDN> -AppSharingPortStart 40803 -AppSharingPortCount 8348

Set-CsConferencingConfiguration -ClientAudioPort 20000 -ClientAudioPortRange 40 -ClientVideoPort 20040 -ClientVideoPortRange 40 -ClientAppSharingPort 20080 -ClientAppSharingPortRange 40 -ClientFileTransferPort 20120 -ClientFileTransferPortRange 40 -ClientMediaPort 20160 -ClientMediaPortRange 40

Also, we’re going to set our DSCP markings using the following tags:

  • Audio = DSCP 46 (EF)
  • Video = DSCP 34 (AF41)
  • All Else = No tag, best effort

Now, on to the fun part, setting our DSCP values via PowerShell.   On each Front End server, run the following commands:

New-NetQosPolicy -Name “Skype Conferencing Audio” -IPProtocol Both -IPSrcPortStart 49152 -IPSrcPortEnd 57500 -DSCPValue 46

New-NetQosPolicy -Name “Skype Conferencing Video” -IPProtocol Both -IPSrcPortStart 57501 -IPSrcPortEnd 65535 -DSCPValue 34

SkypeConf

On a Mediation Server, we’re only concerned with audio traffic and we can pin it down to the Mediation service specifically.

New-NetQosPolicy -Name “Skype Mediation” -AppPathName “MediationServerSvc.exe” -IPProtocol Both -IPSrcPortStart 49152 -IPSrcPortEnd 57500 -DSCPValue 46

SkypeMed

Quick and easy, no MMC or policy!  Drop it in with your prerequisites.  If you have many many servers, an AD level group policy may still save you time however, so use your own judgement.

If you have a mix of operating systems in the environment, I would still suggest using group policy for these as only Windows 8.1 and up support this command.  However, if you do happen to have a PowerShell workstation provisioning script, here are the commands you would need and a screenshot of them being executed on Windows 10:

New-NetQosPolicy -Name “Skype Client Audio” -AppPathName “lync.exe” -IPProtocol Both -IPSrcPortStart 20000 -IPSrcPortEnd 20039 -DSCPValue 46

New-NetQosPolicy -Name “Skype Client Video” -AppPathName “lync.exe” -IPProtocol Both -IPSrcPortStart 20040 -IPSrcPortEnd 20079 -DSCPValue 34

SkypeClient

 

One final note before I leave you, if you receive an “New-NetQosPolicy : Access to a CIM resource was not available to the client.” error, make sure you’re running your PowerShell as administrator, we are making a machine-wide change after all.

 

 

Please Don’t In-Place Upgrade Your Lync OS

I felt the need to blog about this quickly as it’s a question that’s coming up very frequently on the TechNet forums as firms are looking to perform an in-place upgrade of Lync Server 2013 to Skype for Business Server 2015.  Many have deployed Lync on Windows Server 2008 R2, and they’d like to move to Skype for Business Server on Windows 2012 R2.  Many want this simply because they want a more recent operating system.  Further confusion arises from the TechNet article found here: https://technet.microsoft.com/en-us/library/Dn951388.aspx.  Many read that Windows 2008 R2 is not listed as a supported operating system and stop reading.  There is a further note that says:

You may have noticed Windows Server 2008 R2 isn’t on this list. That’s because we recommend Windows Server 2012 R2 for all new servers to be used for SFB. You should only be using Windows Server 2008 R2 when you have existing servers with Lync Server 2013 already installed, and you’re intending to do an in-place upgrade of them.

If you fall into this category, in hopes that you find it in your research, this blog is simply here to say DON’T DO IT!  If you want to move to Windows 2012 R2 as part of your upgrade, please build fresh servers and move your users and objects over.  Not only is this a supported upgrade path, there’s less downtime and potentially less risk as you can test and pilot all features before moving objects.  In-place upgrades of the OS are unsupported and have been well known to break Lync.  If you want some more evidence beyond my random blog, some of the comments in Doug’s blog post (two pages of comments) are a fun read:

http://blogs.technet.com/b/dodeitte/archive/2013/10/25/lync-server-2013-now-supported-on-windows-server-2012-r2.aspx#pi75101=1

Nosign

Issue: Skype for Business Client Will Not Perform Transfer

This one was brought up on the TechNet forums by Igor Kravchenko and others.  MVP Richard Brynteson (masteringlync.com and lyncvalidator.com) has brought it to Microsoft’s attention previously, so they are aware of the issue though I haven’t seen any word on when or if it will be fixed.

The issue itself is when transferring a call with the Skype for Business UI, if you search for a contact, right click, and try to choose the number or voicemail you’d like, nothing happens.  You’re still stuck in the transfer window.  This has left plenty of users confused and frustrated.

Figure 1: Wrong Way

Broken

There is however a proper way to perform the transfer and is another great example of why user training and enablement is so critical.  If you hover over or right click the contact’s picture, you’ll see a phone icon.  Clicking the phone icon gives you the same menu, however this time it’s functional.

Figure 2: Right Way

Working

Hopefully that help if you were confused.  If you’re an admin who has or is considering switching to the SkypeUI interface, it’s worth your time to make sure your users are aware of this quirk before they struggle.

 

New Virtual Skype for Business Users Group Starting August 3rd

I wanted to take a moment to help promote a new Skype for Business user’s group, and this one is open to everyone regardless of location.

Skype for Business MVPs Dustin Hannifin, Randy Wintle, and Adam Jacobs are starting up a brand new online only users group at SkypeVUG.org.  The kickoff meeting is on August 3rd at 9:00am Pacific (Microsoft) time and Microsoft’s own Jamie Stark will be presenting.  The event will be held via a Skype Broadcast Meeting, is scheduled to run about two hours, and you can easily register by going to the above link.

I reached out to the team to get a few more details:

  • Q) How often will the users group meet?
  • Dustin) As of right now we are planning once per quarter but of attendance is high we may try once per month.
  • Q) Who all is responsible for the running the group?
  • Dustin) Adam, Randy, and myself are getting things off the ground but I’m a user group purest in that I believe a user group is run by its members.  We will be asking for and needing additional help once we get things off the ground.
  • Q) Will there be vendor participation similar to in-person user’s groups?
  • Dustin) Vendors are always welcome. Our meetings have minimal cost.   We’re still working through when we might want paying sponsors.  The goal is to keep the focus on education and not sales pitches, but we also know that vendors are critical to the community and will always be welcome at our meetings.

Additionally, the site has an forum area where you can suggest and comment on topics you’d like to see discussed.

Finally, if you’re in an area that is served by an in-person user’s group and you’re wondering which to attend, I would suggest both!  In-person groups are invaluable for the social aspect and interaction as well as the ability to ask direct questions.   At the same time, the SkypeVUG group content is not aligned with any local group, offering distinct information and a fresh perspective.

If you haven’t stopped reading to join already, please go register at the link below.

SkypeVUG.org

Reminder: Quarterly Lync User Groups

This is your quarterly reminder that the US Lync Users Groups are coming up.

These are always fun and valuable, and a great place to network with your peers and make those relationships.  Vendors and local experts attend regularly as well so it’s a place to get those questions answered too!

Head over to lyncusersgroup.com and find your group on www.meetup.com.

  • July 15th – Los Angeles, CA
  • July 23rd – Chicago, IL
  • July 28th – Cincinnati, OH
  • July 28th – Nashville, TN
  • July 28th – Philadelphia, PA
  • July 30th – Silicon Valley, CA
  • August 4th – Atlanta, GA
  • August 6th – Charlotte, NC
  • August 10th – Milwaukee, WI
  • August 13th – Kansas City, MO
  • August 18th – Detroit, MI
  • August 25th- Portland, OR
  • August 27th – Baltimore, MD
  • August 27th- Boise, ID
  • August TBA – San Francisco, CA
  • August TBA- New York, NY
  • September 1st- Seattle, WA