Using Active Directory Module for Windows Powershell (part of Windows 2008 R2 Active Directory and downloadable for earlier versions of AD) use the following cmdlet to set all your user to have non-expiring passwords. Great for lab environments:
Get-ADUser | Set-ADAccountControl –PasswordNeverExpires $True
Or indeed, not working at all! I had the issue of it working one way only (On-Premise Exchange organization > Office 365) but the other way (cloud to on-premise) did not work at all.
The answer is shown in this video
http://www.microsoft.com/showcase/en/us/details/a16a9d39-416a-4b01-a88f-5ff511580424
This covers the reasons why Free/Busy (and the other federation features of MailTips, archive and move mailbox might not work both ways in a Hybrid Coexistence setup for Office 365 or between two Exchange on-premise organizations.
The reason I found was the Organization Relationship contained the wrong list of domains. There are three domains (at least) that are needed in the organization relationship. These are:
In the organization relationship on-premise (or Org A if you are doing two on-premise organizations) set the following domains after the relationship is created. This includes the primary SMTP namespace and the service namespace for the other organization. This can be set with the following Exchange Management Shell cmdlet:
Set-OrganizationRelationship -Identity "To Cloud" -DomainNames "service.fabrikam.com","fabrikam.com" -MailTipsAccessEnabled $True -MailTipsAccessLevel All -DeliveryReportEnabled $True –TargetOwaUrl https://outlook.com/owa/fabrikam.com -ArchiveAccessEnabled $True –MailboxMoveEnabled $True
In Org B (or on Office 365) use a similar cmdlet, but use the Exchange Delegation namespace and the primary SMTP domain. Also Office 365 does not let you set the MailboxMoveEnabled property to $True
Set-OrganizationRelationship -Identity "To On-premises" -DomainNames "exchangedelegation.fabrikam.com","fabrikam.com" -MailTipsAccessEnabled $True -MailTipsAccessLevel All -DeliveryReportEnabled $True -ArchiveAccessEnabled $True
Supposedly Service Pack 2 for Exchange 2010 will do all this and more for you with the Hybrid Configuration Wizard, but its always useful for troubleshooting to discover what changes and why when you run a wizard to do things!
To configure the CRM Email Router with Exchange 2010 you need to do the following. Not all of these points are clearly documented on the internet.
New-ManagementRoleAssignment –Name: "ApplicationImpersonation-CRM Router" -User: "CRM_Router@domain.com" –Role:"ApplicationImpersonation"
To enable single sign-on in Office 365 and a variety of other applications you need to provide a federated authentication system. Microsoft’s free server software for this is currently Active Directory Federation Server 2.0 (ADFS), which is downloaded from Microsoft’s website.
ADFS is installed on a server within your organisation, and a trust (utilising trusted digital certificates) is set up with your partners. If you want to authenticate to the partner system from within your environment it is usual that your application connects to your AFDS server (as part of a bigger process that is better described here: http://blogs.msdn.com/b/plankytronixx/archive/2010/11/05/primer-federated-identity-in-a-nutshell.aspx). But if you are outside of your organisation, or the connection to ADFS is made by the partner rather than the application (and in Office 365 both of these take place) then you either need to install ADFS Proxy or publish the ADFS server through a firewall.
This subject of the blog is how to do this via ISA Server or TMG Server. In addition to configuring a standard HTTPS publishing rule you need to disable Link Translation and high-bit filtering on the HTTP filter to get it to work.
Here are the full steps to set up AFDS inside your organisation and have it published via ISA Server – TMG Server is to all intents and purposes the same, the UI just looks slightly different:
ADFS should now work through ISA or TMG assuming you have configured ADFS and your partner organisations correctly!
This quick script will process all your user accounts in the domain and change the UPN for each of them to a new one, which you need to specify in the script in advance of running it. This script is useful for Office 365 Rich Co-Existence scenarios which require that the UPN (User Principal Name) for each account matches their email address.
Before running the below, add the UPN that you are going to use (your verified vanity domain in Office 365) to Active Directory Domains and Trusts and then copy the below to a text file, saving it as Update-UPN.ps1. Then run this script from an Exchange Management Shell.
$users = Get-User * -ResultSize Unlimited
foreach($user in $users)
{
$UPN = "$($user.sAMAccountName)@new.upn"
Write-Host "Setting " $UPN
$user | Set-User -UserPrincipalName $UPN
}
Tip: Comment out the Write-Host line with # if you do not want feedback on each user changed – it will make the script go much faster
Tip: For testing purposes change the * in the first line to the name of a test user or do something like test* to change all users starting with the word “test” in their username.
If you are configuring single sign-on for Office 365 then you will need a server running Active Directory Federation Services 2.0 (ADFS 2.0). When you install this you are asked for a URL that acts as an endpoint for the ADFS service, which if you are publishing that endpoint through a firewall such as TMG needs to be on a mutually trusted certificate as either the subject name or alternative subject name.
The documentation uses sts.yourdomain.com which means you need to have this as a valid name of the certificate. I use StartCom SSL, which provide cheap certificates (approx. $100 for as many certificates as you like), but to change a certificate to add an additional alternative subject name requires revoking the current cert, and that comes at additional cost.
So I have a certificate with lots of name on it for my domain, just not sts.mydomain.com so I set about changing the endpoint in ADFS 2.0
Firstly open the ADFS 2.0 administrative console and select the root note:
Click Edit Federation Service Properties in the Action Pane and modify the three values on the General tab:
After clicking OK, restart the AD FS 2.0 Windows Service.
After the restart, create a new Token-Signing Certificate and Token-Decrypting Certificate. These are self signed certificates. To allow you to add these you need to turn off automatic certificate rollover if enabled. This can be done from PowerShell using Set-ADFSProperties –AutoCertificateRollover $false and this cmdlet is available in Windows PowerShell Modules in the Administrative Tools menu.
To update Office 365 start the Microsoft Online Services Module for Windows PowerShell, installed as part of the Office 365 rich co-existence process. In this PowerShell window type Update-MsolFederatedDomain –DomainName yourFederatedDomain.com. You will also need to login to Office 365 in this window first (Connect-MsolService) and set PowerShell with the name of the ADFS server (Set-MsolADFSContext –Computer ADFS_ServerName). Type Get-MsolFederatedDomain –DomainName yourFederatedDomain.com to ensure that the returned URL’s and certificates are correct.
Now its time to update the TMG rule, or create a new one. The listener in TMG must have the same third party certificate and be for HTTPS with the Public Name matching the certificate subject/subject alternative name and the Path value set to /adfs/*. The To page needs to be set with the same URL and internal IP address of the ADFS 2.0 server.
And that should be it – after the Update-MsolFederatedDomain –DomainName yourFederatedDomain.com has completed both sides of the federation trust are aware of the certificate change and automatic login to http://outlook.com/yourFederatedDomain.com should work.
If you require delegates to approval all room bookings in Exchange 2010 and you have the following two settings set to True then rooms will automatically be approved
To require that rooms are approved by the delegate regardless of when the room is booked set AllRequestOutOfPolicy to False.
These settings require that AllBookInPolicy is False and that BookInPolicy and RequestInPolicy are both null.
You download and begin to install an Exchange Rollup Update only to find after waiting ages for it do the NGen stuff it fails, and on watching it closely you notice it fails on stopping services.
In the event log you are pointed at a website with information on verbose logging for MSI installations.
But you can forget that – the fix is easy! Start and administrative command prompt and run the rollup update from the command line! It will work first time (as long as the update msi file is actually copied to the local machine, it will typically not run from a copy on a network drive.
During a configuration of Blackberry Enterprise Server today I found that I was getting .DLL errors when trying to create a MAPI profile on the BES Server (v5.0.2) when running IEMSTest.
Well it was not the usual stuff – it ended up being the alias that had been assigned to the BESAdmin account. The policy at the company where I am installing Exchange 2010 is last_first@domain.com, but the BESAdmin account does not have a first or last name and so got an email address of _9c73@domain.com, and so though I could login in OWA, I could not do a MAPI login (IEMSTest or Outlook – because the alias was not BESAdmin as they default to).
Once I changed the SMTP Address to BESAdmin@domain.com then it all worked fine.
I have been sent a few emails from a client that start like this:
格tml> 格ead> 猼tyle㰾!-- .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 10pt; font-family:Tahoma } -->⼼style> ⼼head> 㰊body class='hmmessage'>
The HTML characters repeat throughout the message, but not on every message, though those sent from Hotmail are typically affected (but it is not always Hotmail).
The problem is due to the email having character encoding in the charset META tag that differs from the character encoding in the MIME part and a HTML disclaimer having been added. When Exchange 2010 SP1 adds the HTML disclaimer it re-encodes the message and this results in a corrupt message because the wrong character set information is read.
The fix for this has been documented in KB969129, which refers to Exchange 2007, but the same fix is true for Exchange 2010 SP1.
The fix is to add the DisableDetectEncodingFromMetaTag attribute to EdgeTransport.exe.config. This file can be found at \Program Files\Microsoft\Exchange Server\V14\bin and can be opened in Notepad. Make a backup of the file before you change it and then add to the <appsettings> area of the file the following
<add key="DisableDetectEncodingFromMetaTag" value="true" />
After you save the config file you need to restart the Microsoft Exchange Transport service for the setting to take effect.
