You had me @ stfu: March 2013

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.

MS Exchange RPC Client Access Service fails to start

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

I had an issue with installing Exchange 2010 whereby installation took an age and the MS Exchange RPC Client Access service failed to start. I’ve had a similar issue in the past with DoubleTake, so applied the same troubleshooting and workaround.

To troubleshoot, I established that the MS Exchange RPC Client Access service is trying to listen on a particular port, so looked to see why that might not be able to. Firewall off, start MSExchangeRPC service – fail. Check for other software installed – (no AV) – the only other software is some asset management software called NetSupportDNA. Found the service for that, stopped the service, start MSExchangeRPC service – success, start NetSupportDNA service – success. Modified the service startup type for NetSupportDNA service to Automatic (delayed start) and for good measure added a dependency on the MSExchangeRPC service (new multistringvalue in regedit). A small screen capture is included at the end of this post.

During further Exchange server installations I’ll stop the NetSupportDNA service (it doesn’t need to be running all the time) and then modify the parameters before a server reboot (I exported the registry key and whittled it down to these two items).

The client finds this an acceptable workaround. I’ll need to do it on the mailbox servers as well as clients connect directly to them for Public Folders.

While this is a fairly specific problem, as I said at the beginning, I came across a similar issue previously so I’m really just highlighting the delayed start service startup type and how it can be used to workaround issues.

BES links (re: Exchange)

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

I've compiled all the BES links that an Exchange Consultant could possibly want. If I've missed anything, then you're over-engineering it.

BlackBerry Enterprise Server Compatibility Matrix - http://btsc.webapps.blackberry.com/btsc/viewdocument.do?noCount=true&externalId=KB22601

Recommended Microsoft Active Directory groups for the BlackBerry Enterprise Server service account – KB04557 - http://btsc.webapps.blackberry.com/btsc/viewdocument.do?externalId=KB12309

Some BlackBerry smartphone users are unable to receive emails after a mailbox move from Exchange 2007 to Exchange 2010 – KB32634 - http://btsc.webapps.blackberry.com/btsc/viewdocument.do?noCount=true&externalId=KB32539

How to install or upgrade the MAPI Client and Collaboration Data Objects 1.2.1 on the BlackBerry Enterprise Server – KB15779 - http://btsc.webapps.blackberry.com/btsc/viewdocument.do?externalId=KB10285

Restarting the BlackBerry Enterprise Server services may cause delays in message delivery – KB04789 - http://btsc.webapps.blackberry.com/btsc/viewdocument.do?externalId=KB03296

How to turn ON Global Catalog referrals on BlackBerry Enterprise server – KB16118 - http://technet.microsoft.com/en-us/library/ee332346.aspx

Search the Blackberry Knowledge Base - http://btsc.webapps.blackberry.com/btsc/microsites/microsite.do

I'm aware that RIM have (in the past) moved or deleted their KB articles. To this end I have created some very basic pdfs of the above articles and packed them in one zip file. You can download the zip file here. Wasn't that nice of me?

Fixing Failed and Suspended DB copies

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

I was looking for something in my archive e-mail and stumbled across this script for Exchange 2010.

One of the things I have observed is that database copies easily fail if you have repeated failovers and switchovers with little or no traffic. As what happens when you are testing a new environment.

http://www.cohesivelogic.com/2010/08/automatically-fixing-failedandsuspended-exchange-2010-databases-with-powershell/

It's not one of my scripts, so I'm not taking credit for it.

Here is the script listed in the article:

add-pssnapin *0* -ErrorAction SilentlyContinue

$startstring="Start script run at: "

$startendtime=date

$startannounce=$startstring+$startendtime

Start-Transcript -Append -Force -Path 'C:\<path>\DBHealthFix.log'

$startannounce

#gets list of mailboxservers, locates 2010 servers, gets db copy status, finds copies that are failed, updates failed copies

$mailboxservers = get-mailboxserver | get-exchangeserver | ?{$_.IsE14OrLater -eq 'True'}

foreach ($mailboxserver in $mailboxservers){

get-mailboxdatabasecopystatus -Server $mailboxserver.name | ?{$_.Status -like 'FailedAndSuspended'} | update-mailboxdatabasecopy -deleteexistingfiles -confirm:$false

}

stop-transcript

I don't know any rocket scientists, which is okay because it doesn't need one to work out that you need to replace "<path>" in the script with an appropriate folder name.

Useful links (Lync & other)

Here are a few more useful links.

LYNC

Set-CsLync2013Prereqs.ps1 – Easily install prerequisites and tools for Microsoft Lync Server 2013 - http://www.ehloworld.com/1697

Lync products: http://www.techland.co.uk/ & http://www.vcomm.com/

OTHER

Mounting an ISO to a HP iLO over HTTP - http://torxsmind.blogspot.co.uk/search/label/iLO

Exchange Management Shell tips

This article has been ported from my old TechBlog as it is still valid and useful.

I’ve used loops to perform repeated tasks before but hit a snag with one that I wanted to do. It’s easy to vary an object with a number variable. For example:

1..4 | Foreach-object {Get-ExchangeServer -Identity SERVER0"$_"}

returns SERVER01, SERVER02, SERVER03, SERVER04.

Simples as Bob would say.

But trying to do that in a command that is already incorporating quotes (because there are spaces) poses a new dilemma. What am I on about? Look at the following example:

Set-OWAVirtualDirectory -Identity "SERVER0"$_"\OWA (Default Web Site)" -ExternalUrl https://mail.company.com/owa

That won’t work.

Don’t panic Mr Mainwaring, don’t panic

I have a solution and it works a treat. Break up the text and define it as a variable(s). Like this:

$dir = "\OWA (Default Web Site)"; 1..4 | Foreach-object {Set-OWAVirtualDirectory -Identity SERVER0"$_"$dir -ExternalUrl https://mail.company.com/owa}

So that one liner basically does this:

Set-OWAVirtualDirectory -Identity SERVER01\OWA (Default Web Site) -ExternalUrl https://mail.company.com/owa
Set-OWAVirtualDirectory -Identity SERVER02\OWA (Default Web Site) -ExternalUrl https://mail.company.com/owa
Set-OWAVirtualDirectory -Identity SERVER03\OWA (Default Web Site) -ExternalUrl https://mail.company.com/owa
Set-OWAVirtualDirectory -Identity SERVER04\OWA (Default Web Site) -ExternalUrl https://mail.company.com/owa

Exchange 2010 Datacenter failover and switchback scripts

This article has been ported from my old TechBlog as it is still valid and useful.

I’ve been lapping up some sunshine in the garden but the weather is now changing again, so it’s back indoors and time to post something. From some recent work I was doing, here are some scripts for DAG failover to DR site and switchback again. There are specific assumptions here; firstly, I was working with two mailbox servers in my main site and a single mailbox server in the DR site. Secondly, I had a single DAG. Thirdly, I was using the same CAS Array for both sites – that is not necessarily always going to be the case, but this was just a DR site, so was appropriate for me. Finally, I was blocking database activation in the DR site. You can easily modify the scripts according to your circumstances and need to modify some of the tags anyway.

< MAIN_SITE>
< DR_SITE>
< DAGNAME>
< DR_MBX_SERVER>
< CASARRAY>

In my example there are 15 mailbox databases named DB01-DB15.

#### TERMINATE FAILED DATACENTER
#### if mailbox server(s) in are still powered on but not functioning properly

POWER OFF

### or
Stop-DatabaseAvailabilityGroup -ActiveDirectorySite -Confirm:$false

#### if AD is available in but servers went off before doing the previous step
Stop-DatabaseAvailabilityGroup -ActiveDirectorySite -ConfigurationOnly -Confirm:$False

#### check that the mailbox servers have stopped in
Get-DatabaseAvailabilityGroup | select Name,*server*

#### run in
Stop-DatabaseavailabilityGroup -ActiveDirectorySite -ConfigurationOnly -Confirm:$False

#### ACTIVATE DR SITE
#### run in

stop-service ClusSvc
Restore-DatabaseAvailabilityGroup -ActiveDirectorySite -Confirm:$False
(repeat above if necessary)

1..9 | ForEach-Object {Move-ActiveMailboxDatabase DB0"$_" -ActivateOnServer -SkipActiveCopyChecks -MountDialOverride:None –confirm:$false}; 0..5 | ForEach-Object {Move-ActiveMailboxDatabase DB1"$_" -ActivateOnServer -SkipActiveCopyChecks -MountDialOverride:None –confirm:$false}
Set-clientaccessarray –site –confirm:$false

#### SWITCHBACK
#### run in after site is brought back up

Start-DatabaseAvailabilityGroup -ActiveDirectorySite
(repeat above if necessary)

Set-clientaccessarray –site –confirm:$false

#### check that mailbox servers in show as started in DAG ()

Get-DatabaseAvailabilityGroup | select Name,*server*

#### move databases back to

origlocation$=get-location; set-location exscripts$; .\RedistributeActiveDatabases.ps1 - -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution -Confirm:$false; set-location origlocation$

(repeat above if necessary)
#### if appropriate, block from activating databases when is available

Set-MailboxServer -DatabaseCopyAutoActivation:blocked

Monitor-MoveRequests.ps1

This article has been ported from my old TechBlog as it is still valid and useful.

I had to painfully watch someone move a mailbox and monitor its progress using Exchange Management Console the other day and I made a note to myself to share my mailbox move bits and pieces, especially a script ”what I writ’ to monitor move requests. I meant to add something to happen when the mailbox move is complete, but haven’t got round to it and can’t be bothered at the present time. Another day.

Here’s the Monitor-MoveRequests.ps1 script:

$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}

It may look familiar; I modified another script to make it

Here’s the rest of the stuff:

Test mailbox is ready to move:

New-MoveRequest -Identity user01@company.com -TargetDatabase "MDB01" –whatif

Move a mailbox:

New-MoveRequest -Identity user01@company.com -TargetDatabase "MDB01"

Clear a mailbox move request:

Get-MoveRequest | where {$_.status -eq "Completed"}

Clear all move requests:

Get-MoveRequest | where {$_.status -eq "Completed"} | Remove-moverequest -confirm:$False

New mailbox creation:

New-Mailbox -Name 'user01' -Alias 'user01' -OrganizationalUnit 'company.local/staff' -UserPrincipalName 'user01@company.com>' -SamAccountName 'user01' -FirstName 'user01' -Initials '' -LastName '' -ResetPasswordOnNextLogon $false -Database MDB01

Multiple move requests (enter in a ps1 script):

New-MoveRequest user01 -TargetDatabase "MDB01" -suspend
New-MoveRequest user02 -TargetDatabase "MDB02" -suspend

Start multiple move requests (enter in a ps1 script e.g. ResumeMailboxMoves.ps1):

Get-MoveRequest | Resume-MoveRequest

Powershell script as a batch file (e.g. for scheduling using Task Scheduler)(where ‘D:\Exchange’ is the Exchange install path):

PowerShell.exe -command ". 'D:\Exchange\bin\RemoteExchange.ps1'; cls; Connect-ExchangeServer -auto; & 'D:\Exchange\Scripts\ResumeMailboxMoves.ps1'"

Powershell - working with the registry

This article has been ported from my old TechBlog as it is still valid and useful.

I’ve been a good boy and taken the Lync leap. The really annoying thing I’ve always found about Lync is that it always starts up, especially when I don’t want it to. I reboot my laptop at home in the evening or at the weekend and the next thing I know is people are trying to contact me because they thing I’m working. Please. Working outside working hours? You don’t know me well enough.
So I set about doing something about it.

I started by tracking down what was forcing the Lync startup. I’m running Windows 7 64-bit and I found it here:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
"Communicator"=”C:\Program Files (x86)\Microsoft Lync\communicator.exe" /fromrunkey

So I set about nobbling that and replacing it with a Scheduled task that runs every weekday at 9am that starts up Lync.

Guess what? It works.

But this post would be far too simple and boring if that’s all I included in it. So let’s use some Powershell and to make this whole process a lot more complicated. But seriously, this is a great opportunity to demonstrate how to work with the Registry using Powershell and to introduce a script I found to help.

The script I found creates a .reg backup of Registry keys / values. The beauty of this is that you can then easily script and record what you are doing. I found the script here: http://franckrichard.blogspot.co.uk/2010/12/generate-reg-regedit-export-to-file.html

It’s quite clearly not my script, but I’ve used it and it does what it says on the tin. I found that I needed to specify ‘HKEY_LOCAL_MACHINE’ instead of ‘HKLM’, but with that heads-up you should find it easy to use. The script is included at the bottom of this page and can also be downloaded directly here. Don’t forget about your execution policy, although Powershell will prompt you if you have forgotten.

Exchange virtual directories default permissions

This article has been ported from my old TechBlog as it is still valid and useful.

I had to look up the default permissions for Exchange Virtual Directories and decided that I should capture them in my techblog for posterity. I got them from here: http://busbar.blogspot.co.uk/2010/05/exchange-20102007-virtual-directory_16.html

Nowadays I’m only interested in Exchange 2010, but these are valid for Exchange 2007 as well. It’s handy to have these as a reference for when you are fixing someone else’s mess, which seems to becoming a full-time job for me these days. Just call me 'the fixer'…

NodeStructureSettings

This article has been ported from my old TechBlog as it is still valid and useful.

I noticed an annoyance with an Exchange 2010 deployment with six servers (3 MBX and 3 CAS/HTS) where the servers had a hissy fit when the first MBX server was rebooted. The Exchange Management Console just didn’t want to connect whenever that MBX server was rebooted. It turns out that it relates to the value in the following registry key:

HKCU\Software\Microsoft\ExchangeServer\v14\AdminTools\NodeStructureSettings

The fix is to delete the key.

Enter our superhero saviour of the day – Captain Powershell – dah dah dah (fanfair).

Remove-ItemProperty -Path HKCU:\Software\Microsoft\ExchangeServer\v14\AdminTools\ -Name NodeStructureSettings

Just run that on each of your Exchange 2010 servers (see my post about backing up registry keys – what do you mean “you already deleted it”?).

OWApp password change page (standalone)

This article has been ported from my old TechBlog as it is still valid and useful.

I was asked what is the password change page is OWApp by someone who just wants to use it standalone. I know it’s an Exchange Control Panel page, but didn’t know what the url would be for the page on its own. Why would I? Do I have ‘SAD’ written on my forehead? (I’m not talking about those ‘priceless’ photos from my youth). Enough suspense; here it is:

https:///ecp/PersonalSettings/Password.aspx?showhelp=false

Of course, whether you can get to this from outside your domain network depends upon how your organization publishes OWApp. If everything is redirected via /owa, you’ll enter via your mailbox. But if it’s done properly you’ll get the following:

Revealing items hidden in ExBPA

This article has been ported from my old TechBlog as it is still valid and useful.

When viewing a report in ExBPA, you can hide items. But you may wonder how on earth you get them back again. Here’s how.

GUI:

When you are viewing a previous report in ExBPA, click the "Other Reports" radio button. If items have been hidden, you will see a "Hidden items" tab. You can unhide them by choosing "Show me this item again for all instances".

POWERSHELL:

The hidden items are stored in the registry and unhiding them can also be controlled from there.

The path is:

HKCU\Software\Microsoft\Exchange\ExBPA

The key is called SuppressionData and has a string data type. All the items you have suppressed are listed in this key and you can recover them by deleting individual ones or all of them. The values are comma separated.

When hiding items in ExBPA, the choices are “Do not show me this item again for this instance only” and “Do not show me this item again for all instances”. Which choice you make is reflected in the registry by appending the name of the instance you were working with to the name of the item. An item stored in this key that has a server name or Org name is hidden only for that server or Org, whereas an item without anything to accompany it is an exception item for all instances. If you clear the key completely then all hidden data is restored. You can do this with:

Remove-ItemProperty –Path HKCU:\Software\Microsoft\Exchange\ExBPA -Name SuppressionData

After you have manipulated the SuppressionData value in the registry you have to restart ExBPA for the changes to take effect.

BTW. If you weren't aware, you can use the Exchange Pre-deployment Analyzer with Windows 7 to view exported EXBPA reports.

Test-OutlookWebServices

This article has been ported from my old TechBlog as it is still valid and useful.

I was trying Test-OutlookWebServices with a new Exchange 2010 SP1 installation and it was failing with:

WARNING: An unexpected error has occurred and a Watson dump is being generated: Failed to find the mailbox. Mailbox = 'extest…

My friend Google led me to this fix:

http://www.itexperience.net/test-outlookwebservices-failed-to-find-the-mailbox-in-exchange-2010/

telling me that I have to run .\new-TestCasConnectivityUser.ps1 first…

which also failed with:

Mailbox could not be created. Verify that OU ( Users ) exists and that password meets complexity requirements.

Yes & Yes.

My friend Google helped me out again, as the client has more than one OU with the name ‘Users’ in the title (Main Office Users, Test Users, Remote Office Users) with the following:

http://www.zerohoursleep.com/2010/10/new-testcasconnectivityuser-ps1-fails-with-verify-that-ou-users-exists/

advising me to specify the OU as follows:

.\new-TestCasConnectivityUser.ps1 -ou domain.local/users

Woo-hoo. Success. Got there in the end. Thank you. Now what was I trying to do in the first place?

Connecting to Office365 with Powershell

This article has been ported from my old TechBlog as it is still valid and useful.

To manage Office 365 you can use Powershell. Here are the steps that you need to take to get set up for doing so:

http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh124998.aspx

Then you need to connect to the service (best to have UAC disabled). Use the ‘Microsoft Online Services Module for Windows Powershell’ that you now have installed, or import the module in Powershell with:

import-module MSOnline

The credentials that you need to provide are admin credentials for your Office 365 portal – that’s how it knows which account to connect to:

$livecred = get-credential; $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection; Connect-MsolService

Now that you are connected, here are the cmdlets that you can use:

http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh125002.aspx

You may want to start with:

Get-MsolDomain

Code (for my own benefit)