Categories
2010 bpos exchange exchange online hybrid Office 365

Office 365 Hybrid Coexistence and Edge Server

One of the delights in my job is when Microsoft give me a call and ask me how something works in one of their products! Such a call came today and it involved get Office 365 hybrid coexistence working with an Edge Server.

Exchange Server Deployment Assistant does not have the answer to this issue; it always refers to a Hub Transport server within the organization. But it was an interesting challenge, as the last time I tried to get this working I got a “a local loop detected” error.

In brief, its is possible to use Edge Server as the coexistence server between your organization and your Office 365 tenant, you just need to make sure that everything you would create on the Hub Transport is either configured on the Edge Server (receive connectors and certificates) or created within the organization and replicated to the Edge Server via EdgeSync (send connectors, remote domains, accepted domains).

The reason for “a local loop detected” error was down to having the service domain for the Office 365 tenant configured as Internal Relay (as it needs to be) and not having a Send Connector on the Edge Server that pointed to the Office 365 infrastructure.

Update 26 Oct 2011

In the above I wrote that the Office 365 tenant domain as configured on-premises needs to be internal relay. This is only required if your on-premises org contains Exchange 2003. If the minimum version of Exchange installed on-premises is 2007 then the domain can be Authoritative. This is because with 2007+ you can forward emails to an authoritative domain using contact or remote-mailbox objects and a send connector for the domain.

Categories
2010 active directory exchange exchange online powershell

Hub Transport Load Balancing

In Exchange 2010 (not SP1) and Exchange 2007 there was no memory of unavailable transport servers and so the round robin method of load balancing across the hubs in the target delivery site or smarthosts used by connectors sourced to your current server was just that – round robin.

Though if a server was unavailable the next server in the list was selected and connected to and the first server in the list was moved to the end of the list of servers to use. This resulted in an uneven distribution of load when servers were offline. Imagine the scenario where you have three hub transports in the London Active Directory site (HL1, HL2 and HL3) which were installed in that order. A Hub Transport server in another AD Site will deliver up to 20 messages per connection and will make the connections in a round robin fashion. Therefore if HL1 is offline the connection will automatically be made to HL2. Upon completing the connection the first server in the list will be moved to the end of the list – in this example HL1 will move to the back of the list.

The next connection to the London site will use the list HL2, HL3, HL1 for delivery, and as HL2 is running will connect to HL2 and deliver its email and move HL2 to the back of the list. The third connect will go to HL3. The fourth connection will attempt to reach HL1 and fail, so deliver to HL2 and move HL1 to the back of the list.

The result of this is that HL2 will get 66% of email delivered to HL3’s 33% and not a 50/50 distribution once one server is down. When all servers in the site are operational the distribution will be 1/3 of connections each and even load balancing.

Exchange 2010 SP1 records downed servers in a separate list which it will attempt to connect to on a separate sequence (unrelated to email delivery). So taking the above example and HL1 is offline (again) and the source server is Exchange 2010 SP1 it will fail to connect and deliver to HL2, move HL2 to the bottom of the list and remove HL1 from the available servers list. Therefore HL2 and HL3 will get 50% of connections each – no overloading of the next hub in install order.

The source Exchange 2010 SP1 server will maintain this list of unavailable servers and will attempt to connect to the unavailable server regularly. It does this once a minute for four minutes (known as the QueueGlitchRetryCount and  QueueGlitchRetryInterval), then it changes to TransientFailureRetryCount and TransientFailureRetryInterval, which is six times, once every five minutes. After 35 minutes going through the Glitch and Transient retry intervals Exchange will only attempt to connect once every 10 minutes (the OutboundConnectionFailureRetryInterval value) or 15 minutes if on an Edge Transport server.

Once the server is online again it is added back into the round-robin load-balancing list for connections to remote sites or smarthost endpoints. This does mean though that if a server is offline for more than 35 minutes it will be up to 10 minutes before Exchange 2010 SP1 attempts to connect to it for transport and email delivery.

To see which servers are on your unavailable list run Get-ExchangeDiagnosticInfo -Process EdgeTransport -Component SmtpOut -Argument verbose . The Get-ExchangeDiagnosticInfo cmdlet is covered further in my next blog today.

Categories
2010 ADFS ADFS 2.0 certificates exchange exchange online federation Office 365 organization relationships owa powershell

OWA and Moving Mailboxes to Office 365

Lets imagine a scenario where you are using an on-premises Exchange Server and users’ use Outlook Web App, and then you move some mailboxes to the Office 365 cloud with Hybrid Coexistence enabled. The user might not know their mailbox has been moved and so yesterday they went to https://mail.company.com/owa, but today they need to visit https://outlook.com/owa/company.com (where company.com is the domain name in your login name).
But becuase the user does not know that their mailbox has been moved when they visit https://mail.company.com/owa they get an error that their OWA URL is out of date.
To fix this, and provide the user with the correct URL (https://outlook.com/owa/company.com) then you need to set the TargetOwaURL property of the Organization Relationship that you have configured for your Office 365 service domain.

Set-OrganizationRelationship name -TargetOwaURL https://outlook.com/owa/company.com

Now when users login with an account that has been moved to the cloud they will be told that their mailbox has moved, and that they should visit https://outlook.com/owa/company.com.
Some organizations though have an issue with this URL – it does not mention the company name in the domain name bit, and a name such as http://webmail.company.com/owa would be preferred for mailboxes moved to the cloud. To present the user with this URL after they login to on-premises OWA or for a URL that you can just tell them to use you need to do two things:

  1. Create a CNAME record in DNS for webmail that has outlook.com as the target FQDN. The CNAME record can be anything that is not already in use for the domain (for example it could be mail if that is not in use).
  2. The TargetOwaURL property of the Organization Relationship needs to be http://webmail.company.com/owa. The TargetOwaURL must finish with /owa or the on-premises OWA redirect page will error and the domain name used must be the domain name in your login name.

The outlook.com server will take the CNAME value provided by the browser and do realm discovery on this name – that is it will redirect you to the correct login server for your domain.

Categories
2010 exchange exchange online federation licence mcm Office 365

Assign Specific Licences in Office 365 Via PowerShell

 

To add specific licences to users in Office 365 without using the portal, and to assign subsets of the licences available requires two things. First you need to enumerate the licences and licence service plans, then you need to assign the new plan you have created to your users. This can be performed in bulk and is repeatable unlike when using the portal.
First, enumerate the licence plans and create your own licence:

  1. Open Microsoft Online Services Module for Windows PowerShell and connect to the service
    • $cred = Get-Credential
    • Connect-MsolService -Credential $cred
  2. Get-MsolAccountSku | Format-Table AccountSkuId, SkuPartNumber
    • The second column in this list is referenced in the next command as [SkuPartNumber]
  3. $ServicePlans = Get-MsolAccountSku | Where {$_.SkuPartNumber -eq “[SkuPartNumber]”}
  4. $ServicePlans.ServiceStatus
    • This returns all the service plans
  5. $MyO365Sku = New-MsolLicenseOptions -AccountSkuId [tenantname:AccountSkuId] -DisabledPlans Comma_Seperated_List_From_ServicePlans_Output

Secondly you need to assign the licence to the user(s):

  1. Set-MsolUser -UserPrincipalName user@domain.com -UsageLocation GB
  2. Set-MsolUserLicense -UserPrincipalName user@domain.com -AddLicenses [tenantname:AccountSkuId] -LicenseOptions $MyO365Sku
  3. Repeat for any other licences you want to apply for other users or other licence options you want to apply to this user.

For reference, the SkuPartNumber’s that we discovered are:

Inside ENTERPRISEPREMIUM_NOPSTNCONF (E5 without PSTN Conferencing) Sku:

  • EQUIVIO_ANALYTICS
  • LOCKBOX_ENTERPRISE
  • EXCHANGE_ANALYTICS
  • SWAY
  • ATP_ENTERPRISE
  • MCOEV
  • BI_AZURE_P2
  • INTUNE_O365
  • PROJECTWORKMANAGEMENT
  • RMS_S_ENTERPRISE
  • YAMMER_ENTERPRISE
  • OFFICESUBSCRIPTION
  • MCOSTANDARD
  • EXCHANGE_S_ENTERPRISE
  • SHAREPOINTENTERPRISE
  • SHAREPOINTWAC

Inside ENTERPRISEPREMIUM (E5) Sku:

  • EQUIVIO_ANALYTICS
  • LOCKBOX_ENTERPRISE
  • EXCHANGE_ANALYTICS
  • SWAY
  • ATP_ENTERPRISE
  • MCOEV
  • BI_AZURE_P2
  • INTUNE_O365
  • PROJECTWORKMANAGEMENT
  • RMS_S_ENTERPRISE
  • YAMMER_ENTERPRISE
  • OFFICESUBSCRIPTION
  • MCOSTANDARD
  • EXCHANGE_S_ENTERPRISE
  • SHAREPOINTENTERPRISE
  • SHAREPOINTWAC
  • MCOMEETADV (PSTN Conferencing)
  • BPOS_S_TODO_2 (To Do)
  • FLOW_O365_P2 (Flow)
  • FORMS_PLAN_E3
  • POWERAPPS_O365_P3
  • STREAM_O365_E3
  • TEAMS1

Inside ENTERPRISEPACK (E3) Sku:

  • YAMMER_ENTERPRISE (Yammer – though you cannot apply this individually or disable it individually, so ignore it for the purposes of this script)
  • OFFICESUBSCRIPTION (this is Office Professional Plus)
  • MCOSTANDARD (this is Skype for Business Online)
  • SHAREPOINTWAC (this is Office Web Apps)
  • SHAREPOINTENTERPRISE
  • EXCHANGE_S_ENTERPRISE (Exchange Plan 2)
  • RMS_S_ENTERPRISE (Azure Rights Management)
  • INTUNE_O365 (Mobile Device Management for Office 365)
  • SWAY
  • BPOS_S_TODO_2 (To Do)
  • FLOW_O365_P3 (Flow)
  • FORMS_PLAN_E5
  • POWERAPPS_O365_P3
  • STREAM_O365_E5
  • TEAMS1
  • MCOEV
  • LOCKBOX_ENTERPRISE
  • BI_AZURE_P2
  • THREAT_INTELLIGENCE
  • EQUIVIO_ANALYTICS

Inside Enterprise Mobility Pack (EMS)

  • RMS_S_PREMIUM
  • INTUNE_A
  • RMS_S_ENTERPRISE
  • AAD_PREMIUM
  • MFA_PREMIUM

Inside ENTERPRISEPACKWITHOUTPROPLUS sku

  • YAMMER_ENTERPRISE
  • SHAREPOINTWAC
  • SHAREPOINTENTERPRISE
  • RMS_S_ENTERPRISE
  • MCOSTANDARD
  • EXCHANGE_S_ENTERPRISE
  • INTUNE_O365

Inside DESKLESSWOFFPACK Sku:

  • SHAREPOINTWAC
  • SHAREPOINTDESKLESS
  • EXCHANGE_S_DESKLESS

Inside EXCHANGESTANDARD sku

  • INTUNE_O365
  • EXCHANGE_S_STANDARD

Inside EXCHANGEENTERPRISE sku

  • INTUNE_O365
  • EXCHANGE_S_ENTERPRISE

Inside EXCHANGEARCHIVE Sku

  • EXCHANGE_S_ARCHIVE

Inside P1 (Small Business) Tenants

  • MCOLITE
  • SHAREPOINTLITE
  • EXCHANGE_L_STANDARD

Inside K1 – DESKLESSPACK

  • SHAREPOINTDESKLESS
  • EXCHANGE_S_DESKLESS

Inside K2 – DESKLESSWOFFPACK

  • SHAREPOINTWAC
  • SHAREPOINTDESKLESS
  • EXCHANGE_S_DESKLESS

Inside P1 – LITEPACK

  • MCOLITE
  • SHAREPOINTLITE
  • EXCHANGE_L_STANDARD

Inside E1 – STANDARDPACK

  • MCOSTANDARD
  • SHAREPOINTSTANDARD
  • EXCHANGE_S_STANDARD

Inside E4 – ENTERPRISEWITHSCAL

  • YAMMER_ENTERPRISE
  • OFFICESUBSCRIPTION
  • MCOSTANDARD
  • SHAREPOINTWAC
  • SHAREPOINTENTERPRISE
  • EXCHANGE_S_ENTERPRISE
  • RMS_S_ENTERPRISE

Inside PowerBI Standalone (POWER_BI_STANDALONE)

  • YAMMER_ENTERPRISE
  • SQL_IS_SSIM
  • BI_AZURE_P1
  • SHAREPOINTENTERPRISE

Inside Project Online (PROJECTONLINE_PLAN_1)

  • SWAY
  • SHAREPOINT_PROJECT
  • SHAREPOINTWAC
  • SHAREPOINTENTERPRISE

Inside Project Lite (PROJECTESSENTIALS)

  • SWAY
  • SHAREPOINTWAC
  • SHAREPOINTENTERPRISE
  • PROJECT_ESSENTIALS

Inside Academic A2 Plans

  • SHAREPOINTWAC_EDU
  • MCOSTANDARD
  • SHAREPOINTSTANDARD_EDU
  • EXCHANGE_S_STANDARD

Inside Medium Business Sku (contoso:MIDSIZEPACK)

  • SHAREPOINTWAC
  • OFFICESUBSCRIPTION
  • EXCHANGE_S_STANDARD_MIDMARKET
  • SHAREPOINTENTERPRISE_MIDMARKET
  • MCOSTANDARD_MIDMARKET

PowerBI Standard (POWER_BI_STANDARD)

  • BI_AZURE_P0

Visio Pro for Office 365

  • VISIOCLIENT

Project Pro for Office 365

  • PROJECTCLIENT

Skype for Business PSTN Conferencing

  • MCOMEETADV

Skype for Business PSTN Domestic and International Calling

  • MCOPSTN2

Skype for Business Cloud PBX

  • MCOEV

Microsoft Dynamics CRM Online internal use rights (IUR) benefit for MPN members

  • CRMIUR

Windows 10 Enterprise E5

  • WIN10_PRO_ENT_SUB
  • WINDEFATP

 

With thanks to Donte Henry (Avanade) and Tim Heeney (Microsoft). Discovered during the Office 365 MCM Class for Exchange 2010 MCM’s.

Updated June 2014 with the findings of some of those who added comments below. Note that some comments say you need to have an array for disabled plans – this is not what I find when I run the above.

Updated Feb 2015 with more licence pack data.

Updated June 2015 with more licence pack data (INTUNE_O365)

Updated Dec 2015 with E5/NOPSTN and new standalone licence skus

Updated Feb 2016 with E5 and PSTN Conferencing

Updated May 2016 with Skype for Business Cloud PBX and some Dynamics CRM

Categories
2010 cloud exchange exchange online Office 365 windows 2008

Office 365 and Dynamic Distribution Groups

Updated Dec 8th 2011 to remove reference to LegacyExchangeDN

In Office 365 with Hybrid Deployment, if you create Dynamic Distribution Groups on the on-premises Exchange organization, these objects are not replicated to Office 365 via DirSync. Therefore for mailboxes in the Office 365 cloud they will not see the Dynamic Distribution Group in their Global Address List, and so therefore can only email the members of the list by sending an email directly to their email address.
To show the Dynamic Distribution Group in the GAL in the cloud, you need to add a MailContact to the cloud that represents the Dynamic Distribution Group. This MailContact object should have the following mappings:

On-Premises DDL Cloud MailContact
Name Name
proxyAddress ExternalEmailAddress
Alias Alias

Note that this MailContact object is made in Office 365 or Exchange Online and not in the on-premises AD. It is not replicated to the cloud via DirSync. If it exists on premises then the name for the DDL will appear twice in the on-premise GAL, once as a DDL and once as a contact object.
To determine the information need for the cloud contact object, run the following in Exchange Management Shell on premises:

Get-DynamicDistributionGroup | fl Name,EmailAddresses,LegacyExchangeDN

An alternative is to create the DDL in both the cloud and on-premises, but this can only happen if the attributes you are filtering on on-premises are replicated to the cloud via DirSync.

Categories
exchange exchange online Office 365 powershell

Migrate to Office 365 Using the Command Line

Cutover Migrations and Staged Simple Exchange Migrations from on-premise and hosted email systems can be done by the remote PowerShell command line (Powershell to Exchange Online). The help for New-MigrationBatch claims that migrations from Hotmail are possible, but the actual commands are not working at this time.
Doing a migration via the command line is possible, and is documented below, but if you can do it via Exchange Control Panel it is considerably easier.
To migrate you need to create a migration connection string. This is done with Test-MigrationServerAvailability. Once you have this object you can use it in the migration with New-MigrationBatch.
To grant access to one user account to all mailboxes perform the following in Exchange Management Shell:

  • Get-Mailbox | Add-MailboxPermission -User domain\user -AccessRights FullAccess

To connect to Exchange Online do the following:

  1. Start the Windows Powershell
  2. $cred=Get-Credential tenant_admin@tenant.onmicrosoft.com
  3. $EOSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/PowerShell/ -Credential $Cred -Authentication Basic -AllowRedirection
  4. Import-PSSession $EOSession -AllowClobber

To perform the migration do the following:

  1. $MigrationSettings = Test-MigrationServerAvailability -Exchange -Credentials (Get-Credential) -ExchangeServer internal-exchange-fqdn -RPCProxyServer external-outlook-anywhere-fqdn
  • Enter credentials of account that has FullAccess rights to all mailboxes
  • New-MigrationBatch -Exchange -Name unique-name-for-migration  -ExchangeConnectionSettings $MigrationSettings.ConnectionSettings -MaxConcurrentMigrations 10 -TimeZone “Pacific Standard Time”
  • Start-MigrationBatch

 

To see the status of the migration do one of the following:

  • Get-MigrationBatch OR Get-MigrationStatus

Once the migration has completed (Get-MigrationBatch | Format-List Status shows Completed) then complete the migration to finish:

  • Complete-Migration
Categories
exchange exchange online Office 365

Enable-OrganizationCustomization

Exception has been thrown by the target of an invocation is an error you can see in Office 365 Rich Coexistence when you are first configuring the settings.
This is due to the hydration status of your tenant at Office 365. Each Office 365 tenant is not “hydrated” by default. Hydration is the adding of lots of settings in the Exchange Online directory service per tenant – by default lots of tenants do not need these settings and so rather than creating the settings per tenant, each tenant shares these common settings.
To enable your own Transport Rules, Free/Busy Rich Coexistence and custom RBAC settings require that all the “common” settings in the directory are copied to the tenants area of the directory. To do this means you need to run the Enable-OrganizationCustomization cmdlet in remote PowerShell to Exchange online.
Once this is done the GUI will create RBAC, rules, free/busy etc. without throwing Exception has been thrown by the target of an invocation error.
The exact steps to perform on your Office 365 tenant before configuring RBAC, rules or coexistence are as follows:

  1. Start the Windows Powershell
  2. $cred=Get-Credential tenant_admin@tenant.onmicrosoft.com
  3. $EOSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/PowerShell/ -Credential $Cred -Authentication Basic -AllowRedirection
  4. Import-PSSession $EOSession  -AllowClobber
  5. Enable-OrganizationCustomization
Categories
ADFS 2.0 cloud exchange exchange online mcm Office 365 proxy

Adding Servers to ADFS 2.0 Farms – Subject Alternative Name Issues

When you add additional servers to an ADFS 2.0 farm and you have used a subject alternative name from your certificate to create the first server in the farm the additional servers will not be able to join the farm. If you have used the subject name on the certificate all works fine.
You get the following error message:

The Subject name of the SSL certificate for the Default Web Site on this computer should match the name of the Federation Service to which you are trying to join this computer.

You also get the following error:

No certificates matching the Federation Service name were found in the Local Computer certificate store. Install the certificate that represents your Federation Service name in the Local Computer certificate store, and then try again.

The help file for ADFS 2.0 says “the actual name text is determined by either the Subject field or, if necessary, the Subject Alternative Name field of the certificate”, but the addition of additional servers does not work if you have used a Subject Alternative Name.
So how do you get around this. With thanks to Tim Heeney and Roberto Martinez Lima from Microsoft and the rest of the class on the inagural Office 365 Microsoft Certified Master class (a subset of the Exchange 2010 MCM program) we worked out the answer. You need to install the additional servers from the command line – the problem is a user interface bug in the ADFS 2.0 setup program.

FsConfig.exe JoinFarm /PrimaryComputerName ADFS-SRV-1 /ServiceAccount fabrikam\adfsservice /ServiceAccountPassword password /CertThumbprint “ef 72 a6 78 c0 ab 4a bf 07 10 7e e4 86 f5 5e ba 2a 3c 99 6b”

The thumbprint needs to be the thumbprint of the certificate used on the first ADFS server and imported into the computer certificate store on the additional ADFS servers.
On running the FsConfig command above you should get a series of green Passed statements. Existing databases can be removed with /CleanConfig switch. A yellow warning about an existing website can be ignored unless you have broken the website previously!

Categories
exchange exchange online Office 365

Mismatched Archive GUID for Moving Archive to Office 365

If you create an archive in Office 365 for a mailbox on-premise you might find that it does not work – the actual archive is not (as of time of writing) created correctly. What’s the way around it? The way around it is to create the archive on-premise and then move the archive to the cloud.

But you get this error message:

Recipient ‘Aaron Con’ has mismatched archive GUID (19ec252e-00b2-463f-b9b4-7012fabfa60e). Expected value: 00000000-0000-0000-0000-000000000000.
Click here for help… http://technet.microsoft.com/en-US/library/ms.exch.err.default(EXCHG.141).aspx?v=14.1.218.11&t=exchgf1&e=ms.exch.err.Ex71CCCD
Exchange Management Shell command attempted:
‘c607a1af-5608-424d-8ea1-447dcad60003’ | New-MoveRequest -Remote -ArchiveOnly -RemoteHostName ‘mail.fabrikam.student027.mcmexch.ms’ -ArchiveDomain ‘o365.fabrikam.student027.mcmexch.ms’

This is caused because the archive has been created on-premise and then before this change is synchronised to the cloud the move occurs. The actual steps to do the above are as follows:

  1. Create local archive
  2. Synchronise changes to the cloud
  3. Move the archive to the cloud
  4. Wait until the move request completes (run Get-MoveRequest identity via Remote PowerShell to Exchange Online)
  5. Check that archive in cloud is provisioned with Get-MailUser identity | FL *archive* run via Remote PowerShell to Exchange Online. This will take a few minutes before the ArchiveDatabase value is populated.
  6. Synchronise changes again, so that the changes in the cloud are pushed back to on-premise
  7. Login as the user and access the cloud archive.
Categories
2010 2013 64 bit active directory ADFS ADFS 2.0 certificates exchange exchange online https isa mcm microsoft Office 365 pki tmg

Publishing ADFS Through ISA or TMG Server

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:

  1. New Web Site Publishing Rule. Provide a name.
  2. Select the Action (allow).
  3. Choose either a single website or load balancer or use ISA’s load balancing feature depending on the number of ADFS servers in your farm.
  4. Use SSL to connect:
    image
  5. Enter the Internal site name (which must be on the SSL certificate on the ADFS server and must be the same as the externally published name as well). Also enter the IP address of the server or configure the HOSTS files on the firewall to resolve this name as you do not want to loop back to the externally resolved name:
    image
  6. Enter /adfs/* as the path.
  7. Enter the ADFS published endpoint as the Public name (which will be subject or SAN on the certificate and will be the same certificate on the ADFS server and the ISA Server):
    image
  8. Select or create a suitable web listener. The properties of this will include listening on the external IP address that your ADFS namespace resolves to, over SSL only, using the certificate on your ADFS server (exported with private key and installed on ISA Server), no authentication.
  9. Allow the client to authenticate directly with the endpoint server:
    image
  10. All Users and then click Finish.
  11. Before you save your changes though, you need to make the following two changes
  12. Right-click the rule and select Configure HTTP:
    image
  13. Uncheck Block high bit characters and click OK.
  14. Double-click the rule to bring up its properties and change to the Link Translation tab. Uncheck Apply link translation to this rule:
    image
  15. Click OK and save your changes.

ADFS should now work through ISA or TMG assuming you have configured ADFS and your partner organisations correctly!

To test your ADFS service connect to your ADFS published endpoint from outside of TMG and visit https://fqdn-for-adfs/adfs/ls/idpinitiatedsignon.aspx to get a login screen

Categories
exchange exchange online Office 365 powershell

PowerShell Script To Update All UPN’s

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 Coexistence (Hybrid) scenarios which require that the UPN (User Principal Name) for each account matches their email address.
Optionally you can add the UPN that you are going to use (your verified vanity domain in Office 365) to Active Directory Domains and Trusts. Adding the UPN extension to Active Directory Domains and Trusts allows you to select the UPN extension whilst creating users in this program, but you do not need to add the extension to Domains and Trusts to change a users UPN using the below script.
To run the script copy the below to a text file, saving it as Update-UPN.ps1. Change Then run this script from an Exchange Management Shell.
$upnExt = Read-Host “Please enter your UPN extension (excluding @)”$users = Get-User * -ResultSize Unlimited    
foreach($user in $users)
{
$UPN = “$($user.sAMAccountName)@” + $upnExt
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.

Categories
2007 2010 2013 ADFS ADFS 2.0 certificates exchange exchange online https hybrid IAmMEC ISA Server 2006 mcm Office 365 SSL tmg

Changing ADFS 2.0 Endpoint URL for Office 365

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:

image

Click Edit Federation Service Properties in the Action Pane and modify the three values on the General tab:

image

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.

image

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.

Categories
2007 2010 2013 exchange exchange online IAmMEC mcm mcsm

Random Chinese Characters in Exchange 2010 SP1 Emails

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 area of the file the following

 

After you save the config file you need to restart the Microsoft Exchange Transport service for the setting to take effect.