Teams Focusing Status

I love the new "Focusing" mode in Teams; this came by surprise as the feature was lit up in August 2019 but simply put your status to "Do Not Disturb". I haven't seen an announcement about this, but apparently, there is now a new specific status called "Focusing" which is slightly different from the traditional "Do Not Disturb" status.

Setting this up is currently restricted to using MyAnalytics to subscribe to a "Focus" plan (which there is only one right now). As you may already know, this wouldn't go down well with me; I needed to know how this actually works, and try and have my own plan.

Creating a new meeting invite with the exact same options as the one created by MyAnalytics didn't do the job, so I dived into the underlying meta-data of the meeting invite; and figured out the three pieces of information that Teams looks for to determine if this meeting item is a "Focusing" entry.

• Most importantly, this meeting needs to only have one person "YOU"
• The internal flag "IsDoNotDisturbTime" has to be set to true
• The internal flag "IsBookedFreeBlocks" has to be set to true

To help anyone who wants to set their own schedule, away from MyAnalytics, I have written a little VBA snippet that can be used in outlook after selecting a "focus" meeting that you have created yourself.

Download

v.0.0.2 - 2022.02.28 - ToggleFocusing.vba

Complex IVR Workflow

I recently encountered a use case, where I had to push the Skype for Business RGS Workflows to the limit. While I know there are "paid" software out there that can simplify the task. I thought I would write a script that can do the same thing (with some knowledge of P$).

The script is divided into three sections.

1. The first section of this script is where you can make changes to put the Workflow parameters and customise the script for your environment.
2. The second section is where the fun is; you will need to edit this based on the IVR questions and responses; edit this as you see fit; I have tried to include as much as possible in there.
3. DO NOT EDIT the third section; as this retrieves the Workflow (or creates it); and updates it with the information from the first two sections.

I am looking for feedback; on this script; for now, it will do the job; but do people want to enter the information via a CSV ? JSON ? especially the IVR questions and responses section.

Download

v.0.1 - 2020.05.01 - Update-CsIvrWorkflow.ps1

Office 365 Mailbox Statistics

Ok, I have run into this so many times, I don't think I am the only one that has been having this issue. When you have a tenant with thousands of mailboxes, getting information on the mailboxes using PowerShell will almost certainly timeout in the middle.

To avoid this, I have written a script that will cut the mailboxes up into blocks of 1000 (by default), you can change this via command line. It will then disconnect and re-connect again to help avoid the connection time-out.

Download
v.0.1 - 2017-09-13 - Get-MailboxRecursive.v.0.1.zip

The dreaded DCOM error

This one took weeks from me to figure out, and a little help from our friends at Microsoft. After upgrading a customer's SBA fron 2013 to SfB (and following the correct process):

1. Move users to Front-End
2. Remove SBA from topology
3. Add SBA back into topology with the same name but under the SfB node
4. Re-install SBA software using 2015 image
5. Move users back to SBA

Number five is where the issue happened; the users would not move back with a DCOM error:

Interestingly enough, the error in the event log is even more confusing, talking about RoutingGroup already assigned to a different pool (EventID:32209):

Since this is a weird error, the fix will have to be even more weird; this fix is from MS internal documentation :-) (DISCLAIMER: I take no responsibility for doing this on your own environment)
You will need to run the below command to find the users that have a conflicting routing group ID with the one in the Error message:

(Get-CsPool FE01.contoso.com).Computers | `
    % {Sqlcmd.exe -E -S $_\rtclocal -d rtc -Q `
    "select UserAtHost,* from dbo.RoutingGroupAssignment as rga `
    inner join dbo.ServiceCluster as sc on (sc.ServiceClusterId = rga.ServiceClusterId) `
    inner join dbo.ServiceAssignment as sa on (sa.ServiceTagId = sc.ServiceTagId) `
    inner join dbo.Pool as p on (p.PoolId = sa.UscClusterId) `
    inner join dbo.ResourceDirectory as ResD on (ResD.RoutingGroupId = rga.RoutingGroupId) `
    inner join Resource as Res on (Res.ResourceId = ResD.ResourceId) `
    where rga.RoutingGroupName = '<BAD ROUTING GROUP ID>'" -W -s "," -o $_-dumpuserinRG.csv}

The output file will have several users for that routing group ID that are considered "defective"; you will need to run the next command from the RTC database on ALL FE servers in the pool:

use rtc
go
exec [RtcDeleteResource] 'user@domain.com'
go

Rinse and Repeat ... for all Routing Group IDs that show up in the error message.
Now the move user works !!!