-->

Saturday, April 14, 2018

Exchange Bulk Create Dynamic Distribution Lists From CSV

Last year I migrated our company from Notes to Exchange 2016, and just recently found out that we're "missing" several Dynamic Distribution Lists...by several I mean 53.
So, instead of doing that all by hand, I thought building a CSV with that info sure would be handy!
I'll show you how to create multiple DDLs from a CSV, using PowerShell.


We're going to create a CSV with all the necessary information to automatically create these DDLs, and we'll be using the AD Custom Attribute 15 for the Location Codes for each group.
Since most DDLs are built by location or OU, that will be the scope of this post. Feel free to leave a comment if you need some other filterable properties.


**Note** We use Attribute15 in my environment to specify the location code (because we run a Resource Forest which syncs over from the Accounts forest), but you can change that to whatever attribute you use...for instance you can choose "ConditionalStateOrProvince" to use the State attribute.
Just change the "Attribute15" column heading to "State" in your CSV.

Create the CSV

Now, we'll create a CSV file in the following format:

Dynamic Distro CSV

In the example CSV, we'll use the following locations (which are populated for my users within CustomAttribute15 in AD):

NYC (New York)
CHI (Chicago)
DAL (Dallas)
BOS (Boston)


The CSV will specify the following:

Name - DDL Display Name

Alias - DDL Alias

OU - The Organizational Unit where the DDLs will be created e.g. "domain.com/DistributionLists"

Attribute15 - CustomAttribute15 (where the location code is stored)

Recip (RecipientTypes) - "MailboxUsers, MailContacts, MailUsers"

Email (PrimarySMTP) - The primary email address of each DDL e.g "LocAllUsers@domain.com"

Container (RecipientContainer) - Where the DDL will query AD to pull the members from e.g. "OU=Users,DC=domain,DC=com"

Now, save the CSV somewhere like: c:\temp\newdlls.csv

Create the Dynamic Distribution Groups

Once you have your CSV built and saved, run the following cmdlet in the EMS (Exchange Management Shell):

Import-CSV "C:\temp\newddl.csv" | % {New-DynamicDistributionGroup -Name $_.Name -OrganizationalUnit $_.OU -ConditionalCustomAttribute15 $_.Attribute15 -IncludedRecipients $_.Recip -PrimarySmtpAddress $_.Email -RecipientContainer $_.Container}

The cmdlet will call each heading in the CSV, and pipe in the values you have specified for each group.

**Note** If you're using something other than Attribute15 like "State" for instance, in the above cmdlet, change the "-ConditionalCustomAttribute15" switch to "-ConditionalStateOrProvince $_.State" which will then match your CSV heading.

**Note** Depending on how many DDLs you're creating and how large your environment is, this could take a while - meaning the Shell might sit there and "do nothing" for a bit.

Once the cmdlet is finished, you'll see the new DDLs in your "domain.com/DistributionLists" OU, and they'll be populated from the Recipient Container we specified  (OU=Users,DC=domain,DC=com).

All done!

To get a membership report and see that our filters work, you can grab a script I wrote in this post, which will output a nice and pretty HTM file for ya!

Sunday, April 8, 2018

Exchange Reconnecting An Orphaned Linked Mailbox

Here's a "fun" scenario: Exchange is installed in a Resource Forest. A user's AD account in the Accounts Forest was deleted by our SAP automated system (I dunno why does it has so much control), which orphaned the Linked Mailbox because now there's no master account to attach to.

The mailbox isn't listed in the EAC:

EAC Missing Mailbox

And the recipient can't be found:

Get-Recipient sarah.one@exchangeitup.com

The operation couldn't be performed because object 'sarah.one@exchangeitup.com' couldn't be found on 'DC1.exchangeitup.com'.

Running the Get-MailboxStatistics cmdlet, shows that it does exist...but floating around in the ether maybe?

You can see that the mailbox isn't disconnected, but it's also not attached to an account:

Get-MailboxDatabase | Get-MailboxStatistics | Where { $_.DisplayName -eq "sarah one" } | fl DisplayName,Database,DisconnectReason

DisplayName               : Sarah One
Database                       : DB01
DisconnectReason        :

Reconnecting the Mailbox:

Resurrect the Account:

First, we'll need to de-tombstone the AD account in the Accounts forest, then do the same in the Resource Forest.

**Note** You'll need to have the AD Recycle Bin enabled...hopefully you already do. Otherwise, you'll need to create a new account for the user...that's painful.

Connect the Linked Mailbox:

Next, we'll connect the orphaned mailbox to the restored/new AD account. Fire up the EMS (Exchange Management Shell) and run the following:

$cred - Get-Credential

**Note** Passing creds is only required depending on your Trust setup. Once you run the above cmdlet you will input your Accounts Forest admin credentials.

Next, run:

Get-MailboxDatabase DB01 | Get-MailboxStatistics | where ($_.displayname -eq "Sarah One" } | Connect-Mailbox -Alias "SarahOne" -LinkedMasterAccount "exchitup.com\SarahOne" -LinkedDomainController "DC.exchitup.com" -Database DB01 -LinkedCredential $cred

**Note** Change "DB01", displayname, -Alias, -LinkedMasterAccount, -LinkedDomainController, and -Database to match your environment

And, done!

Check the EAC and you'll see the mailbox is alive.

Connecting a User Mailbox:

UserMailboxes don't tend to be "orphaned" very often when a user account is deleted, they just get disconnected.

But just to cover our bases, in case it does happen, the following cmdlet will get it back working.

After you restore the deleted AD account, run the following cmdlet:

Get-MailboxDatabase -Identity "D01"  | Get-MailboxStatistics | Where { $_.Displayname -eq "Sarah One" } | Connect-Mailbox -User "sarahone"

**Note** Again, change "D01", displayname, and -User

Your user should be happy...now fix whatever deleted your accounts!

Saturday, April 7, 2018

Exchange Set Resource Mailbox Calendaring Back To Defaults

If you follow my blog, you know that my company does some wacky (stupid) things with Resource Mailbox booking settings. They want calendars to function like Notes (which I migrated them over to Exchange from) and instead of letting Exchange manage calendars, we end up changing things that don't follow best or even sane practice.
Most of the time, they end up asking me to revert those settings. The problem is: I've changed so many settings over the months, I can't remember every thing that I was asked to set.
It'd be nice if there was a Set-RoomBackToDefault cmdlet, but there's not. So I cooked up a quick-and-dirty script that will set all settings on a Resource Mailbox back to default. This will save you time from deleting and re-creating the Mailbox!

Here's some settings that I've been asked to set. This is just an example, but it sets the Room to allow me (the delegate) to book without requiring myself to accept/decline my own meetings, but requires all other users to book through me; allows conflicts; allows the subject; and allows text in the body (comments).

Set-Calendarprocessing "test room" -AllowConflicts $true -DeleteComments $false -AddOrganizerToSubject $false -DeleteSubject $false -AllBookInPolicy $false -AllRequestOutOfPolicy $false -AllRequestInPolicy $true -BookInPolicy "stacey branham" -ResourceDelegates "Stacey Branham"

Get-CalendarProcessing "test room" | fl

AutomateProcessing                            : AutoAccept
AllowConflicts                                     : True
BookingWindowInDays                      : 180
MaximumDurationInMinutes              : 1440
AllowRecurringMeetings                     : True
EnforceSchedulingHorizon                  : True
ScheduleOnlyDuringWorkHours         : False
ConflictPercentageAllowed                  : 0
MaximumConflictInstances                  : 0
ForwardRequestsToDelegates               : True
DeleteAttachments                                 : True
DeleteComments                                    : False
RemovePrivateProperty                         : True
DeleteSubject                                         : False
AddOrganizerToSubject                        : False
DeleteNonCalendarItems                       : True
TentativePendingApproval                    : True
EnableResponseDetails                          : True
OrganizerInfo                                         : True
ResourceDelegates                                 : {exchangeitup.com/Users/staceybranham}
RequestOutOfPolicy                              : {}
AllRequestOutOfPolicy                         : False
BookInPolicy                                          : {/o=exchangeitup/ou=Exchange Administrative Group
(FYDIBOHF23SPDLT)/cn=Recipients/cn=026f8db5e35544e082e8c123cf9c190f- staceybranham}
AllBookInPolicy                                    : False
RequestInPolicy                                     : {}
AllRequestInPolicy                                : True
AddAdditionalResponse                        : False
AdditionalResponse                               :
RemoveOldMeetingMessages               : True
AddNewRequestsTentatively                : True
ProcessExternalMeetingMessages         : False
RemoveForwardedMeetingNotifications : False
ObjectState                                              : Changed


I created the following script to ask you to provide a Resource Mailbox name (this way you don't have to edit the script itself every time you run it), then it will run against that Resource Mailbox and set all settings to default according to this MS TechNet Article.
This basically saves you from typing all the switches mentioned in the above article, manually ;)

You can grab the script from my Google Drive here

-or-

Copy and paste the following block into Notepad, and save as Set-Calendar-Defaults.ps1

$name = Read-host "Enter a Resource Mailbox Name"
Set-CalendarProcessing -Identity $name -AddAdditionalResponse $false -AddNewRequestsTentatively $true -AddOrganizerToSubject $true -AllBookInPolicy $true -AllowConflicts $false -AllowRecurringMeetings $true -AllRequestInPolicy $false -AllRequestOutOfPolicy $false -AutomateProcessing AutoAccept -BookingWindowInDays 180  -BookInPolicy $null -ConflictPercentageAllowed 0 -DeleteAttachments $true -DeleteComments $true -DeleteNonCalendarItems $true -DeleteSubject $true -EnableResponseDetails $true -EnforceSchedulingHorizon $true -ForwardRequestsToDelegates $true -MaximumConflictInstances 0 -MaximumDurationInMinutes 1440  -OrganizerInfo $true -ProcessExternalMeetingMessages $false -RemoveForwardedMeetingNotifications $false -RemoveOldMeetingMessages $true -RemovePrivateProperty $true -RequestInPolicy $null -RequestOutOfPolicy $null -ResourceDelegates $null -ScheduleOnlyDuringWorkHours $false -TentativePendingApproval $true; Get-CalendarProcessing -Identity $name | FL


Once you have the .ps1 saved, fire up the Exchange Management Shell (EMS) and run Set-Calendar-Defaults.ps1

You will prompted to input a Resource Mailbox:

EMS Set Calendar Defaults

Enter the mailbox name (it doesn't need quotes around it) and the script will fire off.

After the script sets the defaults, it will then automatically run the Get-CalendarProcessing cmdlet on the mailbox you ran the script against to show that the revert-to-default was successful:

AutomateProcessing                         : AutoAccept
AllowConflicts                                  : False
BookingWindowInDays                    : 180
MaximumDurationInMinutes            : 1440
AllowRecurringMeetings                   : True
EnforceSchedulingHorizon                : True
ScheduleOnlyDuringWorkHours       : False
ConflictPercentageAllowed                : 0
MaximumConflictInstances                : 0
ForwardRequestsToDelegates             : True
DeleteAttachments                              : True
DeleteComments                                 : True
RemovePrivateProperty                       : True
DeleteSubject                                       : True
AddOrganizerToSubject                      : True
DeleteNonCalendarItems                     : True
TentativePendingApproval                  : True
EnableResponseDetails                        : True
OrganizerInfo                                       : True
ResourceDelegates                               : {}
RequestOutOfPolicy                            : {}
AllRequestOutOfPolicy                       : False
BookInPolicy                                       : {}
AllBookInPolicy                                  : True
RequestInPolicy                                   : {}
AllRequestInPolicy                              : False
AddAdditionalResponse                      : False
AdditionalResponse                             :
RemoveOldMeetingMessages             : True
AddNewRequestsTentatively              : True
ProcessExternalMeetingMessages      : False
RemoveForwardedMeetingNotifications : False
ObjectState                                          : Changed


Now, all settings are back to the way they were when you first created the mailbox; and surprise surprise, it works pretty well out-of-the-box...tell your users that!

Saturday, March 17, 2018

Exchange Resource Mailbox Exclude Delegates From Accepting/Denying Their Own Meetings

When you have a Resource Mailbox set to require Delegates to manage meetings, the default setting is that meetings from all users must be accepted/rejected by Delegates. Even the Delegates' own meetings. This is counterintuitive, since of course the Delegate would know when the Resource is free or busy. The default settings should exclude the Delegates, but we can't have everything we ask for, can we Microsoft?

In order to exclude the Delegates from accepting/denying their own meeting requests, we need to manually change the BookInPolicy on the mailbox; in Exchange 2013/2016 it must be done in PowerShell...there's no option to change it in the EAC.

The requirements for the Resource Mailbox to allow Delegates to book automatically, but require all other users to book with approval are as follows:

All Book In Policy: False

All Request Out of Policy: False

All Request In Policy: True

Book in Policy: One or More Users/Group Defined

Resource Delegates: One or More Delegates Defined

Fire up the Exchange Management Shell (EMS) and run the following cmdlet to set the above options:

Set-CalendarProcessing "Conference Room HR" -BookInPolicy "receptionist@exchangeitup.com","assistant@exchangeitup.com" -AllBookInPolicy $False -AllRequestOutOfPolicy $False -AllRequestInPolicy $True

**Note** Change "Conference Room HR" to the name of your Resource Mailbox, and "receptionist@exchangeitup.com","assistant@exchangeitup.com" to the email addresses of your Delegates.

**Note** I'm assuming you already have Resource Delegates set on the Mailbox, but if you need to add those as well, just include -ResourceDelegates "receptionist@exchangeitup.com","assistant@exchangeitup.com" in your cmdlet

What this cmdlet does is sets the Resource policies listed above, and adds your Delegates to the "BookInPolicy" list.
You can use a Distribution Group if you have multiple Delegates you want to set; you would just use the DL's email address in place of the Delegates' addresses like so: -BookInPolicy "roommanagersDL@exchangitup.com" -ResourceDelegates "roommanagersDL@exchangeitup.com"

To the check that the settings have been applied to the Resource Mailbox, run:

Get-CalendarProcessing "Conference Room HR" | FL AllBook*,AllReq*,BookInPol*,Request*,Resource*

You'll get the following output:

AllBookInPolicy               : False
AllRequestOutOfPolicy    : False
AllRequestInPolicy           : True
BookInPolicy                    : {/o=exchangeitup/ou=Exchange Administrative Group
                                  (FYDIBOHF23SPDLT)/cn=Recipients/cn=91bb55ebc2a64cb4844b31c470833308-                                           receptionist,
                                          /o=exchangeitup/ou=Exchange Administrative Group
                               (FYDIBOHF23SPDLT)/cn=Recipients/cn=f3ac6e3f538d47f19da77d79b6f7a407-                                          assistant}
RequestOutOfPolicy        : {}
RequestInPolicy               : {}
ResourceDelegates           : {exchangeitup.com/Mailboxes/assistant,

                                          exchangeitup.com/Mailboxes/receptionist}

In the above output, you can see that your Delegates are now listed in the "BookInPolicy" in LegacyDN format.

Now to test, have one your Delegates schedule a meeting in that Room and see that the request will automatically be accepted or denied based on availability and they don't get the request itself forwarded to their mailbox.

You should have happy Delegates now that they don't get tons of requests coming in...I usually advise organizations to always use automatically booking because it saves a lot of work for both the Exchange admin and the delegates, and 99% of the time I end up being told to switch the rooms back to auto-booking when the delegates get tired of managing so many requests...maybe they should listen to me in the first place.

Sunday, March 4, 2018

Exchange Automatically Enable OWA For New Mailboxes

My Exchange 2016 resides in a Resource Forest in the US and I share an Accounts Forest with our EU parent company who also has an Exchange 2016 Resource Forest. We use the same mailbox provisioning script for both Exchange environments, which simplifies the creation process, but I don't run the same configuration as they do in Europe so I have to change a bunch of settings...like enabling OWA for all users.

I'll show you how to set a scheduled task to enable OWA on all new mailboxes so we don't have to do it manually.

Create a Service Account:

First, you'll want to create a Service Account in your domain, which will be used to run the scheduled task. It's best practice to use service accounts rather than your own account to run scheduled tasks, so if you ever leave your position and they deactivate your account, it won't break the task!

In your domain, create a new user called something like exchscriptaccount and set a super-strong password.

This account will need to be a member of the Server Management Role Group, otherwise it won't have permissions to enable OWA on mailboxes.

Next, add the newly created user to the Local Administrators Group on your Exchange Management Tools server or Exchange server if your running it from there. The scheduled task will need local admin rights to run PowerShell things, and since you have a super strong password, it's not an issue.

Creating The Task:

On your Exchange Management Server or an Exchange Server, open the Task Scheduler Control Panel, click Action > Create Task...

On the General tab:

Give it a name like Enable OWA

Click "Change User or Group..." hit "Locations" and switch to your domain, then search for your exchscriptaccount service account.

Check the box for "Run with highest privileges"

On the Triggers Tab:

Click "New..."

Set it for how often you need it to run. I run mine Daily at 12AM - no specific reason, but you do want it to run Daily depending on your onboarding turnover.

On the Actions Tab:

Set the "Action" dropdown to "Start a program"

Under Program/Script, copy/paste the following:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

In the "Add arguments" field, copy/paste the following:

-NonInteractive -WindowStyle Hidden -command ". 'C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; Get-CASMailbox -ResultSize unlimited | ? {$_.OWAEnabled -eq $False} | Set-CASMAilbox -OWAEnabled $True"

**Note** What this cmdlet does is finds any mailbox with OWA disabled ($False), and sets the flag to $True (enabled)

In the Settings Tab:

Checkmark the following boxes:

- Allow task to be run on demand

- Stop the task if it runs longer than: 1 hour (if it runs longer than an hour, you got something wrong!)

- If the running task does not end when requested, force it to stop

Click OK when you have everything set.

Testing the Task:

In the main task window, right-click your new "Enable OWA" task, and click Run.

When it finishes running, you should have a (0x1) Last Run Result.

Check Our Work:

Check that OWA is set on All Mailboxes by running:

Get-CASMailbox -ResultSize unlimited | ? {$_.OWAEnabled -eq $False}

The output should be empty.

Now, Exchange will do the boring job of turning on OWA for you :)

Saturday, March 3, 2018

SFB Client Error: You Don't Permissions Needed to Access File System

I recently had a user complain that they couldn't get their SFB client to sign-in...what's funny is we've been running SFB for over a year and they've never been able to use it.

When attempting to sign in, the following error is thrown:

Skype For Business can't sign in. You might not have the permissions needed for Skype For Business to access the Windows file system, or there might be a problem with your installation of Office.

SFB Permission Error

The user can sign in on another machine, so it's definitely something wrong with this particular client and not their account.

The Problem:

After some digging, I checked the following path on the user's machine:

"%localappdata%/Microsoft/"

The "Office" folder didn't exist, which explains why there's a permission problem...can't have perms on a non-existent folder.

The Fix:

Completely close the SFB Client and Outlook

Copy the "%localappdata%/microsoft/office" folder from a working machine to the problem machine.

Start SFB and Outlook

Now the user should be able to sign-in!

Saturday, February 10, 2018

Exchange Enabling Mailbox Auditing Scheduled Task - Part 3

In my previous post, I showed that mailbox auditing takes up very little storage space. In this post, I'll show you how to create a Scheduled Task to enable auditing on newly created mailboxes...we don't wanna do that manually every time we enable mailbox, right?

Create a Service Account:

First, you'll want to create a Service Account in your domain, which will be used to run the scheduled task. It's best practice to use service accounts rather than your own account to run scheduled tasks, so if you ever leave your position and they deactivate your account, it won't break the task!

In your domain, create a new user called something like exchscriptaccount and set a super-strong password.

This account will need to be a member of the Records Management Role Group, otherwise it won't have permissions to enable auditing on mailboxes.

Next, add the newly created user to the Local Administrators Group on your Exchange Management Tools server or Exchange server if your running it from there. The scheduled task will need local admin rights to run PowerShell things, and since you have a super strong password, it's not an issue.

Creating The Task:

On your Exchange Management Server or an Exchange Server, open the Task Scheduler Control Panel, click Action > Create Task...

On the General tab:

Give it a name like Set Shared Mailbox Auditing

Click "Change User or Group..." hit "Locations" and switch to your domain, then search for your exchscriptaccount service account.

Check the box for "Run with highest privileges"

On the Triggers Tab:

Click "New..."

Set it for how often you need it to run. I run mine Daily at 12AM - no specific reason, but you do want it to run Daily.

On the Actions Tab:


Set the "Action" dropdown to "Start a program"

Under Program/Script, copy/paste the following:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

In the "Add arguments" field, copy/paste the following:

-NonInteractive -WindowStyle Hidden -command ". 'C:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; Get-Mailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited | ? {$_.AuditEnabled -eq $False} | Set-Mailbox -AuditEnabled $True -AuditOwner SoftDelete, HardDelete"

**Note** You can create one Schedule Task to enable auditing on all mailboxes, or create separate tasks by specifying the Mailbox Type like I have above...it depends on your mailbox creation rate.
To set for mailbox type just change the "-RecipientTypeDetails SharedMailbox" to another mailbox type like "-RecipientTypeDetails UserMailbox"

In the Settings Tab:

Checkmark the following boxes:

- Allow task to be run on demand

- Stop the task if it runs longer than: 1 hour (if it runs longer than an hour, you got something wrong!)

- If the running task does not end when requested, force it to stop

Click OK when you have everything set.

Testing the Task:

In the main task window, right-click your new "Set Shared Mailbox Auditing" task, and click Run.

When it finishes running, you should have a (0x1) Last Run Result.

Check Our Work:

Check that auditing is set on All Shared Mailboxes by running:

Get-Mailbox -Filter {AuditEnabled -eq $false -and recipienttypedetails -eq "sharedmailbox"}

The output should be empty.

Now run:

Get-Mailbox -Filter {AuditEnabled -eq $true -and recipienttypedetails -eq "sharedmailbox"}

The list should show all Shared Mailboxes

Now, Exchange will do the boring job of applying auditing for you :)

Exchange Enabling Mailbox Auditing Storage Consumption - Part 2

In my previous post I showed you how enable mailbox auditing by mailbox type. Some Exchange admins are wary of enabling auditing for all mailboxes because of storage space concerns. But, the good news is: even on a huge mailbox with lots of activity, the space consumed is miniscule.

From my experience, Mailbox Auditing adds less than 1% of mailbox size. Which means it's totally safe to enable it on all mailboxes in your organization. Plus, disks are cheap...just add more!

The following mailbox is 91GB (why she has a mailbox that gargantuan I don't know. At that point, I bet she can't even find what she's looking for).

As you can see, the Audits folder size is very little, and I have the "-AuditOwner SoftDelete, HardDelete" options set on her mailbox.

Get-Mailbox "Christiane G" | Get-MailboxFolderStatistics -FolderScope RecoveraleItems | fl name,foldersize

Name       : Recoverable Items
FolderSize : 0 B (0 bytes)


Name       : Audits
FolderSize : 143.94 KB (44,994 bytes)


Name       : Calendar Logging
FolderSize : 3.678 MB (3,856,561 bytes)


Name       : Deletions
FolderSize : 273.4 MB (286,645,304 bytes)


Name       : Purges
FolderSize : 0 B (0 bytes)


Name       : Versions
FolderSize : 0 B (0 bytes)


**Note** If you don't see an Audits folder right away, it just means that the owner/admin/delegate hasn't done anything according to your -AuditOwner/Admin/Delegate settings in the mailbox yet. Give it time and once some modification happens, it will create that folder

So, auditing won't kill your Database storage, go ahead an enable it and make your life easier!

In the next post, I'll show you how to create a scheduled task to automatically enable auditing on newly created mailboxes.

Exchange Enabling Mailbox Auditing By Mailbox Type - Part 1

I enable mailbox auditing on all mailboxes in every Exchange environment I work on. Why? Because WHO MOVED MY CHEESE?!.
Actually it makes the exchange admin's life so much easier when dealing with users who come crying that "all my emails are gone!" Another reason, is 90% of the time the messages can be found in Recover Deleted Items, and my personal policy is to never restore Single Items from a backup; you deleted it...tough luck :)


In this 3 part series, I'll show you how to enable Mailbox Auditing by mailbox type; how much storage auditing actually consumes; and how to create a scheduled task to automagically set auditing when new mailboxes are created.

To enable auditing by mailbox type run the one or all of the following cmdlets:

User Mailboxes

Get-Mailbox -ResultSize Unlimited -Filter{RecipientTypeDetails -eq "UserMailbox"} | Set-Mailbox -AuditEnabled$true -AuditOwner SoftDelete,HardDelete

Linked Mailboxes

Get-Mailbox -ResultSize Unlimited -Filter{RecipientTypeDetails -eq "LinkedMailbox"} | Set-Mailbox -AuditEnabled$true -AuditOwner SoftDelete,HardDelete

Shared Mailboxes

Get-Mailbox -ResultSize Unlimited -Filter{RecipientTypeDetails -eq "SharedMailbox"} | Set-Mailbox -AuditEnabled$true -AuditOwner SoftDelete,HardDelete

Room Mailboxes

Get-Mailbox -ResultSize Unlimited -Filter{RecipientTypeDetails -eq "RoomMailbox"} | Set-Mailbox -AuditEnabled$true -AuditOwner SoftDelete,HardDelete

Equipment Mailboxes

Get-Mailbox -ResultSize Unlimited -Filter{RecipientTypeDetails -eq "EquipmentMailbox"} | Set-Mailbox -AuditEnabled$true -AuditOwner SoftDelete,HardDelete

**Note** We only specifically set the -AuditOwner options, because the following settings for AuditAdmin and AuditDelegate are already set by default:
Create, Folder Access, Hard/Soft Delete, Move/Move to Deleted, Send on Behalf, and Update

The auditing options can be found here so you can see what you want to set.

To enable auditing on all mailboxes in the environment, run:

Get-Mailbox -ResultSize Unlimited | Set-Mailbox -AuditEnabled $true

**Note** This cmdlet will take quite a while depending on how many mailboxes you have. Which is why I usually use the cmdlets above to apply by mailbox type.

Now, you have auditing enabled on all mailboxes or the types you want. In the next post I'll show examples of the storage used by auditing...teaser: it's not as much as you think ;)

Sunday, January 21, 2018

Skype For Business Convert CsUser to CSMeetingRoom

In a previous post, I went over converting a Room Mailbox to a Linked Mailbox. During the Linked Room account conversion in the Exchange Resource Forest, we had already set up the Skype For Business account as a regular CsUser account in our Accounts Forest. I needed that CsUser account to be a SFB Meeting Room account.

**Note** While a standard SFB user account can be used for a meeting room, an actual Meeting Room account will give you more control over the conferencing device. From my experience, it also affects the presence of the contact...a standard user will show "offline" unless in a meeting.

So, I needed a quick way to convert that CsUser to a CsMeetingRoom without having to delete and re-create the account.

Luckily PowerShell makes it easy!

On your SFB server, fire up the SFB Management Shell and run the following:

Get-CsUser "bld 51 conference room b" | Enable-CsMeetingRoom -SipAddress "sip:confrmb@exchangeitup.com" -RegistrarPool pool1.exchitup.com

**Note** Change "bld 51 conference room b", "sip:confrmb@exchangeitup.com", and pool1.exchitup.com to match your environment.

To check that it works, run:

Get-CsMeetingRoom | fl name,sipaddress,registrarpool

And you'll get the following:

Name                    : Bld 51 Conference Room B
SipAddress           : sip:confrmb@exchangeitup.com
RegistrarPool       : pool1.exchitup.com


You'll also note that the user can no longer be seen in the SFB Control Panel, because Meeting Rooms can only be managed with the SFB Shell.

Now the presence should work correctly and you can book that room and have it join your conferences!

Saturday, January 20, 2018

Exchange Convert Room Mailbox to Linked Mailbox

I'm in the process of setting up Skype For Business Meeting Rooms and the issue is: my Exchange 2016 environment is installed in a Resource Forest, and SFB is located in the Accounts Forest.

This means we need Linked Mailboxes for the Rooms in order for the conferencing devices to login to SFB.

I already have tons of Room Mailboxes created in Exchange, and I really didn't want to delete and re-create those. So, I needed to be able to convert them to Linked Room Mailboxes.

According to MS TechNet, you have to disconnect the mailbox, and then create a linked account and connect the mailbox. That isn't required; you can convert directly with the following steps.

Create an AD account in the Accounts Forest.

Next, enable the new AD account as a SFB Meeting Room

Fire up the SFB Management Shell and run:

Enable-CsMeetingRoom -Identity "Bld51ConferenceRoomB" -SipAddress "sip:Bld51ConferenceRoomB@exchangeitup.com" -RegistrarPool "pool1.exchitup.com"

**Note** Change the Identity, SipAddress, and Pool to match your environment

DirSync the new account to the Resource Forest with MIM or whatever sync app you use - or you can copy all proxy addresses (SIP and SMTP) over manually

In the Resource forest, fire up the EMS (Exchange Management Shell) and run:

$cred = Get-Credential

Enter your Accounts forest admin creds

Next, run:

Set-User "Bld51ConferenceRoomB" -LinkedMasterAccount "exchitup.com\Bld51ConferenceRoomB" -LinkedDomainController dc1.exchitup.com -LinkedCredential $cred

**Note** Again, change the values to match your environment

To check that it worked, run:

Get-Mailbox "Bld 51 Conference Room B" | fl name,alias,recipienttypedetails

You'll get the following output:

Name                               : Bld51ConferenceRoomB
Alias                                : Bld51ConferenceRoomB
RecipientTypeDetails      : LinkedRoomMailbox


Or check the EAC:

EAC - Linked Room Mailbox

You'll see that you now have a "Linked Room" mailbox. Now users can schedule that conference room for more boring meetings ;)