Running a DirSync from a remote computer

If you wish to force a manual synchronisation from a remote computer, a remote command must be issued to the Dirsync Server.

We have created a script to aid this, but it needs basic modification before it will work in your environment.

Unsigned scripts must be enabled on the remote computer by running the powershell command ‘set-executionpolicy Unrestricted’.

Variables need to be set inside the script for the servername, user account to connect to the dirsync server, path to store the credential file and the credentials file name.

This script will do the following;

  • Check if the stored credential path exists, and if it doesn’t – it will perform the following
    1. Create the path
    2. Enable Powershell Remoting
    3. Add the DirSync server to the allowed remote hosts
    4. Restart the WinRM Server
  • Check if the credential file exists and if it doesn’t prompt for credentials and store them as a secure string in the file specified (this must be done on a per-user basis, the credential file cannot be copied to another user).
  • Use the stored credential to connect to the Dirsync server and initiate the command.

The powershell script is below:

#Attributes

$DirsyncServer = "dirsync-server.fqdn"  # FQDN of the Dirsync Server

$AdminName = "domain\username"  # User account with permissions to the server

$path = "C:\Dirsync credential\" # The Folder to store the credentials (with the trailing \)

$CredsFile = $path + "Dirsync-PowershellCreds.txt" # The file that will contain the securestring

#Check for Stored Credentials

 if((Test-Path $path) -eq 0)

    {

        #First run: Create the path & enable PSRemoting   

        mkdir $path;

        Enable-PSRemoting -Force

        Set-Item WSMAN:\localhost\client\trustedhosts $DirsyncServer

        Restart-Service WinRM

    }

$FileExists = Test-Path $CredsFile

if  ($FileExists -eq $false) {

    Write-Host 'Credential file not found. Enter your password:' -ForegroundColor Red

    Read-Host -AsSecureString | ConvertFrom-SecureString | Out-File $CredsFile

    $password = get-content $CredsFile | convertto-securestring

    $Cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $AdminName,$password}

else

    {Write-Host 'Using your stored credential file' -ForegroundColor Green

    $password = get-content $CredsFile | convertto-securestring

    $Cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $AdminName,$password}

# Initiate Remote Dirsync Command

Invoke-Command -credential $Cred -ComputerName $DirsyncServer -ScriptBlock {C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -psconsolefile "C:\Program Files\Windows Azure Active Directory Sync\DirSyncConfigShell.psc1" -command "Start-OnlineCoexistenceSync"} 

 

Adding multiple domains to Office 365 in powershell

There may be times when you need to add tens or even hundreds of domains to an Office 365 tenant so using the GUI isn't really an option.

I've created a little script here that will make this process easier.

It takes a csv file (called domains.csv) that exists in the same folder as the script itself and outputs the domain proof required for each domain to a domains.log text file.

The CSV file must be a single column csv file in the following format;

Domain
domain1.co.uk
domain2.co.uk

I've included a generic domain CSV file in the downloadable zip archive if that's easier for you.

write-host
write-host --------------------------------------------
write-host Authenticating....
write-host --------------------------------------------
Import-Module MSOnline
$cred = Get-Credential
Connect-MsolService -Credential $cred
$count=import-csv .\domains.csv | measure
$domainlist=import-csv .\domains.csv
write-host
write-host --------------------------------------------
write-host Importing $count.count Domains....
write-host --------------------------------------------
$logfile=".\domains.log"
Function LogWrite {
Param ([string]$logstring)
Add-content $logfile -value $logstring
}
logwrite "Domain,TXTRecord"
foreach ($domain in $domainlist)
{
New-MSOLDomain -name $domain.domain
$proof = (Get-MSOLDomainVerificationDNS -domainname $domain.domain | select-object -expandproperty label).split(".")[0]
$txtrecord="MS=" + $proof
$domainrecord=$domain.domain
logwrite "$domainrecord,$txtrecord"
}

You can download the script and sample domains.csv file here

Tony currently works at Cloudworks implementing Office 365 and Azure based projects.

Office365 and Google DNS Servers

Many companies use the Google DNS servers (8.8.8.8 and 8.8.4.4) as forwarders to resolve internet addresses.

Whilst performing some exhaustive troubleshooting on Office365 & Outlook slowness & connection issues, we have uncovered incorrect addresses being resolved for EMEA customers.

When using Office365 in EMEA, outlook.office365.com is a CNAME record that should always resolve to either emea-east.outlook.com, or emea-west.outlook.com. This means you access the servers closest to you, and don’t cross the Atlantic multiple times to get to your data.

Google DNS servers

I have seen multiple occurrences recently of Google’s servers resolving UK based clients to outlook-namwest.office365.com which causes mail opening times of between 3-8 seconds (depending on the message size) and a raft of other connection and disconnection issues.

I recommend not using Google’s name servers if you’re either using Office365 or rely on accurate name resolution, but either OpenDNS or the servers provided by your ISP.

I'll shortly post a powershell script in the downloads section that will send an email if any of your nameservers return a non-emea result.

Tony currently works at Cloudworks implementing Office 365 and Azure based projects.

Office365 Delegated & Shared mailbox sent items fix

When using shared or delegated mailboxes with Office365 or Exchange 2013, any emails that are 'sent as' or 'sent on behalf of' the shared/delegated mailbox go into the senders mailbox instead of the shared/delegated mailbox.

There is a registry fix for this if you're using cached mode, but for online only users, there is no current workaround.

Some users have to work in online mode - Citrix and Remote Desktop users are an example, as if you're using cached mode you have to target users to specific Citrix / RDP servers to ensure cache files aren't taking up space on every single server, but that means no automatic fail-over in the event of a server failure.

I've written an Outlook macro that achieves the same as the registry hack that checks to see if the 'sender name' is the same as the 'sent on behalf of' name, and if it's not will move the message to the shared / delegated mailbox.

To give this a test - open Outlook, press alt +F11, expand Project1, expand Microsoft Outlook Objects and double click on ThisOutlookSession, then paste the following code into the new window.

VBA macro to move to delegated or shared mailbox

Private WithEvents MProSend As Outlook.Items
Private Sub Application_ItemSend(ByVal Item As Object, Cancel As Boolean)
If MProSend Is Nothing Then
Application_Startup
End If
End Sub
Private Sub Application_Startup()
Dim objNS As Outlook.NameSpace
Dim objSentFolder As Outlook.MAPIFolder
Set objNS = Application.Session
Set MProSend = objNS.GetDefaultFolder(olFolderSentMail).Items
End Sub
Private Sub MProSend_ItemAdd(ByVal Item As Object)
Dim objNS2 As Outlook.NameSpace
Dim MProFolder As Folder
Set objNS2 = Outlook.GetNamespace("MAPI")
If TypeOf Item Is Outlook.MailItem Then
If Item.SentOnBehalfOfName <> Item.SenderName Then
strSenderName = Item.SentOnBehalfOfName
Set MProFolder = objNS2.Folders(strSenderName).Folders("Sent Items")
Item.Move MProFolder
End If
End If
Set objNS2 = Nothing
Set MProFolder = Nothing
End Sub

Hope it helps...

Office 365 and Proxy Servers

Many large organisations employ proxies to control internet access and cache web content but this can cause major issues with the way Outlook and Lync connect to Office 365. Microsoft recommend bypassing proxies wherever possible with Office365 and here are the reasons why you should do this..

  • All content is encrypted so no traffic analysis can be performed
  • As content is encrypted, no caching can be utilized to increase performance
  • A minimum of 2 connections for Outlook and 5 for Lync are required per user which can increase if shared or delegated mailboxes are accessed, this can put massive strain on existing proxy servers when migrating to Office 365 from an on premise based messaging system
  • As the TCP connections to Office 365 are persistent, any issue that may cause your proxy to restart will disconnect the Outlook / Lync connection of every user.

Bypassing proxy servers for connections to office 365 can be achieved in a number of ways - Proxy Auto-Config (PAC) files can be used in the web browser to set bypass urls - more info here or the proxy server itself can be configured to go direct without authentication.

As Outlook reads proxy information from Internet Explorer, the best way to achieve this is to use PAC files to push Office 365 traffic away from the proxy servers but this can be problematic as many proxy servers are setup at the network's edge and are the only way out of the LAN for network clients so additional infrastructure may be required.

If using PAC files isn't an option - as a minimum the Office 365 and IPs should be configured on the proxy server to go direct without authentication but be aware that 2 connections per client as a minimum are required for basic connectivity of a single mailbox and significantly more if shared mailboxes delegated mailboxes are in use.

Recently Microsoft changed the guidance on which URLs are required to connect to Office 365, especially if you're based in the UK. It used to be the case that only EMEA servers were required to connect but now you should open up the entire global suite of URLs / IP ranges.

You can get this list of IPs and URLs here:

Office 365 global URLs / IP Ranges

Exchange Online URLs and IP Ranges

RSS Feed for Address / IP Range changes

Close attention should be paid to exactly how clients will connect when deploying Office 365 as latency and connection failures may occur that will severely affect user experience.

More Articles...

  • 1
  • 2