Quickly Retrieving Information on Receiving Connectors

Hi folks,

Just wanted to share with you a quick way to retrieve information about receive connectors on Exchange 2010/2013 servers.

As you know receive connectors are managed on transport (mailbox) servers and in order to retrieve information you need to retrieve receive connector information from every server. This is when standardization is helpful even in big environments.

So, let's imagine that you have large and highly standardized environment. On every transport server you have a receive connector named "From Internet" which is used to receive information from outer world and you need to retrieve information about it.

The 2 following strings help you to retrieve the information about the receive connector named "From Internet" from all hub transport (or mailbox) servers in your environment.

1st we create variable for all the transport servers in environment:

For Exchange 2007/2010 it will be:

$TrpSrv = Get-TransportServer -Identity *EX0* |sort Name

For Exchange 2013 and later:

$TrpSrv = Get-TransportService -Identity *EX0* |sort Name

And as soon as we have variable populated against every server in variable we execute command like below:

$TrpSrv |foreach {Get-ReceiveConnector -Server $_.Name |where {$_.Name -like "*Internet*"}}


Enjoy.

Quickly Retrieving AD Domains Within the Multi-Domain Forest

Hi folks,

If you are working in a multi-domain forest and you need to retrieve a list of domains there are coule ways to achieve, either using  ADSI as in this post or write function as this blog post. Both are work.

However there's a simple way to achieve it if you are running Windows 2008 R2 and later and AD PowerShell module. You can achieve this simply by running:


Get-ADForest |select -ExpandProperty Domains

An you will get list of all domain FQDNs within your forest.

Enjoy.

EMS and Exchange Server Installation Path

Hi folks,

Just wanted to share with you the recent adventure that I had. Sometimes there're situations when you will need to re-install Exchange Server binaries on the same server but into the different directory. Sometimes after successful re-installation you may run into the following error when starting Exchange Management Shell or Exchange Management Console (obviously because it runs on top of EMS):

Connecting to remote server failed with the following error message : The WinRM client cannot complete the operation within the time specified. Check if the machine name is valid and is reachable over the network
 and firewall exception for Windows Remote Management service is enabled. For more information, see the about_Remote_Troubleshooting Help topic.

This article is a good starting point for troubleshooting. So first make sure that ExchangeInstallPath environment variable exists and points to the right directory. You will need to reconfigure it pointing to the new installation folder.

However there's one more point which was not considered there. This is where this blog post came to my help. Apparently when Exchange binaries IIS cofiguration file (C:\Windows\System32\inetsrv\config\applicationHost.config) file remains unchanged. As the result kerbauth parameter is pointing to the old location of kerbauth.dll

It's quite easy to fix it. You will need to run the following steps:

1. Run command line as admin and execute:

notepad C:\Windows\System32\inetsrv\config\applicationHost.config

2. In the applicationHost.config locate the following entry:

<add name="kerbauth" image="C:\Program Files\Microsoft\Exchange Server\v14\Bin\kerbauth.dll" />

3. Modify path to the kerbauth.dll to point to the correct location and save applicationHost.config

4. Run iisreset /noforce

After this your EMS will be able to start successfully and connect to remote PowerShell without problem.

Enjoy.

Creating Identical Receive And Send Connectors

Hi folks,

I would love to share with you about an easy way to create receive connectors for multiple transport servers (Mailbox servers in Exchange 2013). As you know receive connectors are maintained on per server basis. At the other hand to have consistent mail receive experience you will need to have identical configuration of receive connectors in your organization, This task will be hard if you have many Exchange servers.

But fortunately, PowerShell is indeed powershell and allows to automate this task. All you need to do is to create one receive connector on first transport (mailbox) server and then you can easily deploy them across.

I won't share how to create receive connector as you can read about it in this TechNet article.

After receive connector is created you create a variable and dump all the information about the connector there. Then you run New-Receive connector on the rest of the server using New-receiveConnector cmdlet (or lately tweaking them using Set-ReceiveConnector cmdlet) and get all the necessary values for the parameters from the respective parameters dumped into the variable. The code will be as follows.

$RC = Get-ReceiveConnector -Identity "SERVER001\MyConnector"

For Exchange 2010:

New-ReceiveConnector -Name "MyConnector" -Server SERVER002 -AuthMechanism $RC.AuthMechanism -Bindings $RC.Bindings -Enabled $RC.Enabled -ConnectionInactivityTimeout $RC.ConnectionInactivityTimeout -ConnectionTimeout $RC.ConnectionTimeout -MessageRateSource $RC.MessageRateSource -MaxInboundConnection $RC.MaxInboundConnection -MaxInboundConnectionPerSource $RC.MaxInboundConnectionPerSource -MaxInboundConnectionPercentagePerSource $RC.MaxInboundConnectionPercentagePerSource -MaxRecipientsPerMessage $RC.MaxRecipientsPerMessage -PermissionGroups $RC.PermissionGroups -ProtocolLoggingLevel $RC.ProtocolLoggingLevel -RemoteIPRanges $RC.RemoteIPRanges -MaxMessageSize $RC.MaxMessageSize -MaxHopCount $RC.MaxHopCount -MaxLocalHopCount $RC.MaxLocalHopCount

For Exchange 2013:

New-ReceiveConnector -Name "My Connector" -Server SERVER002 -AuthMechanism $RC.AuthMechanism -Bindings $RC.Bindings -Enabled $RC.Enabled -ConnectionInactivityTimeout $RC.ConnectionInactivityTimeout -ConnectionTimeout $RC.ConnectionTimeout -MessageRateSource $RC.MessageRateSource -MaxInboundConnection $RC.MaxInboundConnection -MaxInboundConnectionPerSource $RC.MaxInboundConnectionPerSource -MaxInboundConnectionPercentagePerSource $RC.MaxInboundConnectionPercentagePerSource -MaxRecipientsPerMessage $RC.MaxRecipientsPerMessage -PermissionGroups $RC.PermissionGroups -ProtocolLoggingLevel $RC.ProtocolLoggingLevel -RemoteIPRanges $RC.RemoteIPRanges -MaxMessageSize $RC.MaxMessageSize -MaxHopCount $RC.MaxHopCount -MaxLocalHopCount $RC.MaxLocalHopCount -TransportRole $RC.TransportRole

Even more automation can be achieved if you create another variable for transport servers and then run New-ReceiveConnector cmdlet against every transport server in this variable, like below:

$TS = Get-TransportServer (for Exchange 2010)
or
$TS = Get-MailboxServer (for Exchange 2013 and later)

and then

$TS | foreach {New-ReceiveConnector -Name "MyConnector" -Server $_.Name -AuthMechanism $RC.AuthMechanism -Bindings $RC.Bindings -Enabled $RC.Enabled -ConnectionInactivityTimeout $RC.ConnectionInactivityTimeout -ConnectionTimeout $RC.ConnectionTimeout -MessageRateSource $RC.MessageRateSource -MaxInboundConnection $RC.MaxInboundConnection -MaxInboundConnectionPerSource $RC.MaxInboundConnectionPerSource -MaxInboundConnectionPercentagePerSource $RC.MaxInboundConnectionPercentagePerSource -MaxRecipientsPerMessage $RC.MaxRecipientsPerMessage -PermissionGroups $RC.PermissionGroups -ProtocolLoggingLevel $RC.ProtocolLoggingLevel -RemoteIPRanges $RC.RemoteIPRanges -MaxMessageSize $RC.MaxMessageSize -MaxHopCount $RC.MaxHopCount -MaxLocalHopCount $RC.MaxLocalHopCount}

Similar approach can be used for cloning send connectors in case you want to create scoped send connector or create send connector that use different source hub or mailbox servers in different sites.
The code for this will be as below:


$SC = Get-SendConnector "Send Connector Russia"

New-SendConnector "Send Connector Poland" -AddressSpaces $SC.AddressSpaces  -ConnectionInactivityTimeOut $SC.ConnectionInactivityTimeOut -DNSRoutingEnabled $SC.DNSRoutingEnabled -Enabled $SC.Enabled -ForceHELO $SC.ForceHELO -IgnoreSTARTTLS $SC.IgnoreSTARTTLS -MaxMessageSize $SC.MaxMessageSize -SourceTransportServers SERVER001,SERVER002 -SmartHosts $SC.SmartHosts -SmartHostAuthMechanism $SC.SmartHostAuthMechanism

Enjoy.

Which commans a Role Group Member can Execute

Hi folks,

Just wanted to quickly share with you one of the RBAC tricks in the Exchange 2010 or 2013. I will not go in to details on role groups, assignments, scopes and so on as it can all be read here.

These 2 strings of code create a report on what cmdlets members of a role group can execute and also scope where they can be executed.

I had to use the $RLGRP variable because when attempting to pipeline results of the Get-ManagementRoleAssignment cmdlet I would get error as below:

$RLGRP= Get-ManagementRoleAssignment  -RoleAssignee "Role Group Name"
$RLGRP |foreach {Get-ManagementRole $_.Role} |select Name,ImplicitRecipientReadScope,ImplicitRecipientWriteScope,ImplicitConfigReadScope,ImplicitConfigWriteScope,@{N="Role Entries";E={$_.RoleEntries}} |Export-Csv RlGrpCmdlets.csv

Successful execution of this code produces a nice Excel report.

And of course you will need to replace Role Group Name with something real from your environment.


Enjoy.

Where are My AD Objects?

Hi folks,

Just another quick post about the scenario when you attempt to create or manipulate a recipient object in multi-domain forest scenario.

Sometimes when you try to run a command you may be prompted with the message like:

This is because by default your Exchange Management Shell is talking to the domain where you have launched it (in the domain where Exchange server or workstation with Exchange tools belongs).

You can easily overcome this by running:

Set-ADServerSettings -ViewEntireForest:$true

I hope this little tip will be helpful today for some of you.

Enjoy

Quick Way to Check if Your AD is Ready For the Next Exchange Upgrade

Hi folks,

Just a quick post where I'd love you to share with you how to quickly check whether your AD is ready for the Exchange server upgrade. As you already know with the new servicing model for Exchange 2013 each CU and SP is a separate build which requires a schema update and a new version of Exchange Server that will come at the end of this year.

As you know Exchange uses AD hardly and it stores and reads information from all the AD partitions. I will not be explaining here what the AD partitions are. You can always read about it here. So when you upgrade your Exchange all the partitions are upgraded to support newer Exchange build.

When you are in separate teams with AD management teams it means that the AD team prepares the AD for you and I will now share with you 3 commands how to quickly check if update was successful for each of them.

To check schema you will need to run:

dsquery * cn=ms-Exch-Schema-Version-Pt,cn=schema,cn=configuration,dc=contoso,dc=com -scope base -attr rangeUpper

To check AD forest update you will need to run:

dsquery * "cn=EXCHORGNAME,cn=Microsoft exchange,cn=services,cn=configuration,dc=contoso,dc=com" -scope base -attr objectVersion"

And finally in each domain where you will deploy Exchange servers or have Exchange recipients you will need to run:

dsquery * "CN=Microsoft Exchange System Objects,DC=contoso,DC=com" -scope base -attr objectVersion"

If the version of each object corresponds to the version of Exchange build you're installing then the AD update has been successful and you can install new Exchange server into your organization. In order to find the version numbers as well as procedure of schema update you can refer this TechNet article.

Enjoy.