Modern Public Folders: Part 1

Over the past decade of working with dozen of Exchange environments, I can say that Public Folders are that one part of Exchange that most admins wish weren’t there. Some of you newer admins or have had the benefit of being in an environment where Public Folders were underutilized likely can’t relate with these feelings. But those of us who have been working in these older environments have a hierarchy with hundred- of-thousands of folders.

Legacy Public Folders

Long ago, probably before most people in the Internet were born, Public Folders were meant to fill a gap that allowed groups to share data and information. Remember this is long before Google Drive, SharePoint and the other dozens of collaborative tools that didn’t exist.

Exchange 2010 and prior, Public Folders where hosted on their own separate unique databases. However, the databases weren’t clustered. Instead public folders where synced accrossed databases using PF replication. So the advantage to this method is that you can choose which folders are replicated to which databases. If you wanted to geo-locate data, you could force data to specific databases/servers.

The Cloud Killed Legacy Public Folders

Around the time of Exchange 2007 and 2010, there where rumors spreading about Microsoft killing off Public Folders. Why? Well there was a time that Microsoft was encouraging organizations to move their Public Folder infrastructures to SharePoint. When Microsoft realized that organizations weren’t adopting this strategy they were faced with an issue. See Microsoft wanted to encourage people to start using it’s new cloud based Exchange environments, but it didn’t want to bring Legacy Public Folders to the cloud.

Modern Public Folders

So out of necessity the Modern Public Folders where created started in Exchange 2013. So what is different?

There are no longer any Public Folder Databases.

That’s right, no Public Folder Databases. So where do my public folders go? Well Microsoft decided to create something called a Public Folder Mailbox. These mailboxes can be hosted on regular mailbox databases. Which means, the data can now be protected through Database Availability Groups.

There are two kinds of Public folder mailboxes, Primary and Secondary Hierarchy Mailboxes. There is one and only one Primary Hirearchy Mailbox. The purpose of this mailbox is to maintain the only writable copy of the Public Folder structure and permissions. Every other Public Folder Mailbox is a Secondary  Mailbox. These maintain read-only copies of the hierarchy.

Watch for the next post for strategies on working with large Modern Public Folders.

PF Permissions

To be honest, I’ve never been a big fan of Public Folders (PFs). Actually, now that I think of it, I’ve never met an Exchange Administrator who doesn’t have a distaste for PFs. However, they are one of those things that many older and larger organizations started to used a long time ago, when it was one of the only choices for collaboration.

One of the nuances of PFs is permissions. When a Root (\) folder is created, typically us admins will setup the permissions for clients. At that point any new child item of folder inherits the permission of it’s parent folder. This works great, until you get into organizations where there can be hundreds of thousands of folders that make a giant mess.

Additionally, when you add PF permissions, the permissions do not get propagated to child folders. Of course you can use the EWS interface, however for very large trees, you will see the command timeout.

So to address this issue I made the below script. The intention of it is to set the permission on a public folder and all child directories. It is built to allow for multiple users and PF branches. This will look at the trees provided and get a list of all of the child public folders. Then it will check if the user already has permissions on the folder, and if so remove the current permissions. Why is this? Well a user can’t have more than on permission on a folder. So any attempt to add the desired permission will produce an error. So instead I strip out the current permission and then replace it with the desired permission.

Enjoy! Download

<#
.SYNOPSIS
Set the PF permissions on all children Public Folders
.DESCRIPTION

.PARAMETER PFrOOT
The path to the ROOT file that you want to set permission. This attrubte accepts multiple paths.
.PARAMETER Users
Provide the list of user
.EXAMPLE
C:\PS> .\Set-PFClientPermissions.ps1 -PFRoot ".\Folder" -Users "User1", "user2" -Perm PublishingEditor

.NOTES
Author: Joshua Wortz
Date: octover 12th, 2016
#>
paramaters(
[array]$PFRoot,
[array]$users,
[string]$Perm
)


$pfs = $pfroot | %{Get-PublicFolder $_ -Recurse}

foreach ($pf in $pfs)
{
foreach ($user in $users)
{

if (Get-PublicFolderClientPermission -User $user -Identity $pf.Identity -ErrorAction:SilentlyContinue)
{
Get-PublicFolderClientPermission -User $user -Identity $pf.Identity | Remove-PublicFolderClientPermission -Confirm:$false

}

Add-PublicFolderClientPermission -Identity $pf.Identity -AccessRights $Perm -User $user -ErrorAction:Stop

}
}

Clean-Logs

For those of us who have been administering Windows web based servers know that one feature that IIS is known for is not rolling over its logs. Many admins have left logging off when not needing to debug or troubleshoot to work around this. In many enterprise environments, it’s import to maintain these logs to review for security issues.

So I initially created this script to trim the IIS logs on exchange servers. it will search for the exchange servers on your environment and remotely query IIS to locate the log directories. After which it will delete any logs older than the configured amount of days.

When Exchange 2013 came out, I updated the script to also truncate the Exchange logs, since Exchange 2013 was created with a large amount of logging, that again doesn’t truncate. The script will also locate the Exchange log files and truncate those logs as well.

Finally at the end, the script will send an email report of all files deleted from each server for record keeping. Follow the link below to download.

Download


&lt;#
.SYNOPSIS
Used to trim IIS logs on Exchange 2013 servers
.DESCRIPTION
Because of the increased level of logging in Exchange 2013 I developed this script
to locate and truncate log files over a certain day length.
This script will find log files in the Default IIS logging location
and in the Exchange installation location
.NOTES
File Name : Clean-Logs.ps1
Author : Joshua Wortz (v1.0)
Prerequisite : PowerShell V2 over Vista and upper.
Versoion History : v1.0 23rd May 2015 : First Edition

#&gt;
param([switch]$Exchange)

$From = "From@domain.com"
$To = "To@domain.com"
$SMTPServer = "SMTPServer"

$days=30 #You can change the number of days here
#$IISLogPath ="C:\inetpub\logs"

Write-Host "Removing IIS and Exchange logs; keeping last" $days "days"

function Out-FileForce {
PARAM($path)
PROCESS
{
if(Test-Path $path)
{
Out-File -inputObject $_ -append -filepath $path
}
else
{
new-item -force -path $path -value $_ -type file
}
}
}

#Locating and Removing old Logs
Function CleanLogfiles($TargetFolder, $Server)
{
$targetfolder = $targetfolder -replace "%SystemDrive%", "c:"
$TargetServerFolder = "\\$($Server)\" + $TargetFolder.split(':')[0] + "$" + $TargetFolder.split(':')[1]
Write-Host $TargetServerFolder
if (Test-Path $TargetServerFolder) {
$Now = Get-Date
$LastWrite = $Now.AddDays(-$days)
$Files = Get-ChildItem $TargetServerFolder -Include *.log,*.blg -Recurse | Where {$_.LastWriteTime -le "$LastWrite"}

$files | Remove-Item -ErrorAction SilentlyContinue | out-null

$colItems = $files | Measure-Object -property length -sum

[string]$sum = "{0:N2}" -f ($colItems.sum / 1MB) + " MB"

$sum

}
Else {
Write-Host "The folder $TargetServerFolder doesn't exist! Check the folder path!" -ForegroundColor "red"
}

}
#gets the name of the Ex2015 servers
Function Get-ExchangeServerInDomain {

$configNC=([ADSI]"LDAP://RootDse").configurationNamingContext
$search = new-object DirectoryServices.DirectorySearcher([ADSI]"LDAP://$configNC")
$objectClass = "objectClass=msExchExchangeServer"
$serialNumber = "serialNumber=Version 15.*"
$name = "name=DC*"#modify if naming schema is different
$search.Filter = "(&amp;($objectClass)($serialNumber)($name))"
$search.PageSize=1000
[void] $search.PropertiesToLoad.Add("name")
[void] $search.PropertiesToLoad.Add("serialNumber")
$search.FindAll() | %{$_.Properties.name[0]}

}
[string]$Body = $null

#Gets list of Servers
[array]$Servers = Get-ExchangeServerInDomain

foreach ($Server In $Servers) {
[array]$logs = $null

#Queries IIS for log paths for Each IIS Site on Server
$IISLogPaths = Invoke-Command -ComputerName ($Server) -ScriptBlock {get-website | %{$_.logfile.Directory}}
$Body += "&lt;H1&gt;$Server&lt;/H1&gt;"
#Delete log files from each IIS path
foreach ($Path in $IISLogPaths)
{

$logs += $path | select @{N="Path";e={$_}}, @{N="Size Deleted";e={$( CleanLogfiles -TargetFolder $Path -server $Server)}}

}

if($Exchange -eq $true)
{
#Get Path of Exchange Installation on remote server
$objReg = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey('LocalMachine', $Server)
$objRegKey= $objReg.OpenSubKey("SOFTWARE\\Microsoft\\ExchangeServer\\v15\\Setup\\")
[array]$ExchangeLoggingPath = $objRegkey.GetValue("MSiInstallPath") + "Logging\"
$exchangeloggingpath += "D:\Exchange\Logs"

$logs += $exchangeloggingpath | select @{N="Path";e={$_}}, @{N="Size Deleted";e={$(CleanLogfiles -TargetFolder $_ -server $Server)}}

$body += $logs | convertto-html -fragment
}

}

$head = @'
&lt;style&gt;
body { background-color:#dddddd;
font-family:Tahoma;
font-size:12pt; }
td, th { border:1px solid black;
border-collapse:collapse; }
th { color:white;
background-color:black; }
table, tr, td, th { padding: 2px; margin: 0px }
table { margin-left:50px; }
&lt;/style&gt;
'@

[string]$html = convertto-html -Head $head -Body $body #| Out-File $reportFile -Force

Send-MailMessage -SmtpServer $SMTPServer -To $to -From $From -Body $html -Subject "IIS Logs Deleted" -BodyAsHtml

Exchange PowerShell Scripts

Earlier this week Exchange team had a new blog post about some of their favorite PowerShell Scripts for Exchange and Office 365 Admins. While they have a few good suggestions, there are a few more that I’ve found most helpful when working with Exchange.

Generate Health Report for an Exchange Server 2016/2013/2010 Environment

By Paul Cunningham
Download Link

This script is one of my personal favorites and I’ve used it for years in several environments. It does an amazing job of scanning your Exchange organization and reporting back with an easy for follow color coded HTML page that you can have emailed to you. I’ve used this as a daily health check of the environment before the workday begins, and also as a snapshot of the current system health by running it in a scheduled task and having the report outputted to a static HTML page, which can be displayed in a public monitoring space.

Exchange Server Performance Health Checker Script

By Marc Nivens
Download Link

The Health Checker script was created by a Microsoft employee as what I can only assume was a large amount of support calls about server performance that was tied to improper system configuration. So this script is ran against your Exchange servers and verifies that your system is configured to match the Exchange 2013 Sizing and Configuration Recommendations along with several patches and recommendations that have come later.   Below is a list of a few of the items it verifies.

  • OS Version
  • Page File Size
  • Server Role
  • Power Settings
  • Checking if Hyper Threading is enabled
  • .Net version

 I’ve found this script to be particularly helpful before bringing new or rebuilt servers into production as well as to verify that no .Net updates have not sneaked onto the server or that a new critical update isn’t missed. This script is growing and always being updated so be sure to check for updates before running.

If you know of any additional scripts that have been helpful to you as an Exchange administrator, please post them in a comment.

New Skype for Business Room Systems “Project Rigel”

One of the great things that came from #MSIgnite was the announcement of the next Lync Room Systems (aka Project Rigel). As a Skype4B admin who has done integration with current generation Lync Room Systems and Polycom infrastructures, I have to say that Microsoft has made huge steps forward.

The idea of a Lync Room System was great, however the initial execution from the first generation systems was lacking a cohesive professional polish. Earlier versions of the Lync Room Systems where built around non-standardized hardware that each vendor (Polycom, Crestron, and SMART) customized with a non-vanilla client software based on an SDK provided by Microsoft. All of these pieces made for a management nightmare, while delivering a sub-par user experience at an exorbitant price point.

However, after seeing and using these myself, I am actually excited about these new room systems and let me explain why.

20160929_120009.jpg
Image of “Project Rigel” room system from Logitech.

Hardware

All of these systems are based around the Surface Pro 4! That’s right, the image above is an actual computer and not a dumb terminal like most flat screens with room systems. There is no need to have an equipment cabinet to hold the computing component of the room system. This is the core of all of the new room systems, the current vendors (Logitech, Crestron, and Polycom) have taken the Surface Pro 4 and built a standard dock, which contains the power, HDMI and other connectors. Additionally, the vendor is able to build various packages with peripherals, such as cameras, and audio devices that cater to the various size meeting rooms.

Software

Microsoft has created a new Skype for Business application that has been hidden on the Microsoft store and is only available to devices that have been licensed to use them. This means that we can’t just go buy a bunch of Surfaces and create our own room system. However, the major advantage is that now all of the room systems, regardless of vendor, will be using the same Skype software and deliver the same controls and experience to users.

Price

Because of the flexibility with these devices being packaged with different audio and video equipment based on the needs of specific rooms, the price point varies. However, it was announced that small sized room systems will have a starting price point of about $1,200. Medium to large size rooms can reach upward of $5,000. This is still a significate reduction in cost compared to current Lync rooms systems  that sell for around $10,000.

Conclusion

At this time, Logitech is set to the first hardware vendor to release the room system and Crestron and Polycom are following shortly behind. If you would like to know more I recommend that you want the Ignite session on Project Rigel or read the links below from the vendors. There is many details about the systems, and you can see a live demonstration.

Links

Logitech Press Release
Logitech Blog Post
Polycom Press Release
Crestron Press Release

 

 

 

 

 

HTTP Redirection for Exchange

 

If you’ve ever installed Exchange 2010 or 2013, you can probably recall that first time you tried visiting OWA, and there it is the 403.4 error. Of course that small moment of panic sets in because you’re certain there were no errors with the install. Then after a few minutes of scouring the internet, you finally realize that you’re not crazy because this is by designed!

aaeaaqaaaaaaaarzaaaajddkmjmwnjizltnkndmtndawmc1hytcxlta0zmqxy2zjzdizma

While I understand that the last thing we want is to expose our user’s login information over an HTTP connection, from a usability perspective it’s frustrating for users to have to remember to type https:// when trying to get to OWA. We can resolve this by going to the default site and disabling the require SSL and setting up a redirection. However,thanks to inheritance, you’ve just unknowingly disabled the requirement for SSL across the entire default site. Now we need to go to each of the various folders and enable the SSL requirement, but make sure that the PowerShell folder isn’t enabled or you’ll break the Exchange management shell.

After all of that, we still need to setup the redirect so that when people navigate to http://mail.domain.com they get redirected to https://mail.domain.com/owa.

So 30 minuets later I’ve fixed one of my Exchange servers, awesome! I got tired of going through this routine, so I cooked up a PowerShell script that will do the work for you. Hopefully you’ll find it useful as well!

https://gallery.technet.microsoft.com/scriptcenter/Setup-CAS-II-b326b2ed