Seit den frühen Tagen von Exchange Server werden die maximale Postfachgrößen (Quota) von Anwenderpostfächern reglementiert. Diese Konfiguration erfolgte in vielen Exchange Organisationen über die Quota-Einstellungen der Postfachdatenbanken und galt somit einheitlich für alle in der jeweiligen Datenbank gespeicherten Postfächer. Dieses Vorgehen war in der Vergangenheit hauptsächlich dem Umstand geschuldet, dass der vorhandene Festplattenspeicher knapp und teuer war.
Das folgende Beispiel zeigt zwei Datenbanken für Standardanwender (DB-USER-1/-2) und eine Datenbank mit größeren Postfächern für das obere Management (DB-C-Level).
Diese Vorgehensweise wurde für viele Exchange Organisationen auch bei der Transition zu modernen Exchange Server Versionen ab Version 2013 nie infrage gestellt. Die alten Betriebsmuster wurden einfach übernommen.
Mit den modernen Exchange Server Versionen und den Empfehlungen für den Betrieb nach Preferred Architecture ist diese Art des Betriebs von Exchange Server Postfächern nicht mehr sinnvoll. Eine der wichtigsten, nichttechnischen, Empfehlungen, ist die Standardisierung und Vereinfachung des Betriebs der gesamten Exchange Server Plattform. Gerade im Hinblick auf einen hybriden Betrieb, also den parallelen Betrieb einer lokalen Exchange Organisation mit Anbindung an Exchange Online, ist eine Vereinfachung des Betriebs angeraten.
Eine Standardisierung und Vereinfachung des Betriebs erreichen Sie durch die Konfiguration der Postfachgrenzwerte auf Postfachebene. Hierdurch werden dedizierte Postfachdatenbanken für unterschiedliche Anwenderkreise überflüssig. Sie können Postfächer beliebig zwischen den Datenbanken verschieben und so flexibler auf Herausforderungen in der lokalen IT-Infrastruktur reagieren.
Das nachfolgende Beispiel verdeutlicht dies mit drei Postfachdatenanken (DB-1/-2/-3), in den eine unterschiedliche Anzahl an Postfächern mit unterschiedlichen Größen gespeichert ist.
Noch deutlicher wird die Vereinfachung für den täglichen Betrieb, wenn wir uns eine Verteilung von unterschiedlichen Anwenderpostfächern (MBX, grün/gelb) und aktivierten Online-Archiv-Postfächern (ARC, grün) anschauen.
Nun gibt es neben Anwenderpostfächern und Online-Archiv-Postfächern noch weitere Postfachtypen:
Mit diesen zusätzlichen Postfachtypen ergibt sich für einen vereinfachten Betrieb das folgende Beispiel mit Postfächern verteilt über fünf Postfachdatenbanken.
Bei einer modernen Betriebsweise von Exchange Server mit einer Datenbankverfügbarkeitsgruppe (DAG) benötigen Sie keine klassische Form der Datensicherung. Alle benötigten Schutzfunktionen sind in Exchange Server integriert. Daher ist es auch unerheblich, in welcher Postfachdatenbank ein bestimmtes Postfach gespeichert ist. Diese Art des Betriebs entspricht grundsätzlich dem Betrieb von Exchange Online. Dort wird ein Anwenderpostfach ebenfalls nur in „irgendeiner“ Postfachdatenbank gespeichert.
Gibt es auch Nachteile für solch einen vereinfachten und standardisierten Betrieb von Postfachdatenbanken in einer lokalen Exchange Server Organisation?
Es gibt einen Nachteil für den Betrieb einer solchen Exchange Server Datenbank Umgebung. Zumindest dann, wenn Sie weiterhin auf eine klassische Datensicherungsmethode setzen und regelmäßig Postfachinhalte aus einer Datensicherung wiederherstellen müssen. In diesem Fall müssen Sie wissen, in welcher Datenbank ein Postfach zum Zeitpunkt der Datensicherung gespeichert war, um explizit genau diese Datenbank wiederherstellen zu können. Im Active Directory Objekt eines Postfacheigentümers existiert keine Historie der vorherigen Speicherorte eines Postfaches. Es ist immer nur die aktuelle Postfachdatenbank im AD-Objekt gespeichert.
Für die Sicherheit im Betrieb und in der Verwaltung gibt es keine Einschränkungen. Mit Exchange Server Role Based Access Control (RBAC) haben Sie alle Möglichkeiten, um die Verwaltung besonderer Postfächer, z.B. Geschäftsführung, nur bestimmten Mitarbeitern zu erlauben. Von einer Einschränkung der Zugriffsmöglichkeiten durch die direkte Anpassung von Active Directory Objektberechtigungen sollten Sie absehen. Diese Anpassung ist im Vergleich zu eine Berechtigungssteuerung mit RBAC wesentlich unsicherer.
Der moderne Betrieb von Exchange Server mit einer datenbankunabhängigen Steuerung der Postfachgrenzwerte bietet Flexibilität und Standardisierung. Im Hybrid-Betrieb mit Exchange Online stellen Sie Postfächer in der lokalen Exchange Organisation in der gleichen Art und Weise bereit, wie sie auch in Exchange Online erfolgt. Sie haben somit eine einheitlich Betriebsart. Der einzige Unterschied sind die unterschiedlichen Postfachgrenzwerte im Vergleich zu Exchange Online. Idealerweise passen Sie auch die Grenzwerte in der lokalen Exchange Organisation denen in Exchange Online an.
Sollte Ihre lokale IT-Infrastruktur nicht die erforderlichen Rahmenparameter für einen sicheren und stabilen Betrieb von Exchange Server bieten, die Verfügbarkeit von Postfächern für Ihr Unternehmen aber wichtig sein, so ist Exchange Online die bessere Alternative.
Viel Spaß mit Exchange Server!
Sie möchten mehr über Exchange Server 2019 lernen? Werfen Sie einen Blick in das Buch "Microsoft Exchange Server 2019: Das Handbuch für Administratoren".
Sie benötigen Hilfe bei der Planung und Installation Ihrer Exchange Server 2019 Installation? Sie haben Fragen über Ihre bestehende Exchange Server Infrastruktur und möchten Exchange Online implementieren? Kontaktieren Sie uns per E-Mail info@granikos.eu oder besuchen Sie unsere Webseite http://www.granikos.eu.
Das Exchange Blog Cumulative Update für April 2017 (CU0417) fasst interessante Themen rund um Exchange Server und Office 365 (Exchange Online), Azure und Skype for Business (aka Lync) des Monats April 2017 zusammen.
Gerne unterstützen wir Sie bei der Planung und Durchführung Ihrer Exchange Server Implementierung oder Migration.
Sie denken über einen vollständigen Wechsel zu Office 365 oder eine Hybrid-Konfiguration mit Office 365 nach? Wir beraten Sie umfassend und ausführlich über die Möglichkeiten der Office 365 Plattform.
Sie möchten mehr über Exchange Server 2016 erfahren? Gerne erläutern wir Ihnen die technischen Änderungen und Chancen für Ihr Unternehmen in einem persönlichen Workshop.
Weitere Informationen zu unseren Dienstleistungen finden Sie auf unserer Website (https://www.granikos.eu) oder Sie kontaktieren direkt unser Vertriebsteam: info@granikos.eu
Microsoft bietet mit dem Microsoft Azure Trust Center eine zentrale Anlaufstelle, um sich über Compliance Zertifizierungen, authorisierte Dienstleister oder zum Thema Sicherheit in Azure zu informieren.
Im Bereich Resources stehen zahlreiche Best Practices und weitere Anleitungen zur Verfügung, um die Sicherheit eigener Azure Applikationen zu verbessern.
In dieser Woche hat Microsoft eine aktualisierte Liste der Dienstleister veröffentlicht, die mit Kundendaten in Azure arbeiten dürfen. Neben der Information, um welche Dienstleister es sich handelt, wird zusätzlich aufgezeigt, welche Funktionen/Rollen die einzelnen Dienstleister wahrnehmen.
Haben Sie Fragen rund um Azure oder planen Sie bereits konkret den Einsatz von Azure Diensten in Ihrem Unternehmen? Sprechen Sie uns an: info@granikos.eu
Das Blog Cumulative Update für April 2019 (CU0419) fasst interessante Themen rund um Cloud Sicherheit, Exchange Server, Office 365, Azure und Microsoft Teams des Monats April 2019 zusammen.
Sie denken über einen vollständigen Wechsel zu Office 365 oder eine Hybrid-Konfiguration mit Office 365 nach? Wir beraten Sie umfassend und neutral über die Möglichkeiten der Office 365 Plattform und Microsoft 365.
Sie möchten mehr über Exchange Server 2019 erfahren? Gerne erläutern wir Ihnen die technischen Änderungen und Chancen für Ihr Unternehmen in einem individuellen Workshop. Sie möchten mehr über Exchange Server 2019 lernen? Werfen Sie einen Blick in das Buch "Microsoft Exchange Server 2019: Das Handbuch für Administratoren".
Today we start with our short series about agile Project Management with this first article.
Nowadays almost everyone (at least in IT environments) talks about agile project management methods. Some already checked them out, but often enough there are some counter positions to these methods which are related to some unclear things within the methodology.
This small series will try to describe in detail what agile project management is and what are the success factors. First of all: agile project management is a methodology and a mindset! It is NOT a strictly designed process, which will solve problems magically. Key points of "agile" are:
Agile Project management works iterative, the product AND the process will be reviewed and optimized after each iteration
The highly collaborative structure focuses on teamwork and end user transparency as in showing actual project progress or problems which slowed down the progress
At the end of each iteration there will be a product increment which can be used by the customer, this creates actual value and ROI even before the end of the project
Agile Project management can be used in nearly all custom development projects.
If your project has 100% fixed requirements, which will surely not change during the project (by the way...just because they are written down, it does not mean they are fixed!)…
If you roll out "commercial off-the-shelf" software, which is already packaged and automatically distributed (think about MS Office for example)... If your project deals with upgrading or patching a system… … then agile might not be the right approach. If you are thinking about doing your own agile project it is highly recommended to involve an already agile-experienced colleague as an "Agile-Coach". He can help you to set up the process and working mode and help to get a clear understanding what agile is about. Here are some doubts which are quite common regarding agile methods:
This was the first part of our small Series about Agile Project Management. Look out for the next part which we are going to publish soon called "Agile Project Management – What is SCRUM"
The whole Series contains 4 pieces:
Agile Project Management – Basics (Part1) Agile Project Management – What is SCRUM (Part2) Agile Project Management – Agile Project Management in real Life (Part3) Agile Project Management – Agile on the next Level – Program Management (Part4)
If you have any comments on our Articles, your Feedback is highly welcome.
Different technologies are used to verify the validity of email senders. Each technology by itself represents only one component of a holistic solution. It is currently recommended to implement all three technologies.
The technologies are:
The following figure illustrates the protocol relations.
The use of SPF, DKIM, and DMARC are no substitute for email message encryption itself or transport encryption. These technologies are used to identify and asses valid senders and to protect against spam messages.
Keep in mind that SPF, DKIM, and DMARC are offerings for other emails servers. As a sending party, you do not control if and how SPF, DKIM, and DMARC are evaluated by the receiving server. But if evaluated, the configuration must be correct to avoid messages being rejected by receiving email servers.
The following sections focus on the DNS configuration for SPF, DKIM, and DMARC. This post is not intended to rate the technologies, but to describe the implementation.
Each domain is used for sending emails requires an SPF resource record (RR) in its DNS zone. An SPF record is always of the type TXT and does not use any hostname (or resource record name, if you will). An SPF RR is always valid for the entire DNS zone.
mcsmemail.de. 3600 IN TXT "v=spf1 mx a:mail.mcsmemail.de ?all"
The following screenshot illustrates adding a new SPF TXT record in a common DNS management interface (DE) of an internet provider. The hostname textbox remains empty.
Example explained:
v=spf1 SPF Version
mx MX server records defined within the DNS zone are valid senders
a:mail.mcsmemail.de The additional DNS hostname defined as A resource record is a valid sender as well
?all Neutral validation of non listed servers that send emails for this domain
SPF records can be created by using one of the various online resources.
DKIM resource records are configured as TXT resource records as well. In contrast to an SPF record, a hostname is mandatory. In this case its called selector.
A DKIM TXT record is always created as a record in the subdomain _domainkey.
nsp._domainkey.mcsmemail.eu. 3600 IN TXT "v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQChZM8yjegaKfd0ssKyezTW/7xbDSNc0uPd50xa5/ecerv1v3mHKM+T7mClzRmIEx+Ji6AisVeo2uvjTYPemHFMBlQpuS/4zc2QxWHqp62FSQ7lASBOzDfUrIwayPVqwSPD6NrnfVSWoUNrFGGSVeU5uLASecBzTfxPukqTHgYKhQIDAQAB"
The following screenshot illustrates adding a new DKIM TXT record in a common DNS management interface (DE) of an internet provider. The hostname textbox contains the selector nsp followed by the subdomain _domainkey.
v=DKIM1 DKIM version
k=rsa Public key encryption method
p=MIGfMA.... The DKIM public key
DMARC is configured as a TXT resource record as well. The DMARC resource record uses the fixed hostname _dmarc.
_dmarc.mcsmemail.de. 3600 IN TXT "v=DMARC1\; p=none\; rua=mailto:DMARCRUA@mcsmemail.de\; ruf=mailto:DMARCRUF@mcsmemail.de\; fo=1\; adkim=s\; aspf=s\; rf=afrf\"
The following screenshot illustrates adding a new DMARC TXT record in a common DNS management interface (DE) of an internet provider. The hostname textbox contains always the value _dmarc.
v=DMARC1 DMARC version
p=none No DMARC policy defined (You should always start with None, before switching to Quarantine or Reject) rua=mailto:DMARCRUA@mcscmemail.de Email address for status reports
ruf=mailto:DMARCRUF@mcscmemail.de Email address for error reports
fo=1 Error report type
adkim=s DKIM alignment, s = strict
aspf=s SPF alignment, s = strict
rf=afrf Error report message format, afrf = Abuse Report Format following RFC 5965
The DMARC policy (p) should be raised step-by-step. The results for each policy type are:
Recommended reading on this topic: Google Support Post.
DMARC DNS zone entries can easily be checked by using the Net at Works PowerShell tool. The PowerShell script can only be used with NoSpamProxy11+. But there are some online tools available as well.
Do you need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid with Office 365?
Contact us at office365@granikos.eu or visit our website http://www.granikos.eu.
Migration and consolidation projects in the IT field face technical challenges individual to each infrastructure. Internal IT projects can be executed following well established organizational processes and requirements.
Projects related to M&A programs face additonal and very unique requirements and constraints. These contraints tend to be agile and require to work outside of the well established processes valid for internal projects. Especially the constraints provided by the M&A process itself might require immediate adjustments or major changes.
Our real-world experiences from global M&A IT consolidations can help you to lead your M&A program to success. Whether it is an internal infrastructure consolidation handling get-well activities in preparation for a takeover or merging of global IT landscapes in the context of a corporate takeover, our professional program team will assist you from establishing the technical design to project planning, execution and monitoring.
Some of our experiences have been summarized in a PowerPoint slidedeck. The scenario shows
The following pictures demonstrate the situation pre merger:
We are keen to share our experiences to help you to bring your migration activites to a success. Ask for a workshop today: info@granikos.eu