Skype for Business Online Conferencing Policies: Part Deux

Boris Karloff in Lab

In a previous post, I described how to apply a conferencing policy to an O365 account’s Skype for Business audio/video settings.

I also pointed towards this Technet article, which provides some additional information about these policies.

Reviewing this material however, I noticed that Technet entries (at least, the ones I’ve found so far) don’t go into a lot of detail about what each of these policies includes and excludes.  In other words, how do you know what you’re turning on and off when using the Grant-CsConferencingPolicy cmdlet to modify an account?

The answer, is that you have to do a bit of research within your tenant.

First, you need to learn what conferencing policies can be applied to users within your tenant.

Here’s the syntax:

Get-CsConferencingPolicy -ApplicableTo user.name@yourdomain.com

The -ApplicableTo switch returns information about what conferencing policies can be activated for the user specified (and it’s a good bet that the same policies can be applied to others within your tenant).

For example:

 

Identity: Tag:BposSAllModality

AllowIPAudio: True
AllowIPVideo: True
AllowMultiView: True
Description:
AllowParticipantControl: True
AllowAnnotations: True
DisablePowerPointAnnotations: False
AllowUserToScheduleMeetingsWithAppSharing: True
AllowNonEnterpriseVoiceUsersToDialOut: False
AllowAnonymousUsersToDialOut: True
AllowAnonymousParticipantsInMeetings: True
AllowFederatedParticipantJoinAsSameEnterprise: False
AllowExternalUsersToSaveContent: True
AllowExternalUserControl: True
AllowExternalUsersToRecordMeeting: False
AllowPolls: True
AllowSharedNotes: True
AllowQandA: True
AllowOfficeContent: True
EnableDialInConferencing: False
EnableAppDesktopSharing: Desktop
AllowConferenceRecording: True
EnableP2PRecording: True
EnableFileTransfer: True
EnableP2PFileTransfer: True
EnableP2PVideo: True
AllowLargeMeetings: False
EnableOnlineMeetingPromptForLyncResources: False
EnableDataCollaboration: True
MaxVideoConferenceResolution: VGA
MaxMeetingSize: 250
AudioBitRateKb: 200
VideoBitRateKb: 50000
AppSharingBitRateKb: 50000
FileTransferBitRateKb: 50000
TotalReceiveVideoBitRateKb: 50000
EnableMultiViewJoin: True
CloudRecordingServiceSupport: Supported

This reveals what Skype conferencing elements are enabled within the BposSAllModality policy (as the name suggests, it’s “all”).

You can also obtain this information by using the simple cmdlet (without referencing a user):

Get-CsConferencingPolicy

By examining the properties of each conferencing policy, you can learn what makes sense for your environment.

Skype for Business Online: Modifying User A/V Status via PowerShell

outer-limits

Recently I experienced a bit of trouble modifying users’ Skype for Business audio/video properties using the Office 365 web admin GUI.

For example, when trying to save a user’s modified A/V settings (in this case, enabling audio and video), I encountered the following:

Skype for Business Admin Error

Notice the “Sorry, but we couldn’t save your changes…“error message.  This is a bug within the tenant (being addressed by Microsoft as I type this – details about that in a future post).

Needless to say, this is a job for PowerShell.

If you’re familiar with the Skype for Business PowerShell module (and if you’re not, it’s detailed here) you might be inclined to solve this problem by using the following syntax:

Set-CsUser –Identity <User> -AudioVideoDisabled <True|False>

It certainly seems straightforward enough but, TechNet articles notwithstanding, the actual way to accomplish this is by applying a conferencing policy to a user.

Here’s a listing of the conferencing policies I’m familiar with:

Tag:BposSAllModality
Tag:BposSDataProtectionMinVideoBW
Tag:BposSAllModalityMinVideoBW
Tag:BposSAllModalityNoFTMinVideoBW
Tag:BposSAllModalityNoRecMinVideoBW
Tag:BposSDataProtectionNoDialoutMinVideoBW
Tag:BposSAllModalityNoDialoutMinVideoBW
Tag:BposSAllModalityNoFTNoDialoutMinVideoBW
Tag:BposSAllModalityNoRecNoDialoutMinVideoBW

And again, you can learn more about what these mean by going here.

So let’s say you want to enable audio and video conferencing (i.e., Skype call) for the user Clever Boots.

You can change his settings by using the following syntax:

Grant-CsConferencingPolicy -PolicyName Tag:YourPolicyNameHere -Identity clever.boots@thatdomain.com

You’ve no doubt noticed that you can plug one of the conferencing policies listed above (as appropriate) into the string to enable features for Mr. Boots.

Office 365: Discovering “Lost” Mail Using PowerShell

cortez-montezuma-mexico-city

 

If you work in a field long enough, you acquire so much information, you can forget the things you know; or knew.

Consider the following as an example.

The other day, I received a frantic message: a senior executive couldn’t locate email from years ago; emails considered critical (it’s impossible to know whether or not the emails were actually all that important but, as the saying goes, perception becomes reality).

I was certain the emails were within the user’s mailbox (most likely  within the online archive) but overlooked.  How could I help him find them?

The answer: discovery mailboxes.

Interestingly, although I’d worked quite a bit with email discovery using on-premise Exchange 2010 and 2013, under a bit of pressure, that memory slipped from my mind like water through fingers; I found myself wondering how to accomplish this in Office 365.

Fortunately, the same PowerShell syntax applied.

The steps were simple.

I:

1.) Created a discovery mailbox

2.) Granted full access rights to the users who needed to search the mailbox for the “missing” emails.

3.) Un-hid the discovery mailbox from the global address list (because, by default, the mailbox is hidden).

4.) Ran a PowerShell script to search for the mysterious email (by subject) and copy the results into a target folder within the discovery mailbox.

5.) Provided directions to the user(s) explaining how to attach to the discovery mailbox via OWA and search for the emails they need

The PowerShell syntax was simple:

Create the mailbox:

New-Mailbox -Name YourMailboxName -Discovery

Grant a user full access to the mailbox:

Add-MailboxPermission Seach-MailboxName-SearchResults -User user.name@your-office365-domain.com  -AccessRights FullAccess -InheritanceType all

Un-hide from the Global Address List:

Set-Mailbox -Identity “YourMailboxName” -HiddenFromAddressListsEnabled $false

Search according to your criteria and copy the results into a folder in the discovery mailbox:

Get-Mailbox –ResultSize Unlimited -Identity source.mailbox@uour-office365domain.com  | Search-Mailbox -TargetMailbox YourMailboxName -TargetFolder “SearchResults” -SearchQuery {Subject:”Your Target Search”}

Note that searchquery is a switch option of the PowerShell cmdlet Search-Maibox.  You can see more search options here at TechNet.

Oh, and also note that the result is typically a folder structure that, at the parent level, will be very similar to \SearchResults\User-Name-date/time and that the child folders will reflect the source(s) of the mail (i.e., “Inbox”, “Archive”, etc).

So, for example, a search of my mailbox for messages containing the word “Burrito” in the subject heading (and assuming I named the -TargetFolder “Burrito-Hunt”) would be in:

\Burrito-Hunt\Monroe, Roberto\june 8, 9:00 am\

And under that parent folder you might find \Inbox, \Calendar, \Online Archive and so on. These are mirrors of the source folders from which the query extracted email meeting the search criteria.

Note that you can also search using a date range. For example:

Get-Mailbox –ResultSize Unlimited -Identity user.name@your-domain.com  | Search-Mailbox -TargetMailbox Search-MailboxName -TargetFolder “SearchResults” -SearchQuery {received:01/01/2013..12/31/2013}

 

Using PowerShell to Remove Specific Emails

dickpowellinmurder

Email is at the heart of business communications and so, it shouldn’t come as a surprise when you’re called upon to perform a variety of tasks above and beyond simply keeping messages flowing.

For example, removing emails which, for whatever reason, are considered targets for deletion.

Using PowerShell, it’s possible (on both Office 365 and on-premise Exchange) to remove messages by using a modified application of the search-mailbox cmdlet.

So, to find a message within a user’s mailbox by subject heading, you can issue the following:

Get-Mailbox -Identity firstname.lastname@mheducation.com | Search-Mailbox -SearchQuery ‘Subject:”your subject”‘ -EstimateResultOnly

And to remove the message found via your search you simply add the -DeleteContent switch:

Get-Mailbox -Identity firstname.lastname@mheducation.com | Search-Mailbox -SearchQuery ‘Subject:”your subject”‘ -DeleteContent

Note that to perform the basic search, you need the discovery management role and to delete items you need the mailbox import-export role.

Of course, your search parameters aren’t limited to subject line alone but can include date, keywords within a message, target folder and more.

Remote Access to Office 365 Via Powershell

bogart-maltese-falcon
In an on-premise Exchange environment, your PowerShell connection to the server is essentially a remote session (even though it occurs within your Kerberos-enclosed domain).  In an Exchange 2010 environment the EMC (when installed on a Windows desktop) obscures this relationship but it’s there nonetheless.

It’s no different when you connect to Office 365 for PowerShell administration (which is, as I’ve stated before, the best and most powerful way to manage your Exchange tenant).

The how-to is basic and covered well by Microsoft here and at Tom’s IT Pro here.

Briefly, the syntax is very simple:

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Set-ExecutionPolicy RemoteSigned
Import-PSSession $Session

In which, an object named $UserCredential is created that employs the get-credential cmdlet to gather your, well, credentials and passes that to Office365’s web service (for PowerShell).

The session data is imported so the cmdlet set appropriate for Office365 is imported.  This includes familiar tools such as get-mailbox.

When finished, you end your session by invoking Remove-session $Session which cleans up your PowerShell threads of execution (preventing orphaned sessions).

 

O365 and OWA: Room Listing Display Limitations

Modern-times-lego

 

Although quite versatile and feature-rich, Exchange Online does have certain limits that distinguish it from on-premise Exchange.

For example, if you’re accustomed to booking rooms via OWA hosted from an on-premise Exchange organization, you expect to see a list of all available rooms.

In Exchange Online however, there’s a default system setting (which, as of this writing can’t be changed) that limits the number of rooms displayed to 100.  In large enterprises, this can cause some user frustration.

One work-around is to use the scheduling assistant to search for the room you want.  This is helpful, but may not satisfy all users’ needs.

Another method – which I consider to be more elegant – is to create room lists.

Room lists organize room resources into a specific type of distribution group that contains, well, rooms.

This is obviously very useful for large, geographically distributed firms that have many locations and far more than 100 bookable rooms.

So for example, to create a room list for all bookable rooms in the New York office you could issue the following PowerShell command (when connected to your tenant via a remote PowerShell session):

New-DistributionGroup -Name “New York Meeting Rooms” -RoomList

And to add rooms to this room list you’d use the following cmdlet:

Add-DistributionGroupMember -Identity “New York Meeting Rooms” -Member room120

Of course, some amount of planning and thought is needed to organize your rooms into these groups so your users can make sense of it all.  But once you’ve done that background work, room lists will make life much easier for people who access Exchange exclusively through OWA.

Retention Tags and Policies – a quick how to

Poster - Out of the Past (1947)_03

Retention tags determine the actions of retention policies and therefore must be created before their corresponding policies

From TechNet:

Retention tags are used to apply retention settings to folders and individual items such as messages, notes, and contacts. These settings specify how long a message remains in the mailbox and the action to take when the message reaches the specified retention age. When a message reaches its retention age, it’s moved to the archive mailbox, deleted, or flagged for user attention.”

[…]

Using the EMC…here’s a quick example of how to make a tag and apply it to a policy.

(BTW, our example assumes that users have been granted the “my retention policies” role assignment as described in this TechNet article).

Let’s say a user who has recently been assigned an archive mailbox wants a retention policy that will move mail items to their online archive after 15 days.

From within the EMC, go to Organization Configuration  –> Mailbox

One

From the Action section on the right, choose New Retention Policy Tag

Two

  • In the  Tag Name field, enter the name of the Tag (it should describe the tag’s time period, for ex. “15 Days to Archive””
  • In the Tag Type field, use the drop-down to set what kind of tag this is (i.e., applied to a specific folder only or available to be used on any folder within a user’s mailbox). In our example, we’re using the Personal Tag type
  • In the Age limit field, choose the amount of time – in days – that elapse before the tag/policy goes into action.  In our example, it will be 15 days
  • In the Action to take when the age limit is reached field, use the drop-down to choose what action the tag/policy will take when the age limit has been reached.
  • Note the Disable this tag button – this allows you to deactivate a tag without deleting it (for troubleshooting purposes, for example)
  • The comments field is optional

Three

Click New to proceed.

Four

Click Finish to complete making the tag.

Next, you’ll apply this tag to a policy.

Again, from Organization –> Mailbox…

Five

Choose New Retention Policy from the Actions menu on the right…

Six

  • In the Name field, enter your policy’s name (it should match that of the tag for simplicity)
  • In the Add tags to the retention policy field, use the Add button to select from the list of available tags

Seven

Eight

Click OK

Nine

Click Next

Ten

Here, you’re presented with the option to apply this policy to a list of mailboxes. We’re not doing this in our example (since we’re making a policy the user can apply her or his self to an Outlook folder) so we can ignore this setting and click Next.

Eleven

Click New

Twelve

Click Finish to complete making the policy

Thirteen

If you look closely, you’ll notice that the Exchange Management Console displays the PowerShell cmdlet syntax used to perform actions via the GUI.

We can do all of the above within the Exchange Management Shell .

Making the retention tag:

New-RetentionPolicyTag -Name ’15 Days to Archive’ -Type ‘Personal’ -Comment ” -AgeLimitForRetention ‘15.00:00:00’ -RetentionAction ‘MoveToArchive’ -RetentionEnabled $true

And then, tying that tag to a retention policy:

New-RetentionPolicy -Name ’15 Days to Archive’ -RetentionPolicyTagLinks ’15 Days to Archive’

 

Get Mailbox and Mailbox Database Stats Using Powershell

peter o'toole - lawrence of arabia 1962

While it’s possible to gather some information about mailbox database contents using the Exchange Management console (by, for example, using the filtration options found under Recipient Configuration) more comprehensive information can found by using PowerShell.

From within the Exchange Management Shell, you can view the mailbox databases in your org by using the following command:

Get-MailboxDatabase

And, you can view the mailboxes within a particular database by combining shell commands:

Get-MailboxDatabase “Your Mailbox Database name” | Get-Mailbox

We can further modify this syntax to create reports; for example:

Get-MailboxDatabase “Your Mailbox Database name” | Get-MailboxStatistics | Sort totalitemsize -desc | ft displayname, totalitemsize, itemcount

Also,  we can examine the stats for a specific mailbox in detail:

Get-MailboxStatistics -identity “Username” | fl


	

Setting a Database Activation Preference

forbidden-planet (1)

Recently, I had to recreate one of my DAGs (a topic I’ll get into another time). At the end of the process, I had to alter the activation preference of the member databases.  Via PowerShell this is easily achieved.

Let’s say, for example, that your DAG has two servers, EXCHSRV01 and EXCHSRV02 and two databases, MBDB01 and MBDB02. To view the current activation preferences for one of the hosted databases you can issue the following command from an Exchange Management Shell window:

Get-MailboxDatabase “MBDB01″|fl server, databaseCopies, activationPreference

The output will be similar to this:

Server: EXCHSRV01
DatabaseCopies: {MBDB01\EXCHSRV01, MBDB01\EXCHSRV02}
ActivationPreference: {[EXCHSRV02, 1], [EXCHSRV01, 2]}

In this scenario, I’d like to change the activation preference so that MBDB01\EXCHSRV01 is the primary DAG database\host.  To do this I issue the following cmdlet and switch combination:

Set-MailboxDatabaseCopy -identity ‘MBDB01\EXCHSRV01’ -ActivationPreference 1

To confirm, simply re-use: Get-MailboxDatabase “MBDB01″|fl server, databaseCopies, activationPreference

 

 

Useful Powershell Commands for Managing Roles

Here are some very helpful commands for handling RBAC issues I learned at Mike Pfeiffer’s blog.

changing_husbands092

Can this user modify this object?

This can be really helpful when you are troubleshooting permissions. If you need to verify that a member of your staff has write access to an object, use the following command syntax:”

Get-ManagementRoleAssignment -WritableRecipient administrator -GetEffectiveUsers | ?{$_.EffectiveUserName -eq “Mike Pfeiffer”}

Full at this link

See also this Technet blog link which provides background and design detail.

Excerpt:

RBAC and the principle of least privilege

The principle of least privilege is an important design consideration in enhancing the protection of data and functionality from unintentional and/or malicious behavior.

Exchange Server 2010 aids such implementation of roles by using role-based access control (RBAC). However, in my professional experience, I have noticed that many deployments are not actually thought out to utilize the full potential of what RBAC has to offer. Most often, I see deployments where built-in RBAC roles are utilized and rarely customized to match the actual job roles of administrators. This mostly results in having too much access for the role.

[…]

full here