This article describes how to configure Xink rerouting for Office 365 using PowerShell without giving super admin credentials to your Office 365.
This is an additional technical article - Prefer the web console?
Back to the web console and get familiar with the basics.
How to configure rerouting for Office 365 using PowerShell
First, download Xink PowerShell script and save it to the Downloads folder of the logged-on user.
The script uses two credentials – one is for Office 365 and the other is for Xink cloud itself. We will save both into PowerShell variables and use both in all subsequent commands.
Type $xinkCred = Get-Credential, then type your Xink username and password into the pop-up window (username used from the Xink admin login).
Type $o365Cred = Get-Credential and type your Office 365 global admin username and password into the window.
Creating two variables manually instead of direct input to console prompt string makes it completely secure, the Get-Credential cmdlet uses Secure String system type to store the passwords in memory. And it allows running multiple commands without typing both credentials each time.
The script uses Office 365 credential only to create PowerShell remote session to Microsoft servers and Xink credential only to obtain the access token. The script is distributed in sources, of course, it is possible to open it in a text editor and check what it does exactly.
Both variables are saved, now configure Xink and Office 365. Just one command with credentials mentioned above as arguments.
Change directory to the folder where Xink script is saved, in our case it would be “Downloads”, then type \xink-rerouting.ps1 $o365Cred $xinkCred -Create.
The script makes several API calls:
- Create remote PowerShell session to Office 365. (Office 365 Credential is used)
- Obtain Xink API access token. (Xink credential is used)
- Call Get-AcceptedDomain in Office 365 environment, then push the list to Xink.
- Create Inbound Connector in Office 365. It will be used to feed messages from Xink service back to Office 365 for further delivery. The default name of the connector is “Xink-Auto-ReRouting-In”.
- Create an Outbound Connector in Office 365. It will be used to feed messages to Xink service. By default, it would be named “Xink-Auto-ReRouting-Out”.
- Create a Transport Rule in Office 365. The rule will catch outgoing images and route these to the outbound connector created in the previous step. Default rule name is “Xink-Auto-ReRouting-Catcher”.
This is enough to use Xink rerouting service in most cases.
The script creates a typical rule which would catch all messages originating from inside an organization. Any further manual customizations are possible, say, adding a group of people who actually use Xink and routing only emails sent by members of this group. There is only one requirement: the rule must check X-Xink-Handled header, and if it is set to “Yes” do not route the message back to Xink.
Mail routing can be paused by disabling transport rule temporary, in Exchange admin center, mailflow section, “rules” tab.
The script also has -Remove switch, it removes both connectors and the rule from Office 365. We recommend to pause routing to Xink first and remove connectors and the rule in few hours when all stale messages are processed and sent out successfully.
Running the script without -Create or -Remove switches shows the current status of Rerouting.
This command requests Office 365 accepted domain list, compares it to Xink domain map and cache, then looks up for the inbound connector, outbound connector and the transport rule. Only objects created by rerouting configuration script or by the console itself would be recognized.
Here is sample output:
This command requests Office 365 accepted domain list, saves the list to Xink domain map and cache. Then it creates an inbound connector, outbound connector and the transport rule to catch outgoing messages.
This command removes previously created inbound/outbound connectors and transport rule from Office 365.