de-DEen-GB
rss

Granikos Technology Blog

Folgende Aufzeichnungen der 'Tech Talk'-Reihe sind verfügbar:

  • Tech Talk 1 - Supportende von Exchange Server 2010
    4. Februar 2020
    Grafik Tech Talk 1
     
  • Tech Talk 2 - Migrationsmöglichkeiten von Exchange Server zu Exchange Online
    22. Februar 2020
    Grafik Tech Talk 2
     

 

Weitere Links

 


Kurzlink zu dieser Seite: http://techtalk.granikos.eu

 

Weiterlesen »

 

Das zweite Video der 'Tech Talk'-Reihe ist bei YouTube verfügbar. 

Das Thema des Talks:

  • Migrationsmöglichkeiten von Exchange Server zu Exchange Online

Im Tech Talk 2 erhalten Sie einen Überblick über die unterschiedlichen Möglichkeiten, wie Sie eine lokale Exchange Organisation zu Exchange Online migrieren.

 

 

Links

 

Viel Spaß.

 

 

Weiterlesen »

Adnan Rafique is a Collaboration Architect for Microsoft Exchange and Office 365. He is a subject matter expert in this area since the days of Exchange Server 2007.

He reached out to me to record an interview on Office 365, the impact of cloud technologies to the daily operations of IT administrators, and the requirement for life-long learning.

Here is the recording, available on Adnan's YouTube Channel. Enjoy.

 

Video-Link: https://go.granikos.eu/iMentorCloudFeb2020

 

A future interview will cover Microsoft Teams and how it helps to transform the way your work.

 

Links

 

Weiterlesen »

Beim Zusammenschluss von Unternehmen wird in vielen Fällen mit einer Active Directory Vertrauensstellung zwischen Domänen aus unterschiedlichen AD-Gesamtstrukturen gearbeitet. 

Um das Arbeiten mit Ressourcen in beiden Strukturen zu ermöglichen, verfügen Active Directory Objekte über das Attribute sIDHistory. In diesem Attribut in Zieldomäne A wird die SID aus der Quell-Domäne B eingetragen. Hierdurch ist es möglich, dass ein in Domäne A migrierter Benutzer weiterhin auf Ressourcen in der "alten" Domäne B zugreifen kann. 

Dies funktioniert allerdings nur, wenn die Active Directory Vertrauensstellung zwischen beiden Domänen die Nutzung der sIDHistory aktiviert ist. Aus Sicherheitsgründen ist diese Funktionen im Normal ausgeschaltet. Dies nennt man auch SID-Filterung.

Die Aktivierung der SID-History bzw. die Deaktivierung der SID-Filterung erreicht man durch folgenden Kommandozeilenbefehl:

netdom trust LOKALEDOMAIN.tld /domain:REMOTEDOMAIN.tld /enablesidhistory:yes

 

Problem

Wenn Sie den o.g. auf einem deutschsprachigen Windows Server Betriebssystem ausführen, erhalten Sie u.U. folgende Fehlermeldung:

"Der SID-Verlauf ist für diese Vertrauensstellung deaktiviert."

 

Lösung

Die Lösung ist sehr trivial. Verwenden Sie anstatt yes ein ja, um die SID-History zu aktivieren. Der folgende Kommandozeilenaufruf bringt Sie ans Ziel:

netdom trust LOKALEDOMAIN.tld /domain:REMOTEDOMAIN.tld /enablesidhistory:ja

 

Links

 

Viel Spaß mit Active Directory.

 

 

Weiterlesen »

Exchange Server 2016Exchange Server 2019

Mit Exchange Server 2016 wurde das Cmdlet Get-MailboxServerRedundancy eingeführt. Mit Hilfe dieses Cmdlets können Sie den Betriebsstatus der Postfach-Server einer Datenbankverfügbarkeitsgruppe (DAG) abfragen, bevor Sie einen Exchange Server in Wartung nehmen.

Leider exisitiert zu diesem Cmdlet keinerlei Hilfeinformation, weder in Microsoft Docs, noch direkt in der PowerShell per Get-Help.

Das Cmdlet verfügt eine tabellarische Standardausgabe der wichtigsten Informationen.

In der Standardausgabe werden angezeigt:

  • Identity
    Name des Mitgliedsservers der DAG
     
  • IsServerFoundInAD
    Hier sehen Sie, ob das zum Exchange-Server zugehöriger AD-Objekt in Active Directory exisitert
     
  • IsInMaintenance
    Diese Spalte zeigt an, ob für einen Server aktuell der Wartungsmodus aktiviert ist
     
  • RepairUrgency
    In dieser Spalte wird der Reparaturstatus der Postfachdatenbanken und Suchindizes angezeigt
     
  • SafeForMaintenance
    In dieser Spalte zeigt das Cmdlet an, ob für einen Server In sicher der Wartungsmodus aktiviert werden kann
     
  • HealthInfoLastUpdateTime
    Dies ist der Zeitstempel der letzten Aktualisierung der Health-Daten für den Server
     

 

Beispiel - Vor einer Wartung

Das folgende Beispiel zeigt die Informationen einer DAG mit sechs Mitgliedsservern, bevor für Server LOCEXS06 der Wartungsmodus aktiviert wird.

Get-MailboxServerRedundancy -DatabaseAvailabilityGroup EXDAG01

Identity        IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
                InAD          ance
--------        ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01        True          False       Prohibited    False              17.02.2020 09:10:11
LOCEXS02        True          False       Normal        True               17.02.2020 09:10:11
LOCEXS03        True          False       Normal        True               17.02.2020 09:10:11
LOCEXS06        True          False       Normal        True               17.02.2020 09:10:11
LOCEXS05        True          False       Normal        True               17.02.2020 09:10:11
LOCEXS04        True          False       Prohibited    False              17.02.2020 09:10:11

 

Als Exchange Administrator interessieren uns besonders die Spalten RepairUrgency und SafeForMaintenance.

Screenshot Get-MailboxServerRedundancy

 

Für keinen der sechs Server ist in diesem Screenshot der Wartungsmodus aktiv. Für die Server S01 und S04 wird angezeigt, dass beide Server nicht sicher in Wartung genommen werden können und die RepairUrgency den Status Prohibited hat.

Was ist der Grund hierfür?

 

Serverinformationen

Für jeden einzelnen Mitgliedsserver der DAG können Sie Einzelinformationen abfragen. Bei Abfrage der Informationen zu einem Server erhalten wir in der Standardausgabe keine ausführlicheren Informationen zum Status. 

Get-MailboxServerRedundancy -DatabaseAvailabilityGroup EXDAG01 -Identity LOCEXS01

Identity        IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
                InAD          ance
--------        ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01        True          False       Prohibited    False              17.02.2020 09:11:11

 

Da der Server LOCEXS01 gegenwärtig nicht sicher in Wartung genommen werden kann, interessiert uns natürlich, welcher Status genau dafür entscheidend ist.

Diese Information erhalten Sie über die Abfrage der Detailinformationen des gewünschten Servers.

 

Detailinformationen

Die Detailinformationen erhalten Sie einfach durch die Ausgabeformatierung mit Format-List oder kurz FL.

Get-MailboxServerRedundancy -DatabaseAvailabilityGroup EXDAG01 -Identity LOCEXS01 | FL

RunspaceId                                  : 70d82f8d-e6ca-4bfc-863f-11300a9784ff
Identity                                    : LOCEXS01
IsServerFoundInAD                           : True
IsInMaintenance                             : False
RepairUrgency                               : Prohibited
SafeForMaintenance                          : False
ServerContactedFqdn                         : LOCEXS04.VARUNAGROUP.DE
HealthInfoCreateTime                        : 15.06.2018 15:16:19
HealthInfoLastUpdateTime                    : 17.02.2020 09:11:11
ServerFoundInAD                             : CurrentState: Active; LastActiveTransition: 15.06.2018 15:22:16;
                                              LastInactiveTransition:
InMaintenance                               : CurrentState: Inactive; LastActiveTransition: 17.01.2020 09:07:02;
                                              LastInactiveTransition: 17.01.2020 10:42:02
AutoActivationPolicyBlocked                 : CurrentState: Inactive; LastActiveTransition: 09.01.2020 10:14:50;
                                              LastInactiveTransition: 09.01.2020 11:00:51
ActivationDisabledAndMoveNow                : CurrentState: Inactive; LastActiveTransition: ; LastInactiveTransition:
                                              15.06.2018 15:22:16
HighAvailabilityComponentStateOffline       : CurrentState: Inactive; LastActiveTransition: 17.01.2020 09:07:02;
                                              LastInactiveTransition: 17.01.2020 10:42:02
CriticalForMaintainingAvailability          : CurrentState: Inactive; LastActiveTransition: 31.01.2020 16:52:49;
                                              LastInactiveTransition: 31.01.2020 16:56:49
CriticalForMaintainingRedundancy            : CurrentState: Active; LastActiveTransition: 29.01.2020 11:43:06;
                                              LastInactiveTransition: 29.01.2020 11:42:06
PotentiallyCriticalForMaintainingRedundancy : CurrentState: Active; LastActiveTransition: 01.02.2020 05:49:37;
                                              LastInactiveTransition:
CriticalForRestoringAvailability            : CurrentState: Inactive; LastActiveTransition: 06.05.2019 09:16:36;
                                              LastInactiveTransition: 06.05.2019 09:20:36
CriticalForRestoringRedundancy              : CurrentState: Inactive; LastActiveTransition: 29.01.2020 11:42:06;
                                              LastInactiveTransition: 29.01.2020 11:43:06
HighForRestoringAvailability                : CurrentState: Inactive; LastActiveTransition: 29.01.2020 11:42:06;
                                              LastInactiveTransition: 29.01.2020 11:43:06
HighForRestoringRedundancy                  : CurrentState: Inactive; LastActiveTransition: 10.02.2020 09:05:02;
                                              LastInactiveTransition: 10.02.2020 09:06:02
IsSafeForMaintenance                        : CurrentState: Inactive; LastActiveTransition: 03.11.2019 09:42:35;
                                              LastInactiveTransition: 12.11.2019 06:29:58
IsValid                                     : True
ObjectState                                 : Unchanged

 

Interessant sind die Information in den Zeilen 24-27. Der CurrentState-Wert für die Status-Parameter CriticalForMaintainingRedundancy und PotentiallyCriticalForMaintainingRedundancy ist für beide Active. Das bedeutet, dass der Primary Activation Manager (PAM), zuständig für die Aktivierung von Datenbanken innerhalb der DAG, die Verfügbarkeit dieses Servers als kritisch einstuft, um die Verfügbarkeit der auf diesem Server konfigurieren Datenbankenkopien zu gewährleisten.

Für jeden Status-Parameter werden drei Informationen angezeigt:

  • CurrentState
    Dieser Wert gibt den aktuellen Status an
     
  • LastActiveTransition
    Dieser Zeitstempel gibt an, wenn der Wert zum letzen Mal auf Active gewechselt ist
     
  • LastInactiveTransition
    Dieser Zeitstempel gibt an, wenn der Wert zum letzen Mal auf Inactive gewechselt ist

 

Die unterschiedlichen Status-Parameter des Cmdlets werden in einem zukünftigen Blogartikel beschrieben.


Warum werden im Regelbetrieb zwei Server als nicht sicher für die Wartung angezeigt?

Der Grund hierfür ist recht simpel. Die auf den sechs Servern eingebunden Postfachdatenbanken werden aus Kapazitätsgründen mit einer unterschiedlichen Anzahl an Datenbankkopien betrieben. Die Datenbanken für Standardpostfächer werden mit jeweils vier Kopien betrieben, die gleichmäßig über alle sechs Server verteilt sind. Die Datenbanken für Archivpostfächer wiederum werden mit je drei Kopien je Postfachdatenbank betrieben. Mit diesen beiden Szenarien ist es jederzeit möglich, einen Exchange Server sicher in Wartung zu nehmen, ohne die Redundanz der Postfachdatenbanken zu gefährden.

Auf den Servern LOCEXS01 und LOCEXS04 sind jedoch auch Postfachdatenbanken eingebunden, die nur mit je zwei Kopien betrieben werden. Einen dieser beiden Server in Wartung zu nehmen würde bedeuten, dass während der Wartung keine Redundanz von Datenbanken mehr vorhanden ist. Dies ist der Grund, warum uns der PAM über das Cmdlet mitteilt, dass wir diese beiden Server nicht sicher in Wartung nehmen können.

 

Beispiel - Während einer Wartung

Das folgende Beispiel zeigt den Betriebszustand der Mitgliedsserver der DAG, während der Server LOCEXS06 in Wartung ist. Auf dem Server wurden zu diesem Zeitpunkt die monatlichen Windows Updates installiert.

Der Exchange Server wurde mit Hilfe des PowerShell-Skriptes StartDagServerMaintenance.ps1 in Wartung genommen.

 

Get-MailboxServerRedundancy -DatabaseAvailabilityGroup indag01

Identity        IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
                InAD          ance
--------        ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01        True          False       Prohibited    False              17.02.2020 11:04:12
LOCEXS02        True          False       Normal        True               17.02.2020 11:04:12
LOCEXS03        True          False       Prohibited    False              17.02.2020 11:04:12
LOCEXS06        True          True        High          True               17.02.2020 11:04:12
LOCEXS05        True          False       Prohibited    False              17.02.2020 11:04:12
LOCEXS04        True          False       Prohibited    False              17.02.2020 11:04:12

Wenn sich ein Server innerhalb der DAG in Wartung befindet, wirkt sich dies natürlich auch auf die verbleibenden Server aus. Weitere zwei Server (LOCEXS03 und LOCEXS05) können nicht sicher zusätzlich in Wartung genommen werden, da ansonsten die redundante Verfügbarkeit der Postfachdatenbanken nicht mehr gewährleistet ist.

 

Beispiel - Nach einer Wartung

Der durchgeführter Installation der Windows Updates oder eines Kumulativen Updates, wird die Wartung des Servers mit StopDagServerMaintenance.ps1 wieder beendet. 

Get-MailboxServerRedundancy -DatabaseAvailabilityGroup indag01

Identity        IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
                InAD          ance
--------        ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01        True          False       Prohibited    False              17.02.2020 11:23:12
LOCEXS02        True          False       Normal        True               17.02.2020 11:23:12
LOCEXS03        True          False       Normal        True               17.02.2020 11:23:12
LOCEXS06        True          False       High          True               17.02.2020 11:23:12
LOCEXS05        True          False       Normal        True               17.02.2020 11:23:12
LOCEXS04        True          False       Prohibited    False              17.02.2020 11:23:12

 

Der Server ist zwar nicht mehr im Wartungsmodus, jedoch ist der Status der RepairUrgency weiterhin auf High, da die Exchange Replication Engine damit beschäftigt ist, die während der Wartung aufgelaufenen Protokolldateien einzuspielen und die Suchindizes zu aktualisieren.

 

Tipp

  • Wenn Sie für einen Exchange Server, der nicht sicher in Wartung genommen werden kann, den Wartungsmodus mit StartDagServerMaintenance.ps1 -serverName [SERVER] aktivieren möchten, wird es zu einer Fehlermeldung kommen.

    In diesem Fall müssen Sie den Wartungsmodus mit folgendem Aufrauf aktivieren

.\StartDagServerMaintenance.ps1 -serverName SERVERNAME -overrideMinimumTwoCopies:$true

 

Viel Spaß mit Exchange Server!

 

 

Weiterlesen »