Kay Sellenrode's Blog

  Home  |   Contact  |   Syndication    |   Login
  58 Posts | 0 Stories | 42 Comments | 4 Trackbacks

News

Twitter












Tag Cloud


Archives

Post Categories

Image Galleries

Certification

Colleague's

Teched 2007

Thursday, May 8, 2014 #

When you face large Office 365 implementations you might need to add many domains, going through the wizard will take up much time.

Recently I had to work through an extensive list of domains as well, so I created a quick few lines of PowerShell that helped me solve this in seconds instead of hours.
Using PowerShell and an input file I added the domains and additional to that got a list of all DNS txt records that were needed to be created.

Here is the PowerShell script: here is the PowerShell script I used

$domains=import-csv .\domains.csv                                                
$txtrecord=@()                                                                
foreach($domain in $domains){                                                    
new-msoldomain -Name $domain.domain                                                
$txtrecord+=(Get-MsolDomainVerificationDNS -DomainName $domain.domain -mode dnstxtrecord)        
}                                                                        
$txtrecord | select-object text,label,ttl | export-csv c:\temp\txtrecord.csv                
            

This will give you a nice CSV file with the required DNS txt records per domain, which you can send to your DNS gurus to do their thing.

As input file I used a CSV file that was built as following:

Domain            
contoso.com        
Tailspintoys.com    
Fabrikam.com        
Contoso.net        
Tailspintoys.net    
Fabrikam.net        
    

Of course you will need the Windows Azure Active Directory Module to do this.
Find more details at: http://technet.microsoft.com/library/jj151815.aspx

 

 


Saturday, May 3, 2014 #

Recently I designed and implemented a large Office 365 environment, part of it was a Hybrid Exchange 2013 server that should also serve as a central SMTP relay server to 365 and the rest of the world.
Since we didn't want to control a huge list of authorized IP addresses and of course adding complete IP subnets is a bad idea, we chose to use SMTP authentication as our main solution for supporting Mail relaying.

Every office location was assigned a separate account only for this purpose and the credentials were handed out to the IT admin.
In the past I've done this quite often where we configured these accounts as authorized users in Exchange on the receive connector.

But when I configured Exchange 2013 I noticed that the server responded differently from what I expected.
When I added the permissions to the Default Frontend receive connector I could start the process of submitting a message, but once I submitted the data portion of the message I got a reply telling me the user was not authorized to send.
The exact error was: 550 5.7.1 Client does not have permissions to send as this sender


At first I slapped my head because I knew the frontend receive connector should only proxy towards the backend connectors, there all the processing should take place.
All the documentation and even my MCM training taught me that the frontend and backend connectors are tied to each other.
Meaning the "Default Frontend" receive connector would forward towards the "Default" receive connector, and the "Client Frontend" receive connector would forward to the "Client Proxy" receive connector.

So I added the correct permissions for the relay accounts to the "Default Frontend" receive connector, but this didn't resolve the issue of receiving the 5.7.1 error message.
After quite some researching I found out that instead of what I knew of the Receive connectors, these connections were forwarded from the "Default Frontend" receive connector towards the "Client Proxy" receive connector.
Since I also noticed quite some posts on the World Wide Web, were people had the same assumptions and couldn't find a solution I put this blog post together.

So here I outlined the steps required to configure authenticated SMTP relaying in Exchange 2013.

Let's start with the Pre-requirements:

A mailbox enabled account, in my example "testkay"
A group which contains all relay accounts, in my example "Relay Accounts"

So first we will start off with adding the right permissions to the receive connectors.
To allow relaying at the "Default Frontend" receive connector we need the submit to server right assigned to our group "Relay Accounts" no other permissions are required yet.

The following PowerShell Command will set this right for our group.

Get-ReceiveConnector "default frontend*" | Add-ADPermission -User "contoso\relay accounts" -ExtendedRights ms-Exch-SMTP-Submit

For the "Client Proxy" receive connector we need to hand out the actual relay permissions, in our case we allowed the accounts to send from any address to any address but this might be different, see the list below for what each permission gives you.

  • ms-Exch-SMTP-Submit – allow to submit messages (required permission)
  • ms-Exch-SMTP-Accept-Any-Recipient – allow messages to be sent to email addresses unknown to the local server (known as relaying)
  • ms-Exch-SMTP-Accept-Any-Sender – allow sending as any email address that is unknown to the local organization
  • ms-Exch-SMTP-Accept-Authoritative-Domain-Sender – allow sending as any email address that is constructed with the authoritative domain (in our environment contoso.com)
  • ms-Exch-Accept-Headers-Routing – to keep all routing headers in the email, not required but can be nice for troubleshooting.

We picked the all of the above options and set the permissions with the next PowerShell command.

Get-ReceiveConnector "client proxy*" | Add-ADPermission -User "contoso\relay accounts" -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-SMTP-Accept-Any-Recipient,ms-Exch-SMTP-Accept-Any-Sender,
ms-Exch-SMTP-Accept-Authoritative-Domain-Sender,ms-Exch-Accept-Headers-Routing

Ok so we configured the correct permissions now, and that should be enough to allow authenticated relaying of email messages, but reality is that not all devices on our network support NTLM authentication and our TLS encryption.
For our environment it was an acceptable risk to allow basic authentication, and especially for testing purposes this can be helpful as well.

To allow basic authentication we needed to alter the "default frontend" security settings from basic authentication only after offering TLS to allow basic authentication always.
This change can be made using the following PowerShell command

    Get-ReceiveConnector "default frontend*" | Set-ReceiveConnector -AuthMechanism Tls, Integrated, BasicAuth, ExchangeServer

You can notice if basic authentication without TLS is enable when you start a Telnet session and execute the EHLO command, you will receive a response that should list the command "AUTH LOGIN" or "AUTH NTLM LOGIN"

To test from telnet if you can relay you need to encode your username and password to Base64, google will give you several translators to perform this.

 

Here is some additional info to troubleshoot the relaying process.
I use Telnet to test the connection, using the following lines to test the submission of an email with Basic authentication

telnet Exchange2013 25

ehlo

auth login

dGVzdGtheUBjb250b3NvLmNvbQ==

zxvbvmbcnvbcmbxm=

mail from:bla@contoso.com

rcpt to:pietje.puk@hoi.com

data

test

.

 

Since I needed to do some further troubleshooting I also set the ProtocolLoggingLevel for the "Default FrontEnd" receive Connector, "Intra Organizational Send Connectors", "Default" and "Client Proxy" receive connectors to verbose logging. Use the following commands to set each of these.

 

Get-ReceiveConnector "Default FrontEnd*" | Set-ReceiveConnector –ProtocolLoggingLevel Verbose
Get-FrontendTransportService | Set-FrontendTransportService -IntraOrgConnectorProtocolLoggingLevel verbose
Get-ReceiveConnector "Default servername*" | Set-ReceiveConnector –ProtocolLoggingLevel Verbose
Get-ReceiveConnector "Client Proxy*" | Set-ReceiveConnector –ProtocolLoggingLevel Verbose

 

The logs created by these connectors can be found at the following locations (these are the default locations):

  • For the FrontEnd Receive connectors: C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive
  • For the Hub Transport Receive connectors (ie. Default" and "Client Proxy"): C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive
  • For the Intra Organizational Send connectors: C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpSend


Sunday, April 28, 2013 #

Last week I was setting up Lync 2013 with Remote Call Control to a Mitel Live Business Gateway(LBG).
I expected not much had changed from Lync 2010, and the lack for any 2013 procedures took us the 2010 path.

After configuring the Lync environment to talk against the Mitel LBG, surprised I was to see no traffic at all was arriving at the LBG.
Going over the configuration several times and trying a few other things, I finally opened snooper to see what was happening.
The logs showed two interesting pieces of information that caught my attention:

SIPPROXY_E_CONNECTION_MISSING_TLS_TARGET

X.X.X.X is not a local IP

After trying my search karma I quickly found that I wasn't the only one facing this issue, but there wasn't any solution to the issue published online.
So digging further I reached the blogpost of Terence Luk which set me in the right direction, after configuring the identity on the staticroute RCC started working

So the solution to make RCC from Lync 2013 to a Mitel LBG work was to create the static route as following from the Lync command shell.

New-CsStaticRoutingConfiguration -Identity service:Registrar:lyncpool.domain.local

$TLSRoute = New-CsStaticRoute -TLSRoute -Destination lbg01.domain.local -Port 5061 -UseDefaultCertificate $true -MatchUri *.lbg01.domain.local

Set-CsStaticRoutingConfiguration -Identity service:Registrar:lyncpool.domain.local -Route @{Add=$TLSRoute}

 

Watch my blog for a complete configuration guide of the Mitel LBG together with Lync 2013 RCC

 


Friday, February 22, 2013 #

I think many of you have strugled or are now struggling on how to get the Offline Address Book distributed to all CAS servers.
When you try to add a new server to the OAB and you already have a large number of servers in the list of virtual directories it can be quite a pain from the Exchange management console.

It also cost me quite some time to come up with a decent script that was capable of retrieving all the virtual directories and add them to the OAB.
And if you have multiple different Offline Address lists the script might still be useful, see below.

But today I found out that if you want your OAB to be distributed to every CAS server hosting an OAB virtual directory, a new parameter will simplify your life.
This parameter was introduced with Exchange 2010 and automatically will distribute the OAB to each server.

The parameter I'm talking about is GlobalWebDistributionEnabled.

The syntax is simple using the following cmdlet.
Set-OfflineAddressBook –Identity OABname –GlobalWebDistributionEnabled $True

Now when you open the OAB from the Exchange Management Console you will notice that "Web-Based" is listed as a distribution method but not when you open the distribution tab of the property screen.

When you want to add a virtual directory manually you will be prompted with an error stating that you can't due to the globalwebdistribution setting.

The nice part of this setting is, you can now set and forget about updating the virtual directories list.

 

Here is the script I previously used to update the virtual directories, use it at your own risk.

#add all virtual directories to the offline address book.

$oabservers= get-exchangeserver | where {$_.serverrole -like "*clientaccess*"}

$oabdefault="\OAB*"

$oaburls=@()

foreach($oabserver in $oabservers){

    $oabvalue=$oabserver.name + $oabdefault

    $oaburls = $oaburls + $oabvalue

}

set-offlineaddressbook -identity OABName -VirtualDirectories $oaburls


Friday, April 13, 2012 #

I think that almost every Exchange admin can concur with me that the Outlook autocomplete cache is one of those things you love but at the same time also hate.

Users mostly love this function, except when it fails.
Luckily since Outlook 2010 things got a little better and we got rid of the dreaded nk2 files.
Outlook 2010 now includes a folder named "Suggested Contacts", all users you send an email to and that don't already have an contact object are saved in this suggested contacts folder.
A lot of people thought this folder is also the source for the autocomplete cache, which would make it somewhat easy to manage, I wish the solution was that easy.
Badly enough separate from the suggested contacts, outlook still maintains a cache for the autocomplete function.


Let us say you run in to the following situation:

John works for company A and is a popular contact for almost everyone in your organization.
Now John quit his job at Company A and moved to Company B.
Luckily John maintains your company as customer, but his email address is now changed from companyA.com to companyB.com
Since you don't want to do any business with Company A anymore, you want to make sure none of your users accidentally mail to his old address.
Now this is where the real fun starts, cause almost all of your 1000 users have mailed at least once with John.
Resulting in the fact that every user has John most probably listed in their autocomplete cache.

 

I have run into sort like situations multiple times with several customers, which is always a pain.
And of course this blog post is the result of one of those issues once again.
I knew that with the Suggested contacts we could do more than previously, but still never spent time on it before.
But today I thought lets nail this now and forever!!

 

Ok let's start of that things are different for every combination of outlook and exchange.
I explain the procedure for Exchange 2010 SP1+ in combination with Outlook 2010.

At first we want to get rid of all contact objects that contain john@companya.com
To do this we need to be assigned to the RBAC role "Mailbox Import Export", which can be done through the Exchange Control panel.
In my test environment I assigned this role to the Organization admins, but in real life you might want to add it to a custom role.

Open the Exchange control panel by logging in to the ecp url, in my case https://ITFEX.itf.local/ECP, and make sure you selected your organization as management scope.
Browse to Roles & Auditing, and open the properties for the organization management role group.
click on the Add button to add a new role to the Organization Management role group, select the Mailbox Import Export role and click on add and OK to add it to the role.

 

Once you have assigned that role to your account you can open the Exchange Management Shell and execute the following command:

Get-mailbox –resultsize unlimited | search-mailbox –targetmailbox "your.account" –targetfolder searchanddelete –loglevel full –logonly –searchquery "kind:contact AND john@companya.com"

This command will create a list with all mailboxes and any contacts that were found with an email address that contains john@companya.com, this list is then posted in the mailbox you specified at your.account in the folder searchanddelete.
Now examine the report that was created and posted in the mailbox to see if it matches what you think it should match.
My results looked like this:

 

When you're confident that the search includes all references and no false positives you can execute almost the same command, but this time with an delete action instead of the logonly.

Get-mailbox –resultsize unlimited | search-mailbox –targetmailbox "your.account" –targetfolder searchanddelete –loglevel full –DeleteContent –searchquery "kind:contact AND john@companya.com"

Now most people would think this would remove the contact object from the suggested contacts, resulting in a removal from the autocomplete list.
Sad but not true, to clean up the autocomplete list start Outlook with the command: "outlook /cleanautocompletecache"

This will result in an empty cache, but luckily this is rebuild based on the suggested contacts, which now doesn't include the john@companya.com contact anymore.

 

 


Friday, March 23, 2012 #

When Installing Exchange from the command line in a locked down environment I was presented with the following error message on the CAS prerequisites check.

You must be a member of the 'Organization Management' role group or 'Enterprise Admins' group to continue.

When I checked the Organization Management members list, I didn't see my account there but when opening one of the groups that were member I was listed.

One of my first thoughts was, to check if I needed to be a member of the exact group and not a subgroup.
and of course this was the case, so if you run into this issue you need to get yourself added to the Organization Management group directly.

For some organizations this might cause some trouble since they have strict procedures around adding accounts to groups like Organization Management. But at least now you have some proof that hopefully helps


Friday, March 2, 2012 #

A large portion of my work consists of designing Exchange 2010 environments for customers all around the world.
Recently I was working on an assignment where we wanted to implement Exchange UM to replace cisco unity for 23 offices. The whole deployment is planned to run virtualized, this directed me to the specific requirements of UM on virtualization.

This project made it once again clear to me that some good research is valuable even when you think you know your stuff.

What I already knew was that Exchange UM was only supported to be virtualized when it was running on its own, as well as that it required 4 processor cores (with no oversubscription).The requirement that I wasn't 100% sure about, was the memory.
So while doing research on this, I found some contradictory information on this.

If you read the Best Practices for virtualizing Exchange 2010 whitepaper
http://www.microsoft.com/download/en/details.aspx?id=2428
You will notice that the requirement besides 4 Processor cores would be to allocate 16 GB of RAM.

Though when you follow the guidance from the Exchange help at
http://technet.microsoft.com/en-us/library/aa996719.aspx

You will notice the requirements state the following text:
All Exchange 2010 server roles, including Unified Messaging, are supported in a virtual machine. Unified Messaging virtual machines have the following special requirements:

  • Four virtual processors are required for the virtual machine. Memory should be sized using standard best practices guidance.

   

Looking at the standard best practices guidance it will tell you the minimum requirements is 2GB per processor core, doing the calculation for you it makes 8GB as a minimum requirement instead of 16GB.

So I sent out a mail to check what the official support standpoint was, the result is now that the best practices whitepaper has been updated to reflect the guidance from the Exchange help.

So the final requirements for running Exchange 2010 UM on a supported virtualization platform is 4 processor cores (with no oversubscription) and 8 GB of memory.

In my design this saved the customer 184 GB of memory, worth spending some time on.