You had me @ stfu

Exchange Links

*N.B. this is an old article and may no longer be relevant*

This post is to clear up any ambiguity regarding the recommended Page File settings for an Exchange server. If you search online for a solution you will find all sorts of answers (and of course if it's on t'internet then they must be right).

The short answer is to set the minimum and the maximum to the amount of RAM plus 10MB.

That answer can be found posted by Microsoft here:
http://technet.microsoft.com/en-us/library/cc431357.aspx

It states there - "As documented in the Exchange 2007 System Requirements and Exchange 2010 System Requirements, the recommended paging file size is equal to the amount of RAM in the server plus 10 MB."

It also states - "To prevent page file fragmentation, we recommend that you set the paging file size initial and maximum values to be the same value. If you reduce the size of either the initial or maximum page file settings, you must restart your computer to see the effects of those changes. Increases typically do not require a restart."

Creating a custom Management Role Group

*N.B. this is an old article and may no longer be relevant*

Here's a post on creating a custom Management Role Group for a 1st Line support desk using the following blog entry as guidance:
http://msexchangeteam.com/archive/2009/11/16/453222.aspx

The customer requirement is:
1st Line should be able to create mailboxes / mail contacts / mail users and disable them but must not be able to remove them. They will not be doing mailbox moves or any Public Folder management. The pre-canned Recipient Management role therefore doesn’t fit the bill as they would have too many rights. The scope is the whole Organization, which is the default scope anyway.

Step 1 – Determine what to base your new custom role on. I chose Recipient Management.

Step 2 – Examine what Management Roles you want from that Role Group. I opted for Mail Recipient Creation, Mail Recipients & Recipient Policies as these are appropriate from the list (BTW, I got the list from ECP/Administrator Roles):

Recipient Management

Members of this management role group have rights to create, manage and remove Exchange recipient objects in the Exchange organization.

Assigned roles:
..........Distribution Groups
..........Mail Enabled Public Folders
..........Mail Recipient Creation
..........Mail Recipients
..........Message Tracking
..........Migration
..........Move Mailboxes
..........Recipient Policies

Step 3 – Examine the Management Roles and determine what Management Role Entries you want to keep (Management Role Entries are the cmdlets that can be performed if you have this Management Role assigned to you) . These cmdlets help you:

Get-ManagementRoleEntry "Mail Recipient Creation\*" | select Name | out-file c:\support\Mail_Recipient_Creation.txt
Get-ManagementRoleEntry "Mail Recipients\*" | select Name | out-file c:\support\Mail_Recipients.txt
Get-ManagementRoleEntry "Recipient Policies\*" | select Name | out-file c:\support\Recipient_Policies.txt

Here is an example of the Management Role Entries (this is the one for Recipient Policies):

Write-AdminAuditLog
Set-ThrottlingPolicyAssociation
Set-ThrottlingPolicy
Set-OwaMailboxPolicy
Set-ActiveSyncMailboxPolicy
Remove-ThrottlingPolicy
Remove-OwaMailboxPolicy
Remove-ActiveSyncMailboxPolicy
New-ThrottlingPolicy
New-OwaMailboxPolicy
New-ActiveSyncMailboxPolicy
Get-ThrottlingPolicyAssociation
Get-OwaMailboxPolicy
Get-DomainController
Get-DetailsTemplate
Get-CASMailbox
Get-ActiveSyncMailboxPolicy

I examined them (with the client) and we came up with a list of things to keep. Most things apart from ‘remove’ and stuff to do with ‘RemoteMailbox’.

Step 4 – Create new Management Roles that are children of existing roles:

New-ManagementRole -Name "1stLineMailRecipientCreation" -Parent "Mail Recipient Creation"
New-ManagementRole -Name "1stLineMailRecipients" -Parent "Mail Recipients"
New-ManagementRole -Name "1stLineRecipientPolicies" -Parent "Recipient Policies"

Step 5 – Strip the new Management Roles of all Management Role Entries apart from one (it is a requirement to keep at least one):

Get-ManagementRoleEntry "1stLineMailRecipientCreation\*" | ? {$_.name -ne "Write-AdminAuditLog"} | Remove-ManagementRoleEntry
Get-ManagementRoleEntry "1stLineMailRecipients\*" | ? {$_.name -ne "Write-AdminAuditLog"} | Remove-ManagementRoleEntry
Get-ManagementRoleEntry "1stLineRecipientPolicies\*" | ? {$_.name -ne "Write-AdminAuditLog"} | Remove-ManagementRoleEntry

Step 6 – Add in the Management Role Entries selected in Step 3 above. I put them into a ps1 file and the three attachments to this message include the cmdlets for doing this. Here are examples of three cmdlets from the scripts (I could have put all of them into one ps1 file, but this is complicated enough already):

Add-ManagementRoleEntry "1stLineMailRecipientCreation\New-Mailbox"
Add-ManagementRoleEntry "1stLineMailRecipients\Set-User"
Add-ManagementRoleEntry "1stLineRecipientPolicies\New-ActiveSyncMailboxPolicy"

Step 7 – Create a new Role Group (called “1st Line”) and add the new Management Roles to it:

New-RoleGroup "1st Line" -Roles 1stLineMailRecipientCreation,1stLineMailRecipients,1stLineRecipientPolicies –Description “Members of this group can create new mailboxes”

I can now see the new Role Group in ECP (see below).

In AD you’ll also find it in the Microsoft Exchange Security Groups OU (see below).

It sounds simple now that I read this, but it took a couple of hours to get to this point, so this post is as much to remind me the next time as it is to save you the hassle of working out how to do it.

Cat6e cables

*N.B. this is an old article and may no longer be relevant*

I don't normally post about hardware, but I had an e-mail from Bob a while back and think it's worth sharing:

"Started to wonder why Cat6e cable from CPC is like £100 and the “same” stuff of ebay is much cheaper – It’s because the more expensive stuff uses solid copper and the cheaper stuff is known as CCA (Copper clad aluminium)

A bit of googling:
“The use of CCA wire directly contravenes both CAT5e and CAT6 specifications which denote the use of copper conductors. CCA wire is not a copper conductor. Organizations supplying CCA as CAT5e and CAT6 network cables should examine very carefully if they are in compliance with the sales of goods act”

http://www.cetecglobal.com/technologies/cabling/cca.htm

Same goes for patch leads as well, so watch what you order."

So the lesson is not to buy Cat6e cables from Hong Kong or Shanghai for 99p with free postage!

Nice one Dave.

Simples (squeak).

Exchange 2010 to 2003

*N.B. this is an old article and may no longer be relevant*

An FYI with regards to moving mailboxes from Exchange 2010 back to Exchange 2003.

If you do this through EMC, you cannot monitor it through EMS. It thinks that no move requests exist.
When you try and do this through EMS, it won’t recognize the Exchange 2003 Target Database. In order to select an Exchange 2003 Mailbox Database you have to specify it’s GUID. The ways to do this that I found on the web either didn’t work or were too cumbersome.

So I looked in the Exchange Management Shell log and found a command that EMC had run to identify the database and found that you can get the database GUID from there. Put it all together and what you get is:

Get-MailboxDataBase -IncludePreExchange2010 | select identity,guid

Simples (as Bob would say).

So now I can insert the database GUID into my EMS move request:

New-MoveRequest -TargetDatabase "a10a12b3-2469-23ca-35ad-ea21acebd0e4" -BadItemLimit 100 -AcceptLargeDataLoss

And hey presto, I can monitor the move request process with the following:

moverequests = get-MoveRequest ; foreach ($moverequest in $moverequests) {Get-MoveRequestStatistics $moverequest | select Alias,DisplayName,StartTimestamp,TotalQueuedDuration,PercentComplete,BytesTransferred,StatusDetail,SourceDatabase,TargetDatabase,Status,TotalinProgressDuration,OverallDuration}

or stick it in a script that refreshes (e.g. Monitor-MoveRequests.ps1):

$moverequests = get-MoveRequest ; get-exchangeserver | ?{$_.IsE14OrLater -eq 'True'}
$A = (get-host).UI.RawUI
$A.WindowTitle = "Monitor Mailbox Move requests"
$B = $A.windowsize
$B.width = 150
$B.height = 65
$A.WindowSize = $B
while ($true) {cls; foreach ($moverequest in $moverequests) {Get-MoveRequestStatistics $moverequest | select Alias,DisplayName,StartTimestamp,TotalQueuedDuration,PercentComplete,BytesTransferred,StatusDetail,SourceDatabase,TargetDatabase,Status,TotalinProgressDuration,OverallDuration}
;sleep 5}

Note that I am throwing the last two scripts into the mix just to show off. I came up with this so that I can review mailbox moves through EMS as they are then reviewed in one window rather than opening and closing GUI windows to get them to refresh. Don't forget that your target Exchange 2003 mailbox database must have a valid System Mailbox or else the move will fail. If it doesn't have one but there is another Exchange 2003 mailbox database that does, move the mailbox to there and then move it again using System Manager.

N.B. Always test your rollback plan. It's better than an unforeseen forced new career plan!

Certificate Revocation Checking problem

*N.B. this is an old article and may no longer be relevant*

I had an issue a while back with performing certificate revocation checking. The SAN cert installed wasn’t working because the VLAN the servers are on did not have direct internet access. I needed to get the proxy to allow my Exchange servers (which are using the System account to do CRL checking) unauthenticated access to *.verisgn.com and *.verisign.net

In order to do this I had to follow the information I found in my old colleague Marcin's blog (http://unified.swiatelski.com/2011/01/exchange-2010-certificate-status.html) which did just relay what Microsoft publish (http://technet.microsoft.com/en-us/library/bb430772.aspx) but with the added warning:

Notice: Please remember to set value of bypass-list parameter to your local Active Directory domain FQDN. If you pass over this part you won't be able to connect to your Exchange using Exchange Management Console nor PowerShell.

I would have put that in BOLD and possibly RED AND BOLD, because it is more than just a minor annoyance. Maybe even RED AND BOLD UNDERLINED.

Also noteworthy is the following blog with some tips and troubleshooting information for this scenario:
http://blogs.microsoft.co.il/blogs/yuval14/archive/2011/09/20/how-to-resolve-exchange-2010-error-message-the-certificate-status-could-not-be-determined-because-the-revocation-check-failed.aspx

And the following information that I deduced or gathered elsewhere:

· CRL checking is performed at random intervals, but after modifying winhttp settings, you should reboot the server and wait for up to an hour
· To view logging, go to Event Viewer, Applications and Services Log, Microsoft, Windows, CAPI2 and enable the operational log
· Set-ExchangeServer –InternetWebSettings should work, but doesn’t

Backing up IIS

*N.B. this is an old article and may no longer be relevant*

I came across this within a script tucked away on the Exchange Team blog downloads. I think it’s worth extracting and putting into its own script in case changes need to be made to IIS, as a rollback option. The following article goes into more detail about IIS behaviour and restoring from a backup:
http://blogs.iis.net/bills/archive/2008/03/24/how-to-backup-restore-iis7-configuration.aspx

Here’s the script. Save it as BackupIIS.ps1; it takes a minimicronanosecond to run.

function BackupIISConfig
{
Write-Host "Backing up current IIS configuration" -ForegroundColor green
pushd
Set-Location "$env:windir\System32\inetsrv"
$backup = "Exchange IIS Backup "+(get-date -format "MMddyyyy-hhmmss")
.\appcmd.exe ADD Backup $backup
Write-Host "Backup saved to: $env:windir\System32\inetsrv\backup\" -ForegroundColor Green
popd
}
BackupIISConfig

As I said, it's not my script and I'm not taking credit for it. But it's a good script and it's tucked away and I just thought that it would be useful to have it 'not' tucked away.

Exchange 2010 resetting diagnostics logging

*N.B. this is an old article and may no longer be relevant*

I’ve found a bug in Exchange 2010 where resetting Diagnostics Logging back to defaults basically doesn’t work. There’s a screenshot of the error at the end of this post.

<--fail-->

Anyway, moving on from that, I did some searching on Technet and it states that ‘Lowest’ is the default level for all those services. WRONG (double fail). It’s the default level except for the following which are set to ‘Low’:

MSExchange RBAC\RBAC
MSExchange ADAccess\Topology
MSExchange ADAccess\Validation

I searched and couldn’t find a script to report on the logging level as I wanted it or to reset the levels, so I came up with my own.

This one reports all services that are not set to lowest:

$exchangeservers = get-exchangeserver | ?{$_.IsE14OrLater -eq 'True'}; foreach ($exchangeserver in $exchangeservers){Get-EventLogLevel -Server $exchangeserver | ?{$_.EventLevel -ne "Lowest"}}

Here’s the best bit. This script will set all the Event Log levels back to default:

$exchangeservers = get-exchangeserver | ?{$_.IsE14OrLater -eq 'True'}; foreach ($exchangeserver in $exchangeservers){Get-EventLogLevel -Server $exchangeserver | ?{$_.Identity -like "*\MSExchange*"} | Set-EventLogLevel -Level Lowest -Confirm:$0; Get-EventLogLevel -Server $exchangeserver | ?{$_.Identity -like "*\MSExchange ADAccess\Topology"} | Set-EventLogLevel -Level Low -Confirm:$0 ; Get-EventLogLevel -Server $exchangeserver | ?{$_.Identity -like "*\MSExchange ADAccess\Validation"} | Set-EventLogLevel -Level Low -Confirm:$0 ; Get-EventLogLevel -Server $exchangeserver| ?{$_.Identity -like "*\MSExchange RBAC\RBAC"} | Set-EventLogLevel -Level Low -Confirm:$0}

Preparing an Exchange 2010 DAG DR server

*N.B. this is an old article and may no longer be relevant*

Consider this scenario. You want to add an additional Exchange 2010 mailbox server that is going to be part of a DAG but you don’t want it to have any primary mailbox database copies e.g. a DR server that is only going to have database copies of activation preference 3

During installation you are forced to create a mailbox database. So here’s a simple way of achieving the goal.

My command to install the mailbox node is this:

C:\Installs\ExchangeMedia\Setup.com /mode:Install /Role:M /TargetDir:D:\Exchange /u:C:\Installs\ExchangeMedia\Updates /InstallWindowsComponents /MdbName:DefunctDB /DbFilePath:C:\Installs\DefunctDB.edb /LogFolderPath:C:\Installs

My command to tidy up the database and files after a reboot is this:

Remove-MailboxDatabase DefunctDB -Confirm:$false; del C:\installs\*.log; del c:\installs\*.edb; del c:\installs\*.jrs; del C:\installs\*.chk

Now you have a nice tidy mailbox server to add to your DAG and replicate mailbox databases to.

Exchange 2010 First Public Folder Database

*N.B. this is an old article and may no longer be relevant*

The first Public Folder Database in Exchange 2010 gets assigned a random name and installed at the default location. This may be okay for many customers, but not most. So a bit of tidy up work is required. Fortunately Captain Powershell has it under control.

Get-PublicFolderDatabase -Server SERVER1 | Set-PublicFolderDatabase -Name PFDB01 ; Dismount-Database PFDB01 -Confirm:$false ; Move-DatabasePath PFDB01 -edbFilePath M:\ExchangeData\PFDB01\PFDB01.edb -LogFolderPath L:\ExchangeData\PFDB01LOGS -Confirm:$false ; Mount-DataBase PFDB01

(where SERVER1 is the name of the first mailbox server built into the environment)

Here’s my job log:

[PS] C:\Windows\system32>Get-PublicFolderDatabase

Name Server
---- ------
Public Folder Database 1399... SERVER1

[PS] C:\Windows\system32>Get-PublicFolderDatabase -Server SERVER1 | Set-PublicFolderDatabase -Name PFDB01 ; Dismount-Database PFDB01 -Confirm:$false ; Move-DatabasePath PFDB01 -edbFilePath M:\ExchangeData\PFDB01\PFDB01.edb -LogFolderPath L:\ExchangeData\PFDB01LOGS -Confirm:$false; Mount-DataBase PFDB01

[PS] C:\Windows\system32>Get-PublicFolderDatabase

Name Server
---- ------
PFDB01 SERVER1

I think the only way to improve on it would be to tidy up the empty folder left behind, but I’m not going to lose sleep over that.