When Office 365 Groups first launched last year it was a rather underwhelming first stab at combining a lot of functionality which was arguably already in the Microsoft productivity stack, and in pretty much every case, way more refined than Groups.
We’ve seen incremental changes to the Groups feature over the past few months and the messaging seems to point that all roads from Exchange, SharePoint, and Lync/Skype for Business eventually lead to Groups. There is still a long list of control knobs and discovery refinements needed before this is something an enterprise can fully adopt, but there are some use cases which make Groups appealing today.
One of the main motivators for using a social tool like Yammer instead of a traditional distribution list is that it captured the historical content. So the person who starts the day after someone posts a critical message to the entire team actually has access to the previous conversations and content. Groups solves that problem quite well, even if it’s difficult for an administrator to manage that content. But let’s face it – Yammer’s admin features are sorely lacking as well, so if you’re willing to give up tagging and notifications then Groups is a viable alternative.
I wanted to share a few quirks I’ve noticed if you’re headed down this path:
Logo and Image Sizing
The photo you set for the Group logo should be 240×240 pixels. I can’t find this documented anywhere, but that seems to be the size of the example or stock image you’ll see when the group is created. But, OWA and OneDrive for Business show different quality levels for reasons I can’t explain. The first image here is what I see in OWA and the second is the logo in OneDrive for Business when I access the files section, which looks obviously blurry.
If you try to manage the Group within the Azure AD Access Panel you may find that you’re then unable to manage some options back in the OWA interface. For example, I created this Group within OWA as a public group anyone could join. I modified the permissions in Azure AD to require approval. Now – even as the Group owner – I’m unable to revert that setting in OWA and see the Privacy section is grayed out.
Default SMTP Address
Groups default to using your tenant ID as the primary SMTP address. Really smart folks on my team like Keif Machado and Joe Stocker have already beaten this one to death, but let’s just say it’s inconsistent with what anyone would expect when creating a new object. Remember to flip it to an appropriate domain after creation.
It’s getting social, and we’re starting to see even more overlap with Yammer functionality. I can “Like” a message anyone posts and they will receive a notification that I did so. But, that pop-up notification is only visible in OWA, so the Outlook stalwarts will surely suffer from a lack of ego-boosting alerts.
There seems to be some semblance of the presence concept, and perhaps we’re seeing the starting to see these groups becoming a persistent chat room in Skype for Business. When you view the contact card for a group you’ll see the presence indicator on the left side just like any other contact. I’ve seen it change from Available to Away with not much background on why, but it’s obvious that some aspect of the group has presence abilities.
Something that is coming up more and more on Lync projects is the concept of integrating with newer video and collaboration services like Acano or Pexip. It’s very important to understand that the deployment guides from these services request you create a static route from your Lync Front End pools to their MCUs. This in itself is not a red flag, especially since this is how some of the Polycom DMA or Cisco VCS integration has worked in the past.
However, this does pose a problem for organizations looking to leverage split-domain with Lync Online, or more commonly, Exchange Online being leveraged for voicemail while Lync Enterprise Voice remains on-premises. The issue here is that using your primary SIP domain as the Match URI in the static route to these video services prevents the signaling from getting to your federation Edge servers (at least, as of the latest Lync 2013 CUs.) The static routing configuration seems to kick in before the call is ever routed to the Edge, so the concept of the CsHostingProviders and the shared address space is never respected.
Let’s walk through an example:
My primary SIP domain in Lync is @confusedamused.com.
I migrate my mailboxes to O365 and enable the Exchange Online shared address space. My voicemail is hosted in O365.
I want to host large meetings in O365 so I also enable the Lync Online shared address space for hybrid. I have some users homed to O365.
Everything works fine at this point.
I now want to integrate with Acano or Pexip. I create a static route for @confusedamused.com which goes from my Lync FEs to their bridges.
This breaks both Exchange Online voicemail routing and communication to Lync Online users.
The real solution here is to use a different SIP domain for your video routing, which as undesirable as this may be to end users, has arguably been a best practice for a long time. Create the static route matching @video.confusedamused.com, @acano.confusedamused.com, or @pexip.confusedamused.com. Take your pick, or create your own variation. It just needs to be different from the SIP domain you actually assign to Lync users.
This is important to grasp if you’re using Lync Online or Exchange Online today and looking to add video, but probably even more critical from a roadmap standpoint. Exchange Online Unified Messaging is a fairly common use-case today, and Lync Online hybrid is becoming more and more popular. Planning ahead for these scenarios and any potential video integration will help you avoid these issues.
Depending on the role, Lync 2013 servers will have one or two SQL Express instances installed as part of the Lync Deployment Wizard steps. All servers deploy an instance called RTCLOCAL, and Lync Front Ends will also deploy an instance called LYNCLOCAL. Generally, there is no configuration or action required on these instances.
If you were to manually install a SQL Express instance the minimum and maximum memory values are essentially unlimited. Technically, this isn’t a realistic view because SQL Express is actually limited to 1 GB of memory, but it’s important to know the out-of-the-box defaults.
I’ve noticed that the Lync installation wizard actually configures static minimum and maximum values on each instance of both RTCLOCAL and LYNCLOCAL, and these are based on the amount of RAM presented to a server at installation time. You can see an example here, which is from a FE that uses Hyper-V dynamic memory and only had around 2.19 GB RAM available.
The instance will always float between 270 MB and 337 MB of memory, which is quite a bit below SQL Express’s ability to address up to 1 GB. We want both of these instances to always be able to address 1 GB, so this is not ideal!
Each instance uses slightly different defaults, but for the sake of documentation I’ve validated the RTCLOCAL instance will be set to a minimum of 12% and maximum of 15% memory. LYNCLOCAL will be set to a minimum of 6% and maximum of 8% memory.
If the server was installed with a minimal amount of RAM, this could negatively impact the Lync services because the SQL instances won’t enough memory available to function properly. You’ll likely be able to start services, but find they stop after a period of time and log events such as this one:
There is insufficient system memory in resource pool ‘internal’ to run this query.
Cause: The connection to the database might be broken.
It’s fairly obvious that the process needs additional memory, but simply adding memory to the server won’t resolve the issue. The “gotcha” here is if you install Lync with minimal memory for some reason and then bump it up later, Lync’s SQL Express instances won’t actually leverage the memory because of the static max/min values configured at installation time.
You can manually adjust these values within the SQL Express instance, but the Lync process will actually reset your modifications back to these percentages after a period of time.
The permanent fix is to re-run Step 1 and Step 2 in the Lync Deployment Wizard on each machine that had RAM added after the initial installation. This will set the RTCLOCAL and LYNCLOCAL instance max/min memory configuration to the percentages above based on the new amount of installed memory. Now of course, SQL Express still won’t be able to access any more than 1 GB of memory, but this fixes any potential ceiling below that number.
Big thanks to my ExtraTeam colleague, Chris Lehr, for helping track this down.