Granikos Technology Blog

IT Migrationen und Konsolidierungen haben ihre ganz eigenen technischen Herausforderungen. Bei internen Projekten gibt es betriebliche Anforderungen, die den Rahmen solcher Projekte durch etablierte Prozesse abstecken.

Im Rahmen einer Unternehmensübernahme kommen zusätzliche Anforderungen und Zwänge hinzu, die die Planung und Ausführung, im direkten Vergleich mit rein internen Projekten, verschärfen.

Unsere Erfahrungen aus globalen IT Konsolidierungen in M&A Situationen, können Ihnen helfen ein solches Programm erfolgreich auszuführen. Ob es sich um eine interne Konsolidierung zur Vorbereitung einer Übernahme oder um das Zusammenführen im Rahmen der Unternehmensübernahme selber handelt, unser kompetentes Programm-Team unterstützt Sie von der technischen Planung bis zur Ausführung und Projektüberwachung.

Wir haben unsere Erfahrungen in einer Präsentation zusammengefasst, die folgendes Szenario beschreibt:

  • Interne globale Konsolidierung von
    • mehr als 20 Active Directory Domänen mit insgesamt 7.000 Benutzerkonten
    • fünf Exchange Organisationen und Vorbereitung zur Office 365 Migration
  • Globale IT Konsolidierung im Rahmen eines M&A mit
    • Migration aller Benutzerkonten in ein neues Active Directory
    • Migration von mehr als 13.000 Exchange Postfächern nach Office 365
    • Einführung einer einheitlichen E-Mail Domäne über sieben Exchange Organisationen
    • Migration aller Dateiserver Daten in zentrale Rechenzentren
    • Implementierung neuer Netzwerk-Infrastruktur in allen übernommenen Standorten
    • Implementierung einer zentralisierten globalen Lösung zur Datensicherung

Die nachfolgenden Bilder demonstrieren die Situationen vor der Migration:

 Bild Active Directory Umgebung 

Bild Exchange Server Umgebung

Bild Anbindung Office 365 

Haben wir Ihr Interesse geweckt? Gerne teilen wir unsere Erfahrungen im Rahmen eines Workshops, um Ihrer Migration zum Erfolg zu verhelfen. Kontaktieren Sie uns unter

Weiterlesen »

System Monitoring vs. Application Monitoring

When it comes to monitoring applications, administrators often disagree with system administrators on what to monitor and which thresholds to configure. By nature system administrators focus on system-related counters and objects to observe. They do not care about application-related monitoring as those information's are out of the scope of their daily work. Vice versa, the same is true for application administrators.

Therefore there is not and will never be a single monitoring solution to combine different interests in the information. On the other hand, the business is highly interested in implementing an individual monitoring solution to reduce the overall licensing cost (priority 1), reduce the number of servers required to host monitoring solutions (priority 2) and to eliminate the need for technical training (priority 3).

System monitoring and application monitoring systems sometimes share an intersecting set of “things” they can monitor. The fact is that both monitoring approaches have different procedures on how to control.

The following diagram illustrates the system monitoring approach, where a probe connects to a target and queries data using a dedicated protocol supported by the target (e.g., SNMP, WMI, SSH, etc.).

Schema PRTG System Monitoring

The solution illustrated uses PRTG, which is a network monitoring solution that supports all standard protocols for monitoring. You can enhance the monitoring capabilities with individual scripts, programs, and libraries. You can find a link to PRTG at the end of this post.

In comparison to system monitoring the application monitoring approach looks very different, as the following figure shows:

Schematic Overview ENow Application Monitoring


Application monitoring relies on the existence of agents installed locally on the servers hosting the applications. This approach provides the ability to monitor from an application perspective. The agent itself performs checks depended on the application running on the same server. For example, the agent checks that DNS name resolution works using the configured DNS servers on the server. If DNS resolution does not work, the agent responds with an error to central management even when the DNS server itself is reachable by the system monitoring probe.

In the current IT landscape where messaging and collaboration solutions provide business functionality at a large scale and are set up in high-availability configurations, the monitoring of such implementations from an application perspective is crucial. In a world where “always-on” is the business goal for a mobile workforce, downtime of messaging and collaboration systems is an issue.


Application Monitoring Solution

The ENow Management Suite supports your monitoring efforts for:

  • Active Directory
  • Exchange Server
  • Exchange Online
  • Lync Server
  • Blackberry Enterprise Server
  • SharePoint Server
  • SQL Server

Mailscape is the part of the ENow Management Suite which helps you to monitor the messaging infrastructure components like Exchange Server, Blackberry Enterprise Server, and SMTP relay servers.

Mailscape 365 is part of the ENow Management Suite which monitors your Exchange Online and Hybrid Exchange deployment inclusive of required hybrid components like AD FS and DirSync.

Compass is the part of the ENow Management Suite which monitors domain controllers and Active Directory specific topics.

ForeSite is the part of the ENow Management Suite which monitors your SharePoint farms and the related SQL database servers.

Besides monitoring the vitals of the application components and the infrastructure requirements (network, AD, etc.), the solution provides an extensive reporting functionality. The default set of reports fits most reporting needs, but you can set up individual reports as well. A significant feature is the ability to provide reports to different groups of stakeholders.

Monitoring servers should not be a time-consuming task for an application administrator. Therefore the interface of the ENow Management Suite is quite handsome, as it displays all statuses in a dashboard. As long as all conditions are green, the application administrator can focus on other work. When using all parts of the ENow Management Suite, you act within one single dashboard, but each part utilizes it’s own security groups to access the dashboard.

How does a SharePoint administrator work with ForeSite?

The following screenshot shows the ForeSite dashboard:

ForeSite One-View Dashboard

If the dashboard uses a traffic light approach to signal good, warning, and error states for each component monitored. This makes it easy to focus on the section of the application infrastructure, where an element is not in a healthy state. It cannot be any more intuitive.

By just clicking on the signaling rectangle, you dig deeper to the next level of information:

ForeSite One-View Dashboard - Timer Job Error

It seems as if there is something wrong with a SharePoint timer job. But what is going on?

ForeSite One-View Dashboard - Timer Job Error - Level 2

Ok, it is not the SharePoint timer service itself. It is just one of the timer jobs itself.

ForeSite One-View Dashboard - Timer Job Error - Level 3

The Application Addressed Refresh Job is offline for 3.4 days. That is valuable information, and the SharePoint administrator knows where to start to solve this issue.

This is a basic example of how an application monitoring solution can help to identify the error.

The reporting functionality of ForeSite helps to gather a lot of different data from a SharePoint farm. Those reports can be executed manually or be sent automatically by email repeatedly. The report's overview displays a list of different reports which are available by default:

ForeSite - Professional SharePoint Reporting

With the proactive monitoring of critical SharePoint services, like Site Availability, Timer Jobs, Search, and Index, and content databases, ForeSite helps the application administrator to focus on daily work. The alerting functionality helps to reduce the response time in the case of an error and therefore helps to reduce the overall business impact to a minimum.



The classic system monitoring solution is the interface of the administrative personnel responsible for the IT infrastructure itself. The application monitoring solution is the primary interface for application administrators and runs on top of the IT infrastructure. Even when some components (disk, memory, CPU, …) are measured by both solutions.

Besides monitoring of different vital aspects of the application, an application monitoring solution provides the ability for application-specific reports. Those reports and even the dashboard itself can be made available to different groups of stakeholders in the company using Windows credentials.

An application monitoring and reporting solution is a valuable addition to classic system monitoring.

What are your thoughts on system and application monitoring? Leave a comment.

Get your free 21-day trial of the ENow Management Suite today: 

Need more professional consulting on Exchange Server, Office 365, or Exchange configurations? Do not hesitate to contact us by email:




Weiterlesen »

Die nachfolgenden Videos von Exchange MVP Michael Van Horenbeeck (aka Michael Van Hybrid), zeigen Best Practices und Troubleshooting rund um Exchange Hybrid Deployments.

Screenshot Stairway To HEaven  Stairway to Heaven: Best Practices for Hybrid Deployments
Screenshot Troubleshooting Exchange Hybrid Deployments Troubleshooting Exchange Hybrid Deployments
Screenshot What Exchange Administrators Need to Know about Hybrid Deployments What Exchange Administrators Need to Know about Hybrid Deployments


Gerne unterstützen wie Sie beim der Implementierung einer Exchange Hybrid Umgebung oder einer Migration zu Exchange Online. Kontaktieren Sie uns:

Mit Mailscape und Mailscape 365 erhalten Sie eine Monitoring und Reporting Lösung, die Ihre Exchange Server oder Exchange Hybrid Umgebung zuverlässig überwacht.
Mehr erfahren:


Weiterlesen »

Die Bereitstellung und Konfiguration von Hybrid-Umgebung können schwierig sein und mehr Probleme als Lösungen mit sich bringen.

Nutzen Sie Ihre Chance zu einer Fragestunde mit Michael Van Hybrid (aka Michael van Horenbeeck) in einer Reddit IamA Fragestunde an diesem Donnerstag.

In der Fragestunde können Sie Michael all Ihre Exchange Hybrid Fragen stellen, die Sie schon immer mal stellen wollten.

Datum: 23. Oktober 2014

Uhrzeit: 20:00 Uhr (11:00 Uhr PST)

Folgen Sie zur Fragestunde: 

Weiterlesen »
Letzte Aktualisierung: 2020-02-16


Der Edge Server, oder besser gesagt die Edge Rolle, wurde mit Exchange Server 2007 eingeführt. Zu der Zeit war es State-Of-The-Art Protokollverbindungen aus dem Internet im Perimeter Netzwerk enden zu lassen und dies bevorzugt auf Servern, die keine Mitgliedsserver einer internen Active Directory Domäne des Unternehmens sind.

Das Exchange Produktteam hat dieser Anforderung mit der Edge Rolle Rechnung getragen. Mit der Produktveröffentlichung erschienen auch die ersten Best Practice Anleitungen, wie das Deployment mit Edge Servern optimal zu gestalten war. Aufgrund der technischen Anforderungen (z.B. Zuordnung von Edge Servern zu einer AD-Site mit Hub Servern) und einer erst zögerlichen Verbreitung von virtualisierten Exchange Systemen, wurden Edge Server hauptsächlich in größeren Exchange-Umgebungen implementiert.

Seit Einführung der Edge Rolle gibt es immer wieder Diskussionen zwischen den Messaging-Administratoren, die sich die zusätzliche Komplexität der Exchange Umgebung sparen möchten, und den Security-Administratoren, die keine direkten Verbindungen aus dem Internet zu internen Systemen (in diesem Fall Hub Server) zulassen möchten.

Der ganz entscheidende Vorteil des Edge Servers liegt darin, dass er kein Mitgliedsserver einer Domäne ist. Die notwendigen Information über interne Empfänger, deren Block- und Allow-Listen werden in einer AD LDS Instanz verschlüsselt gespeichert. Aktualisierungen werden durch Edge-Sync von internen Servern zum Edge Server verschlüsselt gepusht.

Mit Exchange Server 2010 hat Microsoft schon beim RTM-Release die Edge Rolle in einer neuen Version bereitgestellt. Jedoch wurde der Funktionsumfang nicht wesentlich erhöht, da die primären Funktionen weitgehend unverändert blieben:

  • E-Mail Filterung
  • Anti-Spam & Anti-Virus
  • Dedizierte Konnektoren zu Partner Unternehmen
  • Konnektoren mit Domain Validation
  • Konnektoren mit Domain Secure, zeigt in Outlook einen grünen Haken, dass eine Nachricht über eine besonders gesicherte Verbindung empfangen wurde
  • Integration mit Office 365 
  • Delayed Acknowledge bei eingehenden E-Mails, um im Rahmen der Shadow Redundancy eine die Hochverfügbarkeit im Nachrichtenfluss zu garantieren

Einige dieser Funktionen können natürlich auch mit Hilfe von entsprechen konfigurierten Konnektoren direkt auf Hub Server umgesetzt werden. Dem reinen Nachrichtenfluß tut dies keinen Abbruch. Jedoch stellt sich wieder die Frage der Sicherheit. Manche Administratoren halten die Protokollinspektionen durch Firewalls (ohne hier Namen zu nennen), für gut und ausreichend.

Mit Exchange Server 2013 hat Microsoft es versäumt die Edge Rolle mit der RTM Version bereitzustellen. Stattdessen konnte man Exchange 2013 mit Edge Servern der Version 2007 oder 2010 betreiben (siehe Link). Diesen "gemischten" Betrieb unterschiedlicher Exchange Versionen wollte aber niemand wirklich durchführen. Mit Exchange 2013 SP1 wurde, neben anderen Funktionen, auch die Edge Rolle in Exchange 2013 wieder verfügbar und die Anzahl der verfügbaren Rollen wieder auf drei erhöht.

Brauchen wir heute noch die Exchange Server Edge Rolle?

Meiner Meinung benötigen wir sie auch heute noch. Mit der Edge Rolle im Perimeter Netzwerk werden definierte Endpunkte, sowohl für ausgehen, als auch eingehenden Nachrichtenverkehr, bereitgestellt. Diese zentralen Endpunkte bietet gerade beim Troubleshooting des Nachrichtenflusses einen sicheren Startpunkt für Administratoren. Während man mit zwei Edge Server im Perimeter-Netzwerk eine gute Redundanz für den Nachrichtenverkehr bereitstellt, können due Hub Transport Server im internen Netzwerk nach Bedarf skaliert werden. Einschränkungen durch die Systemanforderungen gibt es keine, da sich reine Transport-Server hervorragend virtualisiert betreiben lassen.

Ein ganz entscheidender Vorteil beim Einsatz von Edge Servern ergibt sich aber gerade bei Unternehmenszusammenschlüssen. Solche Situationen sind immer dadurch gekennzeichnet, dass möglichst schnell und allumfassend eine neue E-Mail Domäne extern sichtbar wird und ohne große technische Probleme umgesetzt werden kann. Hier treffen die Wünsche der Marketingabteilung auf die Widerstände der IT-Abteilung. Mit einem Edge Server aber kann schnell und einfach mit Hilfe der Adressumschreibung auf solche Anforderungen reagiert werden.

Auch in der heutigen Zeit gibt es ausreichend gute Gründe für den Einsatz der Exchange Edge Server Rolle. Setzen Sie auch die Exchange Edge Rolle in Ihrer Messaging Umgebung ein.

Auch Exchange Server 2016 und Exchange Server 2019 enthalten die Edge Transport Rolle. Technisch ist die Funktionsweise der Edge Transport Rolle unverändert.

Gerade im Hinblick auf den hybriden Betrieb einer lokalen Exchange Organisation mit Exchange Online und Verwendung des zentralisieren Nachrichtenverkehrs (Centralized Mail-Flow) ist die Nutzung der Edge Transport Rolle unverzichtbar. 

Mehr zu diesem Thema finden Sie in meinem Buch "Microsoft Exchange Server 2019. Das Handbuch für Administratoren", erschienen im Rheinwerk Verlag.




Gerne helfen wir bei der Planung und Umsetzung Ihrer Exchange Server Umgebung. Sprechen Sie uns an:




Weiterlesen »