If you want to share free and busy details between two Exchange organizations, you usually use the Microsoft Federation Gateway. Sometimes this is not possible, e.g., for compliance reasons, or other business reasons. But there exists a way to do this, even without an Active Directory trust between two organizations.
Let us say we have two Exchange organizations: contoso.com and adatum.com.
The prerequisites are:
I will use user account freebusy in this example.
Execute the following in contoso.com Exchange organization using Exchange Management Shell:
$TargetSmtpDomain = 'adatum.com' $TargetDomainAccount = 'adatum.com\freebusy' Add-AvailabilityAddressSpace - Forest $TArgetSmtpDomain -AccessMethod OrgWideFB -Credentials (Get-Credentials -User $TargetDomainAccount) Set-AvailabilityConfig -OrgWideAccount $TargetDomainAccount.Split('\')[1]
Execute the following in adatum.com Exchange organization using Exchange Management Shell:
$TargetSmtpDomain = 'contoso.com' $TargetDomainAccount = 'contoso.com\freebusy' Add-AvailabilityAddressSpace - Forest $TargetSmtpDomain -AccessMethod OrgWideFB -Credentials (Get-Credentials -User $TargetDomainAccount) Set-AvailabilityConfig -OrgWideAccount $TargetDomainAccount.Split('\')[1]
Exchange Server in the source organization must be able to resolve the recipient address for requesting free/busy information from the target organization. Exchange Server can determine a target address accurately when you create the recipient object as a contact in the source Exchange organization.
For this example, you create contact objects in adatum.com for all user in contoso.com and vice versa. You can use GalSync or any other identity management (IDM) software that can handle object synchronization.
When using Exchange Server 2013, or 2016, you may run into a problem.
The HttpProxy log of the requesting Exchange Server log will state that AutoDdiscover failed for generic mailbox 01B62C6D-4324-448f-9884-5FEC6D18A7E2@contoso.com (or adatum.com).
HttpProxy log excerpt:
2019-07-26T07:19:24.649Z,2827102f-75b1-4ecb-ae6c-36b075bb8e93,15,1,1779,2,,Autodiscover,autodiscover.contoso.com,/autodiscover/autodiscover.xml,,Basic,true,CONTOSO\freebusy,,MailboxGuid~01b62c6d-4324-448f-9884-5fec6d18a7e2,ASAutoDiscover/CrossForest/EmailDomain//15.01.1779.002,172.16.0.20,CONTOSO-EX1,404,,MailboxGuidWithDomainNotFound,POST,,,,,AnchorMailboxHeader-MailboxGuidWithDomain-NoUser,,,,381,,,,0,,,0,1;0;,1,,0,1,,0,4,0,,,,,,,,,0,3,0,,3,,3,3,,,,BeginRequest=2019-07-26T07:19:24.646Z;CorrelationID=<empty>;ProxyState-Run=None;AccountForestGuard_contoso.com=1;AccountForestGuard_contoso.com=1;ProxyState-Complete=CalculateBackEnd;SharedCacheGuard=0;EndRequest=2019-07-26T07:19:24.649Z;I32:ADS.C[CONTOSO-DC1]=2;F:ADS.AL[CONTOSO-DC1]=0.8201787,HttpProxyException=Microsoft.Exchange.HttpProxy.HttpProxyException: Cannot find mailbox 01b62c6d-4324-448f-9884-5fec6d18a7e2 with domain contoso.com. at Microsoft.Exchange.HttpProxy.AnchorMailbox.CheckForNullAndThrowIfApplicable[T](T ret) at Microsoft.Exchange.HttpProxy
If DNS is used to resolve the AutoDiscover endpoint of the target Exchange organization, the source Exchange organization queries AutoDiscover information for a mailbox with that uid. SCP-based AutoDiscover lookup does not use this dedicated uid-based email address.
To solve this issue, you add the required SMTP address found in the HttpProxy log to one user mailbox in the target organization.
In the contoso.com organization:
Set-Mailbox -Identity 'someuser@contoso.com' -EmailAddresses @{add='01B62C6D-4324-448f-9884-5FEC6D18A7E2@contoso.com'}
In the adatum.com organization:
Set-Mailbox -Identity 'someuser@adatum.com' -EmailAddresses @{add='01B62C6D-4324-448f-9884-5FEC6D18A7E2@adatum.com'}
Auf dem aOS Aachen September 2018 Event hat Luise Freese die Vorträge in ihren bekannten Sketchnotes festgehalten.
Hier sind ihr Sktechnotes zu meinen beiden Sessions.
Wer die Ignite 2018 besucht, kann Luise Freese dort treffen. Sie ist Chief Community Sketcher der Konferenz in Orlando.
The use of certificate based email encryption is still a challenging task for administrators. When you store end user certificates stored locally on computers, you accept the risk of the user certificates being deleted or overwritten unintentionally.
The use of smart cards helps to mitigate the risks associated with locally stored certificates. But smart cards are too complicated for large and agile companies. The use of smart cards with mobile devices is even more complicated, if not impossible.
A simple and reliable solution is to use encryption and decryption capabilities at the company email gateway(s). This approach allows for:
Besides the option to import certificates manually, the real benefit is provided by automatic certificate provisioning. By using a certificate authority company account the gateway solution handles certificate requests automatically.
The supported S/MIME certificate authorities are:
NoSpamProxy by Net at Work is a gateway solution proving this set of features for on-premise SMTP messaging infrastructures.
The advantages provided by NoSpamProxy can be used with Office 365 as well. There is no need to have an Exchange Hybrid configuration ins place to benefit from the NoSpamProxy features. The NoSpamProxy gateway can be configured for the use with Office 365 cloud-only tenants.
The following picture illustrates how NoSpamProxy gateway is integrated in such a scenario.
External emails are received by the local NoSpamProxy Gateway server and not by Exchange Online (1). The NoSpamProxy gateway handles the messages and sends the messages to Office 365 using an Office 365 connector (2). Outgoing messages to external recipients are send to the on-premise NoSpamProxy gateway using a dedicated Office 365 Send Connector (3). The NoSpamProxy gateway handles the messages and sends the messages to the external recipients.
Multiple NoSpamProxy gateway servers can be deployed for a redundant setup.
The NoSpamProxy gateway solution provides more than just S/MIME or PGP encryption capabilities. NoSpamProxy is a robust fully fledged anti-spam solution which rejects spam emails legally compliant. Each message that is not fully received by the company does not need to be archived.
NoSpamProxy features:
Want to know more about all NoSpamProxy features? Not yet an Office 365 customer, but keen to know more about gateway based encryption and a reliable anti-spam solution?
Get to know more about NoSpamProxy here: hier.
NoSpamProxy Azure Edition is the cloud based email security gateway of the successful NoSpamProxy family of products by Net at Work. The Azure edition of NoSpamProxy can easiliy be deployed using the Microsoft Azure Marketplace.
NoSpamProxy Azure easily connects an Office 365 tenant and offers an easy way to provide centralized email encryption and decryption with PGP and/or S/MIME for mailboxes hosted in Exchange Online. Additionally, NoSpamProxy Azure provides compliant anti-spam handling, an anti-malware component, and a large file portal.
The edition currently available in Microsoft Azure installs a NoSpamProxy single-server deployment. A single-server deployment combines the NoSpamProxy intranet role and the gateway role on a single server.
The NoSpamProxy Azure Edition is provided as BYOL (Bring Your Own License) deployment. In addition to the recurring fees for the Microsoft Azure VM you are required to buy a NoSpamProxy license. If you already own a NoSpamProxy Version 11 license, the license can be used for the NoSpamProxy Azure Edition as well.
DeploymentOptions Notes Deployment Links
Due to the nature of a cloud service NoSpamProxy Azure can be operated in different scenarios in Microsoft Azure. By default the system is configured as a workgroup system without any Active Directory domain membership. The different operational scenarios for NoSpamProxy Azure depend on the existence of a Site-2-Site VPN between your Azure deployment and your on-premises IT infrastructure.
Currently a direct connection to Azure AD is not supported, but it is planned for a future release.
Depending on the size of the Azure VM different throughputs can be reached in regards to emails per minute.
Tests have shown the following results for Standard A Virtual Machines:
The following steps describe a simple deployment of NoSpamProxy Azure.
Go to Azure Marketplace and search for NoSpamProxy, select the NoSpamProxy Azure Edition.
Click Create to configure the NoSpamProxy Azure system.
Configure the required parameters as needed
Select an appropriate virtual machine type. NoSpamProxy Azure doesn't have extraordinary system requirements for processor and memory. SQL Server 2014 Express is downloaded and installed as part of the standard setup of NoSpamProxy. Even SQL Server 2014 Express can be run on a standard VM..
All other settings remain unchanged for this simple deployment. You can adjust the settings, if required for your individual deployment. Especially if you want to utilize exisiting resources.
Verify the technical summary and click OK to add the configured system to your shopping cart.
Verify the selected Azure service offering and the configured virtual machine. Click Purchase to buy the selected subscription. The deployment is a so called BYOL Deployment and requires a valid NoSpamProxy trial license or an existing full license. After the NoSpamProxy setup as been completed in the virtual machine you will be redirected to a web page to request a trial license.
Connect to the newly deployed virtual machine using Remote Desktop. After first log on NoSpamProxy setup will start automatically as part of an scheduled task. The scheduled task will execute the following steps:
Do not close or interrupt the Windows PowerShell window.
After the setup has finished the public web page of NoSpamProxy Azure Edition will be opened in Internet Explorer. After initial setup of the operating system Internet Explorer runs in secure mode. Therefore, a security warning is displayed. Just add the web page to the list of exclusions and request your personal NoSpamProxy trial license.
The program setup adds new security groups and adds the logged on account to these security groups. It is required to log off and log on again to reflect the new group memberships. This is mandatory to sucessfully manage NoSpamProxy.
After log on start the NoSpamProxy Configuration MMC to import the license.
The NoSpamProxy Configuration MMC displays the NoSpamProxy version.
After initial import of the license you can start configuring NoSpamProxy to suit your needs.
Die NoSpamProxy Gateway-Rolle benötigt für mehrere Funktionen Zugriff ins Internet. Dieser Zugriff kann sowohl direkt, als auch über einen klassischen Proxy erfolgen. Zu den Funktionen gehört u.a. der Webservice-Zugriff auf De-Mail.
Die Proxy-Konfiguration erfolgt direkt in der Konfigurationsdatei des Gateway-Service. Diese Anpassung muss auf jedem Server mit installierter Gateway-Rolle durchgeführt werden.
Für die Konfiguration eines Proxy-Servers wird in der Konfigurationsdatei ein zusätzlicher Xml-Node hinzugefügt.
Das nachfolgende Beispiel bezieht sich auf NoSpamProxy 11.1.179.0
NetatworkMailGatewayRole.exe.config vor der Anpassung
<?xml version="1.0" encoding="utf-8"?> <configuration> <runtime> <gcServer enabled="true" /> <generatePublisherEvidence enabled="false" /> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" /> </dependentAssembly> </assemblyBinding> </runtime> </configuration>
NetatworkMailGatewayRole.exe.config mit konfiguriertem Proxy-Server
<?xml version="1.0" encoding="utf-8"?> <configuration> <runtime> <gcServer enabled="true" /> <generatePublisherEvidence enabled="false" /> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" /> </dependentAssembly> </assemblyBinding> </runtime> <system.net> <defaultProxy> <proxy usesystemdefault="true" proxyaddress="http://10.29.10.11:8080" bypassonlocal="true" /> </defaultProxy> </system.net> </configuration>
Bei der Installation eines Updates von NoSpamProxy wird die Datei NetatworkMailGatewayRole.exe.config überschrieben.
Dies bedeutet, dass nach die Konfiguration eines Proxy-Servers nach erfolgreicher Installation des Updates wieder eingetragen werden muss.
A custom domain can only be registered once across all available Office 365 instances (Global, Germany, and China). In order for a registered domain to be used in a new tenant, the registered domain must be removed from the old tenant.
The following text assumes that you have already migrated or backed up all user data. Otherwise, the steps described will result in the immediate deletion of data or a release for deletion within Office 365. If the domain to be deleted is the tenant's default domain, accounts for guest users (user_remotedomain#EXT#mydomain.com) stored in Azure AD also use that domain name. using that domain. These accounts must be removed as well.
If the old tenant synchronizes with Azure AD Connect this configuration must be removed first. The domain to be deleted must not be used by any user or group object in Azure AD. Your options are:
Use PowerShell to verify if there are still objects using the domain name to be deleted..
# Install the Office 365 PowerShell module Install-Module MSOnline # Import the module, if it's installed already Import-Module MSOnline # Connect to Office 365 using a global admin account w/o MFA Connect-Msolservice # domain name $Domain = 'granikoslabs.de' $Filter = "*@$Domain" # List all Office 365 users with a UPN using the domain name Get-MsolUser -DomainName $Domain | FL UserPrincipalName # List all Office 365 users with a proxy address using the domain name Get-MsolUser | Where-Object {$_.ProxyAddresses -like $Filter} # List all Office 365 groups with a proxy address using the domain name Get-MsolGroup | Where-Object {$_.ProxyAddresses -like $Filter} # List all Office 365 groups with an email address using the domain name Get-MsolGroup | Where-Object {$_.EmailAddress -like $Filter}
If you get any results from the list queries you must clean up the objects first. Without modifying the objects you cannot remove the custom domain from Office 365.
If the queries did not return any result you are safe to remove the custom domain from the old tenant.
# Domain removal Remove-MsolDomain -DomainName $Domain -Force
After the final removal of the custom domain
After deleting the custom domain from the old tenant, the domain can be added to a new tenant relatively quickly in other Office 365 instances.
Enjoy Office 365!
Mit der neuen Version 9.2 des erfolgreichen Net at Work Mail Gateways erwarten uns einige Neuerungen und Änderungen.
Mail Gateway Nutzer, die den De-Mail Konnektor verwenden (egal ob Mentana oder Telekom/T-Systems), müssen die neue Mail Gateway Version 9.2 installieren, ansonsten wird die Verbindung zum DMDA nicht mehr funktionieren. Sowohl Mentana und Telekom/T-Systems stellen zum 31.12.2014 den Dienst der alten Plattform ein.
Der bisherige Zertifikatsanbieter SignTrust hat Ende September bekannt gegeben, sich aus dem Trustcenter-Markt zurückzuziehen. Bestehende Kundenverträge wurden zum 31.12.2014 gekündigt. In Zukunft wird die automatische Beantragung von Zertifikaten über das Trustcenter von SwissSign mit den Gateway Solutions möglich sein. SwissSign bietet seit 2001 digitale Zertifikate und Signaturen an und ist seit 2005 eine 100% Tochter der Schweizerischen Post. Als anerkannter Certificate Services Provider (CSP) rangiert SwissSign in den weltweiten Statistiken hinter Unternehmen aus den USA und Japan als europäische Marktführerin und bildet somit eine ideale Alternative für bisherige SignTrust Kunden.
Neben SwissSign als neuem Zertifikatsanbieter wird Anfang 2015 noch das Trustcenter von GlobalSign seinen Weg in die Gateway Solutions von Net at Work finden. Die Implementierung der API hat bereits begonnen und wird in Kürze abgeschlossen sein. GlobalSign wurde 1996 als eine der ersten Zertifizierungsstellen gegründet. Mit der Implementierung von GlobalSign können enQsig Kunden dann wahlweise Zertifikate von zwei europäischen Zertifizierungsstellen beziehen.
Die Version 9.2 der Mail Gateway Lösung ist die letzte Version des Produktes, die eine Installation auf einem 32-Bit betriebssystem erlaubt. Wenn Sie weiterhin auf die Fähigkeiten des Lösung vertrauen möchten, müssen Sie auf ein 64-Bit Betriebssystem migrieren.
Wir unterstützen Sie beim Versionsupdate und der Migration auf ein neues Betriebssystem. Gerne beraten wir Sie zu den Themen E-Mail Spamabwehr mit NoSpamProxy und automatisch sicherer E-Mail Kommunikation mit enQsig. Kontaktieren Sie uns unter info@granikos.eu.