Tuesday, July 14, 2015

Allow managers to view calendars of their direct & indirect reports - Exchange 2013

I was recently given two tasks and thought I'd share what I came up with to help at least one poor soul out there. 

Task 1: Add permissions for each manager in IT to have reviewer permissions to the calendar of their direct and indirect reports.  I also wanted to check membership of a group that already has permissions and skip them. I came up with the following script, with some caveats.

  1. There are probably cleaner ways of accomplishing the task, but it was simple and worked.
  2. This adds permissions, but does not remove permissions if someone changes manager. Since it is just reviewer permission, and we didn't want to mess with permissions anyone else had already granted to their manager, we accepted that risk.
  3. It only goes 5 levels deep.
  4. Someone can get around this by just assigning their manager a permission level of none.
Clearly this isn't full-proof, but to save some time and get some permissions added, it does okay.

The $MGR grabs the users manager to assign the permission. The $MGRMEM grabs the manager's group membership to see if they are in the group I want to exclude.

get-aduser -filter {department -eq "Information Technology"}|Foreach-Object {
$MGR = (get-aduser -Identity $_.SamAccountName -properties *).manager
$MGRMEM = (get-aduser $MGR -properties *).memberof
$MGR2 = (get-aduser $MGR -properties *).manager
$MGRMEM2 = (get-aduser $MGR2 -properties *).memberof
$MGR3 = (get-aduser $MGR2 -properties *).manager
$MGRMEM3 = (get-aduser $MGR3 -properties *).memberof
$MGR4 = (get-aduser $MGR3 -properties *).manager
$MGRMEM4 = (get-aduser $MGR4 -properties *).memberof
$MGR5 = (get-aduser $MGR4 -properties *).manager
$MGRMEM5 = (get-aduser $MGR5 -properties *).memberof
If (!($MGRMEM -like "*CN=CalendarAdminAccess*"))
{
Add-MailboxFolderPermission ${_}:\Calendar -User $MGR -AccessRights Reviewer
}
If (!($MGRMEM2 -like "*CN=CalendarAdminAccess*"))
{
Add-MailboxFolderPermission ${_}:\Calendar -User $MGR2 -AccessRights Reviewer
}
If (!($MGRMEM3 -like "*CN=CalendarAdminAccess*"))
{
Add-MailboxFolderPermission ${_}:\Calendar -User $MGR3 -AccessRights Reviewer
}
If (!($MGRMEM4 -like "*CN=CalendarAdminAccess*"))
{
Add-MailboxFolderPermission ${_}:\Calendar -User $MGR4 -AccessRights Reviewer
}
If (!($MGRMEM5 -like "*CN=CalendarAdminAccess*"))
{
Add-MailboxFolderPermission ${_}:\Calendar -User $MGR5 -AccessRights Reviewer
}
}

Note: The curly brackets are used to enclose the value {_} because the distinguished name is returned and can have spaces in it.

Task 2: A much simpler task, I was asked to create a group and assign permissions so members of the group are granted Reviewer access to all IT Department calendars, regardless of whether they are in their management chain or not.


get-aduser -filter {department -eq "Information Technology1"}|Foreach-object{Add-MailboxFolderPermission ${_}:\Calendar -User ITCalendarAdminAccess -AccessRights Reviewer}

Note: The group should be a Distribution Group, or a mail-enabled Security Group.

This is pretty simple stuff as far as PowerShell goes, so I know I'm not shocking the world or anything. Just wanted to share in case someone finds it of use.

Tuesday, June 9, 2015

Tip: Speed Up Snapshot Based Exchange DAG Backups (Veeam, CommVault, etc.)

I was struggling with performance issues with my Exchange 2013 DAG backups, mainly due to storage contention during the snapshot commit (remove snapshot). We have a node that contains only passive copies that we are using strictly for backup. I first tried to put the node into maintenance mode, which helped a little. I decided to try suspending the database copies during the backup and that made a huge difference.

Time to delete snapshot on passive node:
Normal: 1.5 to 3 hours
Maintenance Mode: 45 minutes to 1 hour
Mailbox Database Copy Suspended: 2-3 minutes!!!

Analysis:  Having a Node of the DAG that only contains passive copies of the databases helps reduce the impact of the backup on production users. Putting that node into maintenance mode prevents log files from being played into the databases, but they are still copied to the VM. Suspending the database copies prevents the logs from even being sent to the node, so there are very few changes during the backup. Since from what I have seen, writes typically impact storage performance in a greater capacity, the backup itself (just reading the data) goes pretty well, then deleting the snapshot (combining the snapshot data back into the main disk), really thrashes the storage. By minimizing changes to the disk during the backup, the snapshot commit has very little to do and goes very quickly.

Note: We use Veeam, and I tested a restore of an Incremental Backup using this method and was able to restore and view and restore emails with the Veeam Explorer for Microsoft Exchange with the database suspended.

I first tried this process manually and after it worked, I created a script to do the suspend and resume. My scripts are running on the Exchange Server itself, but you could certainly do this within the Veeam job under the Advanced Settings, Advanced Tab, then Job Scripts.

StartBackup.ps1
get-mailboxdatabasecopystatus -server passivenode|Suspend-MailboxDatabaseCopy -SuspendComment "Backup" -Confirm:$False

StopBackup.ps1
get-mailboxdatabasecopystatus -server passivenode|Resume-MailboxDatabaseCopy -Confirm:$False

Disclaimer: Attempt at your own risk. While I have tested this and it is working well for me, attempt first in a lab...yeah...like everyone has one of those. At the very minimum, run through your own backup/restore test to make sure it doesn't impact your ability to do the restores you want.

Friday, June 5, 2015

Don't put your NETLOGON share and GPOs at risk...check this ASAP!

A very important Active Directory upgrade is being missed by organizations far and wide. Many aren't even aware it is a step that needs to be taken, others make the assumption that it is just done for them. What I'm talking about is the migration from FRS to DFSR for SYSVOL replication. Last year Microsoft announced that they are removing FRS from Windows Server, but that announcement seemed to be largely ignored.  Here's why this is important:

  1. If you have a domain that has ever been at a Windows Server 2003 Domain Functional Level or prior, then you have used FRS for SYSVOL replication.  This would be the vast majority of domains being used today.
  2. Migrating from FRS to DFSR for SYSVOL replication is not automatic, regardless of whether you upgrade your Domain Controllers or raise your Functional Levels.
  3. FRS is antiquated and unreliable for replication.
  4. If you haven't migrated, FRS is replicating your NETLOGON share (usually filled with login scripts and other miscellaneous items) and all your Group Policy Objects.
I apologize for the ridiculous font and size, but I'm afraid that most people don't understand the necessity in migrating from FRS to DFSR because they don't really understand what is contained within the SYSVOL. Most will know it sounds familiar, but don't realize that NETLOGON and all their GPOs are contained within this folder.  I don't put cheap gas in my Ferrari *cough* Kia. Okay...usually I do, but I don't want FRS replicating stuff in my Active Directory that is so critical.

So please just check and see if you are still on FRS, or have migrated to DFSR.

Note: If you aren't running at least Windows Server 2008 Domain Functional Level, then you are definitely using FRS.

  • On a Domain Controller, Open PowerShell and run "get-addomain|fl Name,DomainMode"
    • You are looking for Windows2008Domain or higher 

  • Next, run "netdom query fsmo" to find your PDC Emulator.

  • On the PDC Emulator DC, run dfsrmig /getglobalstate and dfsrmig /getmigrationstate
    • If you have been migrated, you are looking for a global state of Eliminated

  • If you see a message that the DFSR migration has not initialized, or get global states of Start, Prepared, or Redirected, then you definitely have some work to do.

I highly recommend these two articles as excellent sources of FRS to DFSR migration information.


Tuesday, June 2, 2015

Very cool free AD Replication Status Tool from Microsoft

Not sure how I missed this, but today I stumbled across the Active Directory Replication Status Tool when reading an article by Ned Pyle from Microsoft about FRS to DFSR migrations.

This tool satisfies my top 3 requirements for a utility:

  1. It is free
  2. It has useful information in a clean and easy to use interface
  3. It isn't bloated unnecessarily (12MB post installation!)



There really isn't much to say about the tool, as it is very self-explanatory when you open it. Select Forest, Domain, or Select Targets to specify just a few Domain Controllers.  When you choose Refresh Replication Status, look for the Last Sync Message, Last Successful Sync, and Consecutive Failure Count columns to see how things are doing. You can click Errors Only at the top, and hopefully that will show you an empty screen.

This certainly will not substitute for a good AD Health Check. Neither will this tool fix any issues you find...like...I don't know...someone powers off a Domain Controller they are having problems with and the KCC is like, "What the heck, dude?"

For the "Real men use the command line" crowd, there is nothing this tool does that you can't do yourself with repadmin, powershell, and some time.  You can stroke your red swingline stapler and ignore this blog post.

I do think using screenshots of this tool for documentation purposes could certainly up a SysAdmin's street cred...and who doesn't need that?

Monday, April 6, 2015

Install Exchange Server 2013 Management Tools when there is no DC at your site

Trying to install the Exchange 2013 Management Tools, I kept receiving an error that setup couldn't proceed because "Setup must use a domain controller in the same site as this computer". The log files indicated "Failed [Rule:DomainControllerIsOutOfSite]". I was trying to install these tools onto a computer in a Site that did not have a DC. Using the unattended setup with /DomainController didn't help, as it wasn't that it couldn't find a DC, but there was no DC in my site. Unfortunately for me, sites were setup for SCCM, and some didn't have DCs. Here is how I finally worked around it and installed the Management Tools quickly, with only changes to the PC - no reboot required.

1. Navigated to HKLM\System\CurrentControlSet\Services\Netlogon\Parameters in the Registry Editor.
2. Created a new String Value (REG_SZ), called SiteName, with a value of the Site where the DC was located.
3. Kicked off the installation again, which completed successfully.
4. Deleted the SiteName registry entry after verifying the Management Tools were installed.




Would this work on a full server installation?  Possibly. However, I certainly wouldn't recommend attempting it for anything other than a critical system outage situation.

Thursday, April 2, 2015

Exchange 2013 Suspended Migrations (staging mailboxes for a mass cutover)

I have read a number of articles on using the new-moverequest -SuspendWhenReadyToComplete:$true parameter. I have read a number of places where they are supposed to automatically re-sync every 24 hours. I have not found this to be the case for me, but I'm not sure if others are wrong, or whether there is an issue with my configuration. Either way, I'm glad they don't, because that allows me to force the re-sync on my own.  Here is what I've found to pre-stage the mailbox migrations to do a mass-cutover.

I am creating a batch of move requests with a CSV (with an Alias and Destination Column) and my command looks like this:

Import-CSV C:\Temp\mailboxes.csv|ForEach-Object{New-MoveRequest $_.Alias -TargetDatabase $_.Destination -BatchName "Human Resources" -SuspendWhenReadyToComplete -AllowLargeItems -BadItemLimit 1000 -AcceptLargeDataLoss}

To view the stats:

get-moverequest -BatchName "Human Resources"|get-moverequeststatistics |select percentcomplete,bytestransferred,overallduration,displayname,status,statusdetail,LastUpdateTimestamp,*ItemsTransf*,*stalled* |Out-GridView

To resync:

Get-moverequest -BatchName "IT"|Set-MoveRequest -SuspendWhenReadyToComplete:$true

Get-moverequest -BatchName "IT"|Resume-MoveRequest

The information I read indicated you need to set the SuspendWhenReadyToComplete to false to allow it to complete. I have found this not to be the case. Whenever I run the resume-moverequest, that flag automatically gets set back to false.  That means if you have autosuspended mailboxes and you do a resume-moverequest on them, they will complete UNLESS you set the SuspendWhenReadyToComplete to True first.

I've used these steps to kick off a re-sync of each batch, one a time, to prevent too much load on the server.

Thursday, March 26, 2015

List all Exchange mailbox sizes for all people that report up to a single manager (direct and indirect reports of a manager)

If you track a manager for a user in Active Directory, then you have the ability to report on everyone that reports to a specific person by calling the directReports system only attribute.

get-aduser username -properties directReports | select directReports | fl

However, there are a number of things you can do with this that come in handy.  For me, I was tasked with reporting on how much space was consumed in Exchange mailboxes broken down by Business Unit. Since ultimately each Business Unit had a specific leader, I was able to utilize the directReports attribute to get everyone that reported up to the leader of the BU, then grab all their mailbox sizes.

There is a great post that got me started here: http://www.lazywinadmin.com/2014/10/powershell-who-reports-to-whom-active.html. That was very helpful to get me started with a function to list everyone that reports up to a specific person. I had to do some modifications in order to get what I wanted, but basically I switched to get-user to pipe properly to the get-mailboxstatistics command, then exported everything to a nice looking CSV for easy sorting.

My Version: (note...execute from Exchange Management Shell)

function ADDirectReports
{
param([string]$Identity)
Get-Aduser -Identity $Identity -Properties directreports|
ForEach-Object -Process {
$_.directreports|ForEach-Object -Process{
$MGR = (get-user $PSitem).manager|get-user
Get-User -identity $PSitem|get-mailboxstatistics|select Database,DisplayName,@{label="Total Size (MB)";expression={$_.TotalItemSize.Value.ToMB()}},@{ L = "Manager"; E = {$MGR.DisplayName}}|Export-CSV -Path C:\Temp\Mailboxes.csv -Append -Confirm:$false -NoClobber
ADDirectReports -Identity $PSItem -Recurse
}}}

(Tip for PowerShell Beginners...paste the function into your PowerShell Window...then press enter twice...once you get back to the command prompt, type in ADDirectReports USERNAME and press enter to gather this information for all the reports of a top level manager).



This creates a CSV that looks as follows in Excel: