Category Archives: Uncategorized

Configure ADFS Integration with AWS Management Console


With the proliferation of public cloud, there comes with it questions around how do you manage authentication and identity to these third party systems. AWS is one of the most popular ones, so today we will walk through how to integrate AWS with ADFS. This article will assume you already have a working ADFS server and AWS account setup. We will walk through configuring it so that two sets of users can login, each with a separate role, or set of permissions.

Active Directory Setup

In your AD, lets configure two different AD groups:





ADFS Metadata

Now, we need to download the metadata file from your ADFS server, this is located at https://[YOURADFSSERVER]/federationmetadata/2007-06/federationmetadata.xml

We will need to upload this file into AWS later on.

AWS Configuration

Next, let’s login to our AWS management console and navigate to the Identity and Access Management console. Now, lets go to Identity Providers on the left hand side and select Create Provider



Set the provider type to SAML, a name to identity your provider, and then upload your FederationMetadata.xml file you download from your ADFS server previously.




Select Next -> Create. Now, select the provider you just created, as you will need to copy the provider ARN of the object, as we will need it for our SAML rules later on:



In our example, lets say that our provider ARN is:


Now, we need to configure the roles that our users will get when they log in. We are going to tie our Active Directory groups created earlier to these roles later in the SAML config. Still in the IAM, navigate to Roles -> Create Role

Select SAML 2.0 Federation, from the dropdown select the identity provider you created earlier, and select Allow programmatic and AWS Management Console access:



Select next, and now we are going to select our roles. This first one will be matched to our AWS-FULLADMINS group so we will select AdministratorAccessImage


Now, lets name the role:


Let’s repeat the process but this time creating the role for AWS-DNSADMINS, this time we will find the AmazonRoute53FullAccess role:


Now, for each of the roles you created, select them, and copy the ARN similar to how we did it for the identity provider previously:



Mine map out like this:

AWS-FULLADMINS -> arn:aws:iam::123456789012:role/AWS-FULLADMINS

AWS-DNSADMINS -> arn:aws:iam::123456789012:role/AWS-DNSADMINS

At this point we are done with the AWS config, we are ready to create our relying party trust in ADFS and configure the necessary claim rules.

ADFS Configuration

In ADFS navigate to Relying Party Trust -> Add Relying Party Trust -> Claims AwareImage


Select Import data about… and use the URL



Set the display name to anything you want:



Set your Access Control Policy accordingly:


Select Next -> Finish

If you didn’t have selected to Edit Claim Issuance policy, highlight the Amazon Web Services trust, and select Edit Claim Issuance Policy


Click Add Rule -> Transform an Incoming Claim



Claim Rule Name -> Name ID

Incoming claim type -> Windows account name

Outgoing claim type -> Name ID

Outgoing name ID format -> Persistent Identifier


Next, create another rule -> Send LDAP Attributes as Claims



Claim rule name -> Session Name

Attribute Store -> Active Directory

LDAP Attribute -> User-Principal-Name

Outgoing Claim Type ->



Note the outgoing claim type IS case sensitive.

Now we need to create our rules to map our groups in AD to AWS roles. Here I will deviate from the AWS instructions and do things a little bit differently. I find this easier than the AWS instructions which require the groups and roles names to match and relies on REGEX to link the two inside the SAML language. The downside is that it can require more rules in the Claim Issuance Policy, and requires more steps to setup.

First, we are going to create a temp rule that we will use to build the initial language we need for our rule.

Select Add Rule -> Send Group Membership as a Claim



Name the rule whatever you need, we will delete this after. The only important piece here is to select the users group. For outgoing claim type and value, it does not matter:



Now, select Finish -> Highlight the rule you just created and click Edit -> View Rule LanguageImage

Copy the language here to notepad:



You want to replace this line:

=> issue(Type = "", Value = "admin", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, ValueType = c.ValueType);

with the following:

=> issue(Type = "", Value = "arn:aws:iam::123456789012:saml-provider/Port25Guy,arn:aws:iam::123456789012:role/AWS-FULLADMINS");

You should replace this section:

Value = “arn:aws:iam::123456789012:saml-provider/Port25Guy,arn:aws:iam::123456789012:role/AWS-FULLADMINS”

with the ARN of your Identity Provider and the ARN of your role that you copied from AWS previously.

Now, your complete rule should look like the following:

c:[Type == "", Value == "S-1-5-21-1693000147-1615933772-1549220743-5440", Issuer == "AD AUTHORITY"]
=> issue(Type = "", Value = "arn:aws:iam::123456789012:saml-provider/Port25Guy,arn:aws:iam::123456789012:role/AWS-FULLADMINS");

Essentially the top half of the rule is seeing if your a member of the AD group via SID, and then if you are, sending a claim to AWS that has the identity provider ARN and role ARN in the claim.

Repeat this process for your second AD group and AWS role, generating the custom rule language. Save the language as we will need it right now.

Delete your temp rule, it is no longer needed.

Select Create Rule -> Send Claims Using a Custom Rule



Name the Claim Rule for the appropriate role, then paste in the custom language you created from above:


Repeat the above step for the AWS-DNSADMINS role and AD group:



Your Issuance Transform Rules should look similar to the above:



Testing Access

First, you need to make sure that you have the IDP Initiated Logon page available on ADFS, you can do that with the following powershell command:

Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

Now, go to the following URL:


Select Sign In:



Then select Amazon Web Services



You should get redirected to the AWS console page:



It will list that it is a Federated Login, as well as the identity provider/username as your session name. You are all set!


Logging in without IDP Portal Page:

ADFS has an annoying configuration in that the IDP login page lists anonymously the resources available through that server:



For this reason, many organizations disable this page, in fact Windows Server 2016 disables it by default. However, AWS doesn’t seem to allow any type of SP initiated logon. So are you out of luck? Nope, we just need to use a special URL to do so.

In ADFS, navigate to the AWS relying party trust, go to Properties->Identifiers

Note the relying party identifiers, which in our case is urn:amazon:webservices.

Now use the below URL, obviously entering in your ADFS FQDN:


Notice after the loginToRP= we enter in the identifier we copied from above. After your ADFS server authenticates you, you’ll be automatically logged into the AWS console, while having the IDP portal page disabled!

Health Mailboxes Not Being Created in Exchange 2013 / Exchange 2016 Because of Missing Email Address Policy



Had an issue where the monitoring mailboxes were not being created for our Exchange organization.  Starting with Exchange 2013 CU1, these mailboxes are created in the OU Monitoring Mailboxes under the Microsoft Exchange System Objects OU:


Previous to that, they were created in the default Users folder in Active Directory.

I had tried several things, I restarted the Health Manager service on all my Mailbox servers, I re-ran setup.exe /PrepareAD from the installation files, checked to ensure that the Exchange servers had permissions to that OU, deleted the Monitoring Mailboxes OU and re-ran Setup.exe /PrepareAD.  Nothing worked.  Deleting the Monitoring Mailboxes OU and re-running Setup.exe /PrepareAD did recreate the Monitoring Mailboxes OU, but there were still no Health Mailboxes.

The fix for this was really simple.  The default email address policy in this environment was disabled, or scoped to only apply to a very specific OU that didn’t include the Microsoft Exchange System Objects->Monitoring Mailboxes OU. 

We created a new email address policy that did apply to that OU:


After I created it, I ensured that it was applied:


After that, I restarted the Microsoft Exchange Health Manager service on all Mailbox servers and low and behold!  All monitoring mailboxes were created!

Essentially if you do not have an email address policy that applies to the Health Monitoring mailboxes, they will not be created.  The fix was simply, create and apply one to that OU.

Migrating Public Folders to Exchange 2016



In this article we will go through the steps to migrate public folders from Exchange 2010 to Exchange 2016.  Keep in mind this same process works for migrating to Exchange 2013 as well, the steps are identical.

Change In Architecture

Let’s start first with the changes in the public folder setup that began in 2013, what Microsoft calls “Modern Public Folders”.  Legacy Public Folders, or public folders from a version of Exchange previous to 2013 went largely unchanged.  There were public folder databases that were stored on a mailbox server.  To provide high availability and redundancy, you could create public folder databases on multiple mailbox servers.  Then, on a per folder basis establish replica’s of that folder so that copies were on more than one server.

Anyone that has dealt with legacy public folder replication issues can tell you the process is not that fun to troubleshoot.  It’s also not exact, as the quickest the folders can replicate is 15 minutes.  This can certainly cause issues if you have a group of users collaborating and they are each connected to a separate copy of the public folder data, there can be delays or collisions in the data sets.  Also, public folder databases could not be protected in a DAG, so they were not able to benefit from the same availability designs as normal mailboxes.

Exchange 2013 change the architecture so that public folder data is now stored in mailbox’s designated as “Public Folder Mailboxes” instead of using dedicated public folder databases.  The benefit of this model was that public folders could not be placed into normal user mailbox databases, which would mean they not benefit from the DAG architecture.  Also, there is now only one writeable copy of the folder, so data integrity is more accurate. 

This means that there is a migration process that must occur from the legacy public folders to the modern public folders.  What we will aim to do in this article is highlight how we do that migration, and also how the user connections to the modern public folder changes as well.

For this article we will leverage a simple two server architecture.

PHDC-SOAEXC01 – 2010 Multirole Server hosting Legacy Public Folders

PHDC-SOAE16MBX2 – 2016 Server that will host the mailbox databases that will contain the Modern Public Folders

Download the Migration Scripts

First we need to download the pre-built migration scripts from Microsoft.  Download them to C:\PFMigration on both your legacy public folder server, and your 2013 Mailbox Server

Run Export Commands for Reference:

On the Legacy Public Folder Server, run the following commands:

Get-PublicFolder -Recurse | Export-CliXML C:\PFMigration\Legacy_PFStructure.xml
Get-PublicFolderStatistics | Export-CliXML C:\PFMigration\Legacy_PFStatistics.xml
Get-PublicFolder -Recurse | Get-PublicFolderClientPermission | Select-Object Identity,User -ExpandProperty AccessRights | Export-CliXML C:\PFMigration\Legacy_PFPerms.xml

This will allow you to backup the folder structure, statistics and the client permissions for reference.  This will be useful if you find your migration does not go well and you need to reference how things looked before the migration.

Check Folder Names

We need to check if any folder in the hierarchy has a backslash “\” in its name.  If it does, it will cause the migration to inadvertently place that folder in the root.  For example, if we had a folder named named “P/E Assets” that was a subfolder of the top level folder “Departments”, the migration would cause the P/E Assets folder to be placed in the root directory alongside Departments instead of under it.  To check, run the following command on the Legacy Public Folder Server:

Get-PublicFolderStatistics -ResultSize Unlimited | Where {$_.Name -like "*\*"} | Format-List Name, Identity

Manually rename any folder found here to something without the backslash character.

Generate CSV Files

Next, we need to use the downloaded scripts from Microsoft to generate two CSV files.  The first one will be PublicFolderStatistics.CSV.  This will simply list all of the folders and their respective sizes.

In the Exchange Management Shell on the Legacy Public Folder server, navigate to the C:\PFMigration folder and run the below command:

.\Export-PublicFolderStatistics.ps1  c:\PFMigration\PFFolderStatistics.csv legacyservername

Replace LegacyServerName with the name of your legacy public folder server, such as:


The script will output the number of folders and their statistics to a CSV file, like below:


It will list the path, and the folder size on the right hand side.

The second script we run, is the Mailbox Mapping script.  What this does is take the PFFolderStatistics.csv file as an input, and also the max size you want a public folder mailbox to be as an input and tells you how many Public Folder Mailboxes you need, and what their names should be.

For instance, in our environment, we don’t want any Public Folder mailbox to be over 1 GB in size.  So we run the following command:

.\PublicFolderToMailboxMapGenerator.ps1 1073741824 c:\PFMigration\PFFolderStatistics.csv c:\PFMigration\PFMailboxMapping.csv

The first input is the max size of each Public Folder Mailbox in bytes.  That is our 1073741824 value.  Note that we are doing this in a lab and in real applications, you want your Public Folder mailbox max size to be something larger.  The next input is the path to our PFFolderStatistics.csv file we generated above.  Finally, we put the path that the script should output our PFMailboxMapping.csv file to.  Running this command looks like the following:


Note that if your Max Public Folder Mailbox size is smaller than the any one folder in and of itself this script will return an error.  Simply increase the max size until the error stops appearing.

The CSV file will look like the following:


Notice the left hand side is the folder paths, and on the right hand side is the corresponding Public Folder Mailbox that they will be migrated into.  The script uses generic names, so we can see, its lists Mailbox1 through Mailbox10.  This means I need at least 10 Public Folder Mailboxes for this migration.

Also to note, the names of the Public Folder Mailboxes are important.  If we leave the CSV file as is, our Public Folder Mailbox name has to match these.  In our case, we want to change our structure.  We want the following Public Folder Mailboxes:











Note that the first Public Folder Mailbox created will be known as the root public folder mailbox and will be the mailbox responsible for keeping the hiearchy.  The rest will replicate the hiearchy from this mailbox, but are available for data to be stored in.  Since we are changing the names, we need to manually edit the CSV file to reflect that.  Note that the root public folder mailbox must be assigned to the folder “\”.

After editing our CSV file looks like this:


Create the Public Folder Mailboxes

On the Exchange 2016 server, create the public folder mailboxes, ensuring they have the same name as in the CSV file:

New-Mailbox PublicFolder-RootMailbox -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-1 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-2 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-3 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-4 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-5 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-6 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-7 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-8 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-9 -PublicFolder -HoldForMigration

This is important, ensure that you have an Email address policy that applies to the public folder mailboxes.  If they do not receive an email address, the migration will fail, but also users wont be able to connect to them later on.  We’ll explain why.

Start the Migration:

Copy the contents of C:\PFMigration to the same location on your Exchange 2016 server.  From an Exchange Management Shell, run the following command:

New-MigrationBatch -Name PFMigration -SourcePublicFolderDatabase (Get-PublicFolderDatabase -Server LegacyServerName) -CSVData (Get-Content C:\PFMigration\PFMailboxMapping.csv -Encoding Byte) -NotificationEmails -BadItemLimit 1000 

Replace LegacyServerName with the hostname of your 2010 Public Folder server, and with the email address of who should get notified when the migration is done.  The command in our set up looks like this:


Next, we can start it from the command line with:

Start-MigrationBatch PFMigration


Of by logging into ECP and starting it from there:


Now we wait for the Migration to get to the status of “Synced” and then we are ready to look at doing the final cutover.  Notice there is a migration for each public folder mailbox, in our case a total of 10.  

Also remember that Migration Batch’s will do incremental sync’s every 24 hours so you can start the initial sync in advanced and let the system sync up every 24 hours.

Lock Down Migration (Downtime Starts!)

The start of this next section is when the users will no longer be able to connect to Public Folders through Outlook.  They will receive an error if they try to expand the public folder section in outlook.

Once the migration reaches a status of Synced your ready for the next step:


Run the following command to lock the public folders for migration, this needs to be run on the Legacy Exchange Server:

Set-OrganizationConfig -PublicFoldersLockedForMigration:$true


If you have multiple Legacy Exchange Servers, this can take some time to complete.  During this time, all emails destined for Mail Enabled Public folders will queue until the migration is completed.

Next you need to run the following commands to complete the Public Folder sync.  Note this will not yet release the folders for the end users:

Set-OrganizationConfig -PublicFoldersEnabled Remote
Complete-MigrationBatch PFMigration


Or you can complete the MigrationBatch in the GUI:



Testing the Folder Hierarchy

Once the migration completes, you can unlock the hierarchy for a test user, just to validate the folder structure is there:

Set-Mailbox -Identity -DefaultPublicFolderMailbox PublicFolder-RootMailbox


If the folder structure looks good and your ready to unlock for everyone, run the below set of commands:

Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false
Set-OrganizationConfig -PublicFolderMigrationComplete:$true
Set-OrganizationConfig -PublicFoldersEnabled Local


Modern Public Folder Connectivity

This brings us to an important part of the process, discussing the connectivity changes for Modern Public Folders.  In previous versions of Exchange, an outlook client made a direct connection to the Public Folder Server.  Your connection logic was handled by the Exchange Server that accepted your connection for your mailbox, informing you of how to connect to public folders.  Well, starting with Exchange 2013 all traffic was forced through either Outlook Anywhere or MAPI/HTTP.  With Modern Public Folders, all connections to public folders, since they are essentially mailboxes, are handled just like a users mailbox, through autodiscover!

Taking our example public folder mailboxes from above:

Notice how they each have an email address of  Now lets say that we have a user, and their email address is  When this user connects to their mailbox, their Outlook will actually perform two autodiscover requests.  One to the domain, and the second to the domain.  This is why you need to ensure the public folder mailboxes have a valid SMTP address, but also that you have valid autodiscover records for that domain.  Remember, if you set the email address to something internal, external users will not be able to access public folders!

If we use the Test Email Auto Configuration tools on our Outlook and check the XML value we will see the public folder mailbox that we our getting in our autodiscover response to connect to:



Configuring Cross Organization Free Busy Information in Exchange 2013


There are many times when you will have an outside organization that you wish to share free busy information with.  Starting with Exchange 2010, Microsoft introduced the ability to utilize their Microsoft Federation Gateway to facilitate the sharing of free/busy information across multiple organizations.  While that solution works really well, there are times when that might not be the best solution.  For instance, you may have a customer in the middle of a large scale migration, or a partner company that you have connectivity to.  In these situations, you can utilize the direct method of establishing and configuring sharing free busy information.  This method, does require the two exchange organizations to have some level of connectivity to each other.  There are two direct methods that you can use. 

You can leverage the forest trust model, which indicates that you have a forest between between the two Exchange Organizations.  This would mean that you have a high level of network connectivity and integration between the two organizations.  The benefit to this method is that you can assign per user based permissions.  Meaning Paul from Forest A can have expanded rights to Jon from Forest B’s mailbox for free and busy. 

The second option is to use the non trusted forest based model.  This means that there is no forest trust between the networks.  Instead a general service account is leveraged to secure the permissions.  This means that the free and busy info is assigned organization wide, meaning you lack the granularity to assign different permissions per user.

I’ll walk through and explain both methods.  For our lab, we have the E15.corp forest, running Exchange 2013, and SOA.corp running Exchange 2013.

Trusted Forest Mode:

So the first thing we need to do is assign the mailbox servers in each forest to have the ms-exch-epi-token-serialization right on the remote forest’s mailbox servers.  If this is an Exchange 2010 or Exchange 2007 environment, change out mailbox servers for cas servers.

In the SOA.corp forest run:

Get-MailboxServer | Add-ADPermission -Accessrights Extendedright -Extendedrights “ms-Exch-EPI-Token-Serialization” -User “E15.corp\Exchange servers”


In the E15.corp forest run:

Get-MailboxServer | Add-ADPermission -Accessrights Extendedright -Extendedrights “ms-Exch-EPI-Token-Serialization” -User “soa.corp\Exchange servers”


So now, the Mailbox Servers from each forest, have the permission’s necessary. 

Next, in each forest, you need to add the availability space so that Exchange knows to look up that space for Availability.  Here is also where we will tell Exchange that we will use the Per User format.  In the SOA.corp domain run:

Add-AvailabilityAddressSpace -Forestname e15.corp –AccessMethod PerUserFB -UseServiceAccount:$true


For the ForestName parameter, mine is E15.corp because it’s a test lab, but this should be the SMTP namespace of the far side domain.  So if the far side is, replace my E15.corp with

Then, in the E15.corp domain run the following:

Add-AvailabilityAddressSpace –Forestname soa.corp –AccessMethod PerUserFB -UseServiceAccount:$true



Next, we need to tell the soa.corp domain how to retrieve free and busy information from the e15.corp domain.  By default, it will use DNS and attempt autodiscover.e15.corp.  So ensure your source forests can resolve that address, and that they trust the certificates of the far side domain.

You can also export the Service Connection Point from one side and import it into the other.

In the E15.corp domain, to export it’s autodiscover information to the Soa.corp domain, run:

Export-AutodiscoverConfig -TargetForestDomainController “phdc-soadc01.soa.corp” -TargetForestCredential (Get-Credential) -MultipleExchangeDeployments $true

Replace the TargetForestDomainController value with the FQDN of your far side domain controller.  And then enter in credentials in the destination forest:



In the SOA.corp, run the same command but specify it for the E15.corp domain:””

Export-AutodiscoverConfig -TargetForestDomainController “phdc-e15dc01.e15.corp” -TargetForestCredential (Get-Credential) -MultipleExchangeDeployments $true


You can check the SCP in your local domain by opening ADSIEDIT and connecting to the Configuration Partition, then browsing to Services->Microsoft Exchange Autodiscover

This is a screen shot from soa.corp showing the SCP info for E15.corp:


Untrusted Forest Mode:

If you don’t have a forest trust between the two forests, you can still do free busy, but you can only share it on an organization wide basis.

In the E15.corp forest, create a user named FreeBusyE15@e15.corp.  This can be a regular user account with no mailbox.

In E15.corp run the following:

Set-AvailabilityConfig –OrgWideAccount e15.corp\freebusye15

In the SOA.corp forest, create a user named FreeBusySOA@soa.corp.  This can be a regular user account with no mailbox.

In SOA.corp run the following:

Set-AvailabilityConfig –OrgWideAccount soa.corp\freebusySOA

Next, in the E15 forest, run the following command to configure the availability service to SOA.corp.  This will leverage the account in the SOA.corp domain to do so:

$a = Get-Credential soa.corp\freebusySOA
Add-AvailabilityAddressSpace –Forest Soa.corp –AccessMethod OrgWideFB –Credentials $a

Next, in the SOA forest, run the following command to configure the availability service to E15.corp.  This will leverage the account in the SOA.corp domain to do so:

$a = Get-Credential E15.corp\freebusySOA
Add-AvailabilityAddressSpace –Forest E15.corp –AccessMethod OrgWideFB –Credentials $a

Syncing the GAL:

So, you need to sync the GAL to make contact objects available across both domains.  Meaning, the Mailboxes of E15.corp get created as mail contacts in SOA.corp and vice versa.  This allows your users to select them from the GAL and perform free/busy lookups.

For the sake of our article, I’ll manually create a mailbox called pponzeka@e15.corp in E15.corp and then manually create a mail contact called pponzeka@e15.corp in SOA.corp.  Then I’ll test with an SOA mailbox to see if I can perform cross forest free busy.

In the pponzeka@e15.corp mailbox, ill create a meeting for tomorrow between 3 PM and 5 PM named E15 Corporate Meeting:



We open Outlook for the user very imaginatively named, Soa-User1, go to create a new appointment and select the Scheduling Assistant.  If we click Add Attendees and see that we have a Paul Ponzeka with the globe icon, indicating he is a Mail Contact:


And confirmed!  Working cross forest free/busy:



Exchange 2013 Error: This computer is a member of a cluster


Had an issue in the lab today.  Went to uninstall an Exchange 2013 server that I had previously removed from a DAG, yet when I went to uninstall Exchange 2013, kept getting an error message that “this computer is a member of a cluster”, even though it was not.  It was an easy enough fix, ran cluster.exe node /force and then tried the uninstall again.

Worked like a charm.

Cycle for Survival!!! Donate to a Great Cause!


On March 1st I’m joining a great cause called Cycle for Survival!  Its sponsored by Equinox and Memorial Sloan-Kettering Cancer Center.  100% of the proceeds go towards rare cancer research.  I am looking for help to raise money for a great cause!  Any donations will help.  I am also in a bet with my wife over who can raise more money!  There is a lot at stake so any help will go a long, long way!


Below is the link to donate to the cause: 


And here is more info on the event itself:

Join the Battle with Paul Ponzeka. Beat Rare Cancers.

I am taking action against rare cancers by participating in Cycle for Survival.

This national indoor team cycling event raises money to fund critical research at Memorial Sloan-Kettering Cancer Center. Participants and donors make progress and hope possible for patients and their loved ones worldwide.

Here are two important facts you should know:

>>> 100% of the funds donated for my ride will go directly to MSKCC to help patients around the world.

>>> Since its inception, Cycle for Survival has helped fund 85 clinical trials and research studies.

Why do I ride?

I ride to honor brave family and friends touched by cancer. Cycle for Survival is my way of fighting back and making a difference.

I ride because I want to contribute to lifesaving research.

I ride because there aren’t enough treatment options for people with rare cancers—I know we can change that. All pediatric cancers, leukemia, lymphoma, sarcoma, and thyroid, ovarian and pancreatic cancers are among the many types considered to be rare.

How can you help?

Give a gift to my Cycle for Survival ride! Every dollar goes directly to promising cancer research.

Together, we can truly make an impact!

It’s time.


How to Install a Certificate in Exchange 2013



Log into the Exchange Admin Center by going to your CAS server at https://CASSERVERNAME/ECP:


Now navigate to Servers->Certificates


Select the CAS server you want to push it to, in our case we will select PHDC-E15CAS01.E15.corp


Now, select the + sign which will bring up the New Exchange Certificate wizard:


Create a friendly name for the certificate:


At the next screen you can decide to request a wildcard certificate, where you would enter the root domain.  For example, if you wanted a wildcard certificate for, your screen would look like the following:


If you want to create a SAN certificate, leave this unchecked and select next.

Select the server to store certificate on, in our case, the same server we are requesting it for PHDC-E15CAS01:


Next, you need to select the services that you want to assign to the external domain, and the FQDN of that service.  In our case, everything will be to  Select each service that does NOT say (when accessed from the intranet) and click the pencil icon to edit the domain:




When you click next, it will show you the domains that will be added to the certificate.  If you have any accepted domains in your organization, it will add the entry to the certificate:


When you click Next, you will need to fill out the information for the organization requesting the certificate:


Select the location to save the certificate.  If you don’t have a network share pre-configured (with the exchange trusted subsystem as an administrator), then you can store it on the C drive of the CAS server with \\phdc-e15cas01.e15.corp\c$\newcertreq.req


Now when you see the request, it will be pending:



Now we need to submit this request to a certificate authority to complete the request.  In our case, we will use a Windows 2008 R2 CA to do so.

Log into your certificate authority at https://CA/certsrv

Select Request a Certificate-> Advanced Certificate Request-> Submit a Certificate Request by using…

Open the request you saved before in notepad:


Copy and past that into the Base-64-Encoded…field, and set the Certificate Template to Web Server:


Hit submit to finalize, and you should see the option to Download Certificate or Download the Certificate Chain.  Select Download the certificate and save the file to the shared location that you saved the request file to.  Next, download the Certificate Chain to the same location, as we will need to import the CA certificate to the host to ensure it trusts the certificate.  certnew.cer is the exchange servers certificate, certnew.p7b is the CA certificate.


To import the Certificate Authority certificate, RDP into PHDC-E15CAS01.  Open up a blank MMC console and add the certificates snapin for the local account:


Expand and select Certificates underneath Trusted Root Certification Authorities


Right click Certificates select Import->All Tasks->Import


Select the Certificate Authority certificate you downloaded before:



Select Next and Finish.

Return to Exchange Admin Center, select the pending request certificate, and on the right hand side select Complete



A new dialog box will open up, enter the path to the certnew.cer file, in our example this would be:



Now we need to assign this certificate to the specific services we want, select the certificate and click the pencil icon.  Then click services, and lets check off which services we want.  We are going to want to add SMTP and IIS:


You will receive a warning about overwriting the existing certificate, just select yes:


That’s it, you are all set! When we go to the site and check the certificate:


We are now utilizing the new cert!

Configure Application Impersonation for Exchange 2010 in Resource Forest



With the new Exchange 2010 RBAC model, one of the configuration changes is regards to EWS and Application Impersonation.  Instead of defining the ACL’s directly, you configure roles for the appropriate permissions.

If your in a resource forest setup, things are a little different.  Here are the steps.

Your service account, named ServiceAccount needs to be assigned Application Impersonation rights to all the accounts in the Accounting OU.  The user accounts are in client.corp and the Exchange mailboxes are stored in exchange.corp and there is a forest trust between the two.

Step 1:

Create a Universal Security Group in client.corp named UG-ExchangeImpersation.

Step 2:

Create a new linked role group with the Application Impersonation rights bound to this group.  Run the following from an Exchange Management Shell in exchange.corp:

$remotecred = get-credential
Put in a user name of an admin account for client.corp

New-RoleGroup ROLEGROUP-ExchangeImpersonation –LinkedForeignGroup “UG-ExchangeImpersation” –LinkedDomainController DC01.client.corp –RecipientOrganizationalUnitScope ‘exchange.corpAccounting’

Step 3:

Add serviceaccount to the UG-ExchangeImpersonation group in Client.corp.

Ensure that serviceaccount has a linked mailbox in exchange.corp.

Once AD replication finishes, you should have impersonation rights on all users in that Organizational Unit!

You cannot open an additional mailbox with Outlook Anywhere and Exchange 2010



If your running Exchange 2010 and utilize Outlook Anywhere, you may have users who complain that they cannot open an additional mailbox.  When they go to expand the additional mailbox, they get the error “Cannot Expand the subfolder” or a similar error.  The scenario is that you have two separate Active Directory sites, and you have outlook anywhere served out of each of them.  For example:

User – Paul Ponzeka

Site – NewYork

OutlookAnywhere URL –

User – Jon Smith

Site – SanFrancisco

OutlookAnywhere URL –

When you add Jon Smith as an additional mailbox to open in Paul Ponzeka’s exchange profile, you cannot open Jon Smith’s mailbox.

This is due to a change in behavior in Exchange 2010 SP2 RU3.  The CAS servers now will try to force a user to connect to a CAS server that is in the local site of the mailbox your trying to connect to.  You can see this in the RPC log:

2012-09-10T17:02:06.140Z,92,1,/o=Company/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Paul Ponzeka72f,,OUTLOOK.EXE,14.0.4760.1000,Classic,,,ncacn_http,,DelegateLogon,1003 (rop::UnknownUser),00:00:00.0156005,"Logon: Delegate, /o=Company/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=John Smith in database DAG01-MDB12 last mounted on at 9/6/2012 2:45:10 AM, currently Mounted",RopHandler: Logon: [RopExecutionException] The client should use Outlook Anywhere and RpcClientAccess server from site SanFrancisco to access the mailbox.. Error code = UnknownUser

The import portion of the log is:

“The client should use Outlook Anywhere and RpcClientAccess server from site SanFrancisco to access the mailbox.. Error code = UnknownUser”

What is happening is the CAS server that Pauls mailbox connects to for Outlook Anywhere has determined that the San Francisco site has a CAS server that is better suited to handle the request for Matt Williams mailbox.  However, since Paul is opening it as an additional mailbox, he cannot open the mailbox and the connection fails.  The workaround is the create the following registry entry:



Create a DWORD entry named EnablePreferredSiteEnforcement and ensure the value is set to 0.  Recycle the Microsoft Exchange RPC Access Service and this should fix it. The fix is described in the following KB article from Microsoft: