5 things to consider when changing the IP of an Exchange server
We are all faced, from time to time, with the need to change the IP address of our Microsoft Exchange server.
There is no hard relation between the operation of your Exchange server and its IP address thus changing the latter will not break your system.
In short this operation can be considered as safe however it requires a certain level of planning and considerations. I will try to cover in this article the various things you should think about before and after actually changing the IP of your server.
Managing spaces in AddReplicaToPFRecursive.ps1 script
If you are familiar with Microsoft Exchange 2007 you already know about the AddReplicaToPFRecursive.ps1 script that can be found in the "X:\Program Files\Microsoft\Exchange Server\Scripts", however this script has a bug it doesn't look to support public folders which names contains spaces.
It is quite common to enclose parameters that contains spaces with "quotations" but that doesn't work here.
If you simply try to use the following it will fail.
AddReplicatoPFRecursive.ps1 -TopPublicFolder “\PublicFolder with space” -ServerToAdd “servername”
The solution turned out to be to use single quotes inside the double quotes so it should be something like
AddReplicatoPFRecursive.ps1 -TopPublicFolder “'\PublicFolder with space'” -ServerToAdd “servername”
That's really weird and not standard but it works !
Cannot move mailboxes: INSUFF_ACCESS_RIGHTS error
When moving mailboxes from Exchange 2003 to Exchange 2007 or Exchaneg 2010 either from Exchange Management Console or Powershell using the move-mailbox or new-moverequest cmdlets the move operation might fail with the following error.
Active Directory operation failed on server.domain.com. This error is not retriable. Additional information:
Insufficient access rights to perform the operation.
Active directory response: 00002098: SecErr: DSID-03150A45, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
+ CategoryInfo : NotSpecified: (0:Int32) [New-MoveRequest], ADOperationException
+ FullyQualifiedErrorId : 6C39B6E8,Microsoft.Exchange.Management.RecipientTasks.NewMoveRequest
At first sight it looks like the user initiating the move mailbox doesn't have enough rights to perform this operation, however that user can move other mailboxes just fine.
Here is how to solve the issue
Managing certificates in Exchange 2010
If you are familiar with Exchange 2010 and trying to install Exchange 2010 for the first time you should have already noticed that the powershell cmdlets used to request and install certificates in Exchange 2007 no longer work in Exchange 2010.
For instance running
New-ExchangeCertificate -GenerateRequest -domainname mail.contoso.msft,autodiscover.contoso.msft,myserver,myserver.internal.contoso.msft -FriendlyName mail.contoso.msft -privatekeyexportable:$true -path c:\cert_myserver.txt
will fail with the following error
A positional parameter cannot be found that accepts argument ‘-Path’.
+ CategoryInfo : InvalidArgument: (:) [New-ExchangeCertificate], ParameterBindingException
+ FullyQualifiedErrorId : PositionalParameterNotFound,New-ExchangeCertificate
and running
Import-ExchangeCertificate -path "c:\CertNew.cer"
will also fail with the same error
A positional parameter cannot be found that accepts argument '-path'.
+ CategoryInfo : InvalidArgument: (:) [Import-ExchangeCertificate], ParameterBindingException
+ FullyQualifiedErrorId : PositionalParameterNotFound,Import-ExchangeCertificate
So here are the commands you should use for Exchange 2010
Solved: Setup Exchange 2007 SP1 CCR passive node fails
When installing Exchange 2007 SP1 in Cluster Continuous Replication (CCR) configuration. The setup of the passive node fails with the following error:
"This is not a passive node. A clustered mailbox server represented by the cluster resource group [clustername] was found on this node."
I've found out that the reason for the problem is that upon finishing the Exchange Cluster installation on the active node the setup will ask you for a restart. Restarting the machine will cause the Windows cluster to failover to the passive node to be and thus causing the Exchange installation to fail on that node.
To solve this problem make sure to move back the cluster resources to the active node and re-run the Exchange 2007 SP1 installation on passive node.
This solution was tested on Microsoft Windows 2008 and Microsoft Exchange 2007 SP1
