Dem Armin sei Seidn

Dem Armin sei Schmierzettel

Archive for the ‘IT’ Category

Exchange 2013 Serverzertifikat erstellen

leave a comment

Quelle: http://www.msblog.eu/exchange-2013-serverzertifikat-erstellen/

 

Nach der Installation eines Exchange 2013 Servers sollten Sie als nächsten Schritt ein Zertifikat beantragen. Ein Zertifikat von der internen CA ist dabei vollkommen ausreichend.

Folgende Namen sollten auf diesen Zertifikat erscheinen:

  • Server
  • Server.domäne.local
  • mail.domäne.eu (Steht z.B. für den externen Namen von Outlook Web Access)
  • outlook.domäne.eu (Steht z.B. für den externen Namen Outlook Anywhere)
  • autodiscover.domäne.local (wird ab Outlook 2007 z.B. für Abwesenheitsassistenten benötigt.
  • autodiscover.domäne.eu

Auf dem internen Zertifikat können ruhig alle Namen in einem Zertifikat zusammen gefasst werden. Wenn Sie später z.B. Outlook Web Access über ein TMG 2010 Server ins Internet veröffentlichen, würde ich Ihnen empfehlen, hierfür ein gesondertes Zertifikat zu erstellen, welches nur den externen Namen enthält.

Nun sind alle Informationen vorhanden, um das Zertifikat zu beantragen:

Öffnen Sie die Exchange Verwaltungskonsole
Exchange2013_Zertifikat_01
Klicken Sie unter „Server“ und „Zertifikate“ auf „+“ …
Exchange2013_Zertifikat_02
Erstellen Sie eine neue Anforderung für die Zertifizierungsstelle
Exchange2013_Zertifikat_03
Da wird nur nur eine Domäne haben, brauchen wir hier keine Stammdomäne eintragen.
Exchange2013_Zertifikat_04
Wählen Sie aus, auf welchen Exchange Servern die Zertifikatsanforderung gespeichert werden soll.
Exchange2013_Zertifikat_05
Bitte tragen Sie in die entsprechenden Felder die erforderlichen Daten ein.
Exchange2013_Zertifikat_06
Als Default Name empfehle ich Ihnen immer den internen Servernamen.
Exchange2013_Zertifikat_07
Allgemeine Informationen zu Ihrem Unternehmen…
Exchange2013_Zertifikat_08
Bitte wählen Sie einen entsprechenden Speicherort für die Zertifikatsanforderung aus. (Der Speicherort muss immer als UNC Pfad angegeben werden)
Exchange2013_Zertifikat_09
Bitte starten Sie den Browser und öffnen die URL der Zertifizierungsstelle. Wenn Sie intern noch keine Zertifizierungsstelle installiert haben, gehen Sie bitte folgendermaßen vor:
Installation Zertifizierungsstelle Windows Server 2008 -> https://www.msblog.eu/microsoft-zertifizierungsstelle-installieren/
Installation Zertifizierungsstelle Windows Server 2012 -> https://www.msblog.eu/windows-server-2012-zertifizierungsstelle-installieren/
Exchange2013_Zertifikat_10
Bitte wählen Sie erweiterte Zertifikatsanforderung aus..
Exchange2013_Zertifikat_11
Sie wollen eine bestehende Anforderung einsenden..
Exchange2013_Zertifikat_12
Bitte kopieren Sie den Inhalt von der .req Datei, welche Sie von der Exchange Console abgespeichert haben. Sie können die Datei mit einem Editor öffnen.
Als Zertifikatsvorlage wählen Sie bitte „Webserver“ aus und klicken auf „Einsenden“
Exchange2013_Zertifikat_13
Bestätigen Sie den Vorgang…
Exchange2013_Zertifikat_14
Laden Sie das Zertifikat herunter und speichern Sie in einen entsprechenden Pfad ab. (Dieser Pfad sollte wieder per UNC erreichbar sein)
Exchange2013_Zertifikat_15
Wechseln Sie wieder in die Exchange Verwaltungskonsole unter „Server“ und dann Zertifikate
Exchange2013_Zertifikat_16
Tragen Sie den entsprechenden Pfad für das Zertifikat ein, welches Sie von der Zertifizierungsstelle heruntergeladen haben und bestätigen Sie mit „OK“.
Exchange2013_Zertifikat_17
In Anschluss müssen wir den Zertifikat noch die entsprechenden Dienste zuweisen. Wählen Sie also das neue Zertifikat aus und klicken auf „bearbeiten“.
Exchange2013_Zertifikat_18
Wählen Sie hier bitte die entsprechenden Dienste aus, welche für das Zertifikat verwendet werden sollen.

Exchange2013_Zertifikat_19
Sollten Sie schon ein Zertifikat auf ein bestehenden Service hinterlegt haben, bestätigen Sie bitte, dass dieses nun ausgetauscht wird.

da ich im Zertifikat die Meldung hatte „… nicht vertrauenswürdidg“ und die Aufforderung hatte es im Speicher zu installieren, habe ich zunächst ewig nach dem Fehler gesucht.
Nach dem auch kein Neustart geholfen hat, habe ich das Zertifikat neu erstellt, gleicher Fehler.
Nach gpupdate /force ist das Zertifikat nun gültig und auch im Zertifikat ist der Hinweis nun weg.

Written by Armin Senger

Oktober 5th, 2016 at 11:01 pm

Posted in IT

2012R2 Hyper-V Replication und Zertifikate

leave a comment

Leitfaden für die Einrichtung:
http://www.it-administrator.de/themen/virtualisierung/fachartikel/191651.html

Hyper-V-Replica einrichten und betreiben (1)

Windows Server 2012 R2 verbessert die Ausfallsicherheit und Hochverfügbarkeit von Hyper-V deutlich. Bereits mit Windows Server 2012 führte Microsoft die Replikation von virtuellen Servern zwischen Hyper-V-Hosts ein, doch mit Hyper-V-Replica lassen sich virtuelle Server noch besser zwischen maximal drei Hyper-V-Hosts replizieren und synchron halten. Windows Server 2012 unterstützt in diesem Bereich nur zwei Hyper-V-Hosts für die Replikation. In der neuen Version können Administratoren die Replikation auch wie eine Serverkette anordnen. Dieser Workshop zeigt Ihnen, wie Sie Hyper-V-Replica für Stand-Alone-Server und Cluster einrichten und betreiben.
Hyper-V-Replica sind das doppelte Lottchen der Server-Virtualisierung.

Die Replikation der Serverdaten findet über das Dateisystem und das physische Netzwerk statt und benötigt weder spezielle Hardware noch Cluster. Die Replikationen lassen sich manuell oder nach einem Zeitplan durchführen. Produktiv ist Hyper-V-Replica sinnvoll, wenn Sie Hyper-V-Hosts vor Ausfall schützen wollen. Fällt ein Hyper-V-Server aus, können Sie die replizierten Server auf einem anderen Server aktiv schalten. Mit Hyper-V-Replica erlangen also auch kleine Umgebungen eine effiziente Ausfallsicherheit, ohne dazu auf spezielle Hardware oder einen Cluster zurückgreifen zu müssen.

In Windows Server 2012 ließ sich das kürzeste Synchronisierungsintervall auf fünf Minuten anpassen. Mit Windows Server 2012 R2 reduziert sich dieser Intervall auf 30 Sekunden, in denen die Daten zwischen den Hosts replizieren. Außerdem können Sie die Replikation auf bis zu 15 Minuten ausdehnen. Die Flexibilität hat sich also deutlich erhöht.

Hyper-V-Hosts für Replikation aktivieren
Hyper-V-Replica konfigurieren Sie entweder im Hyper-V-Manager, dem System Center Virtual Machine Manager 2012 R2 oder mit der PowerShell. Am einfachsten nehmen Sie die Einrichtung über einen Assistenten im Hyper-V-Manager vor. Dies ist auch im produktiven Betrieb möglich. Die Quell-VM läuft bei diesem Vorgang weiter und die Benutzer werden nicht beeinträchtigt. Natürlich kann die Übertragung der Serverdaten auf die Zielserver die Quell-Hosts etwas beeinträchtigen, Sie können nach der Einrichtung aber auch festlegen, dass die erste Übertragung zu den Ziel-Hyper-V-Hosts erst zu bestimmten Zeiten stattfinden soll, an denen keine Benutzer mit den virtuellen Servern auf dem Quellserver arbeiten.

Fällt ein Hyper-V-Host aus, lassen sich die replizierten Server online schalten, sobald diese eine aktuelle Kopie nutzen können. Da der Servername, die IP-Adresse und andere Einstellungen im virtuellen Server gespeichert sind, können die Benutzer nahezu uneingeschränkt weiter arbeiten. Nach der ersten Übertragung müssen nur noch Änderungen gesendet werden. Die erste Übertragung können Sie mit einem externen Datenträger vornehmen.

Die Replikation ist auch in Clustern möglich. In diesem Fall starten Sie die Replikation über das Kontextmenü des virtuellen Servers in der Failovercluster-Verwaltung. Die Einrichtung entspricht der Konfiguration ohne Cluster. Die Einstellungen für die Replikation nehmen Sie in diesem Fall ebenfalls in der Clusterverwaltung vor, indem Sie mit der rechten Maustaste auf den virtuellen Server klicken. In einem solchen Szenario können Sie virtuelle Server zum Beispiel zwischen einem Hyper-V-Cluster mit einem anderen Hyper-V-Cluster replizieren oder Sie lassen virtuelle Server von einem Cluster auf einen Standby-Server replizieren. Die Nutzung der Hyper-V-Replikation in einem Cluster ist allerdings optional. Alle Funktionen sind auch für alleinstehende Server verfügbar.

Damit Hyper-V-Hosts eine solche Replikation erlauben, müssen Sie diese zunächst für die einzelnen Hyper-V-Hosts aktivieren. Danach wählen Sie die virtuellen Server aus, die Sie replizieren lassen wollen. Dazu starten Sie den Assistenten über das Kontextmenü des gewünschten virtuellen Servers auf dem Quellserver, geben den Zielserver ein – also den Hyper-V-Host, auf den Sie den virtuellen Server replizieren wollen – und legen danach noch Zeitplan und weitere Einstellungen fest. Der virtuelle Server auf dem Quellserver bleibt aber weiterhin verfügbar und aktiv. Auf die Details kommen wir gleich zu sprechen. Sie müssen natürlich nicht alle virtuellen Server auf einem Hyper-V-Host replizieren lassen. Außerdem können Sie virtuelle Server zu verschiedenen Hyper-V-Hosts replizieren.

Damit ein Hyper-V-Host für Replikate zur Verfügung steht, müssen Sie auf dem Server in den Hyper-V-Einstellungen im Bereich „Replikationskonfiguration“ die Funktion aktivieren und an Ihre Bedürfnisse anpassen. Sie legen in diesem Bereich zum Beispiel die Verschlüsselung und Authentifizierung fest und von welchen Hyper-V-Hosts der aktuelle Server Replikate annimmt. Im ersten Schritt aktivieren Sie daher zunächst die Funktion, Einstellungen nehmen Sie noch keine vor.

Hyper-V-Replica steht uneingeschränkt auch auf Servern mit Hyper-V-Server 2012 R2 zur Verfügung. Setzen Sie diesen ein, lässt sich dieser Server optional über den Hyper-V-Manager von einem anderen Hyper-V-Host verwalten. Einstellungen bezüglich der Replikation können Sie auch über das Netzwerk vornehmen. Es gibt hier keine Unterschiede zu Windows Server 2012 R2.


Die zertifikatsbasierte Authentifizierung der Hyper-V-Replikation
muss zunächst auf dem entsprechenden Host eingerichtet werden.

Achten Sie während der Einrichtung von Hyper-V-Replica auch darauf, die notwendigen Regeln in der erweiterten Konfiguration der Firewall zu aktivieren. Der Einrichtungsassistent übernimmt nur die notwendigen Einstellungen in Hyper-V, ändert aber keinerlei Sicherheitseinstellungen auf dem Server oder aktiviert Firewall-Regeln. Die Firewall-Regel hat die Bezeichnung „Hyper-V-Replica HTTP-Listener“. Es gibt auch einen Listener für HTTPS, wenn Sie die Daten verschlüsselt übertragen wollen. Das ist in jedem Fall sinnvoll, vor allem in Produktivumgebungen. Bei den Regeln handelt es sich um eingehende Netzwerkregeln, für den ausgehenden Datenverkehr müssen Sie keine Änderungen vornehmen, da die Windows-Firewall diesen Verkehr ohnehin nicht blockiert.

Bei der Kerberos-Authentifizierung und der Verwendung von HTTP werden die replizierten Daten während der Übertragung nicht verschlüsselt. Nur bei der zertifikatbasierten Authentifizierung mit HTTPS verschlüsselt Hyper-V die Daten während der Übertragung. Den Namen der Firewall-Regel für HTTP sehen Sie in der Firewall-Verwaltung. Die Verwendung des Befehls ist analog zur http-Regel. Arbeiten Sie mit Hyper-V-Replica über HTTP, aktivieren die Firewall-Regel in der PowerShell mit

Enable-Netfirewallrule -displayname "Hyper-V Replica HTTP Listener (TCP-In)"

Hyper-V-Replikation mit SSL konfigurieren
In Produktions-Umgebungen sollten Sie die Daten virtueller Server SSL-verschlüsselt mit HTTPS übertragen. Das ist wesentlich sicherer und nicht sehr viel komplizierter in der Einrichtung. In diesem Fall weisen Sie den beteiligten Hyper-V-Hosts ein Zertifikat zu. Dazu müssen Sie Zertifikate verwenden, die Clients und Server authentifizieren können. Das Zertifikat muss dem Namen des Hyper-V-Hosts entsprechen. Sie haben hier die Möglichkeit, mit selbst signierten Zertifikaten zu arbeiten oder greifen auf Zertifikate der Active Directory-Zertifikatsdienste zurück. Wir zeigen Ihnen nachfolgend wie Sie die Einrichtung vornehmen.

In der lokalen Verwaltung von Zertifikaten auf einem Server mit Windows Server 2012 R2 installieren Sie im Active Directory Zertifikate auf einem Hyper-V-Hosts. Die Zertifikate kommen anschließend für die Authentifizierung der beteiligten Hyper-V-Hosts in der Replikation zum Einsatz.

Zunächst starten Sie über certlm.msc im Startbildschirm die Verwaltung der lokalen Zertifikate auf dem ersten Hyper-V-Host. Klicken Sie mit der rechten Maustaste auf „Eigene Zertifikate“ und wählen Sie „Alle Aufgaben / Neues Zertifikat anfordern“. Bestätigen Sie die Option „Active Directory-Registrierungsrichtlinie“ und aktivieren Sie danach die Option „Computer“ und klicken Sie dann auf „Registrieren“. Das Zertifikat wird jetzt in der Konsole angezeigt.

Sie können Zertifikate auch in der Befehlszeile erstellen. Das ist zum Beispiel für geskriptete Umgebungen sinnvoll. Um ein Zertifikat zu registrieren, erstellen Sie eine Text-Datei, mit der Sie danach eine Anfrage bei der Zertifizierungsstelle starten. Hierbei kann es sich um eine externe oder eine interne Zertifizierungsstelle handeln. Speichern Sie dazu die Textdatei mit dem folgenden Inhalt. Passen Sie den Servernamen in der vierten Zeile „Subject“ an Ihre Bedürfnisse an:

[Version]
Signature="$Windows NT$"
[NewRequest]
Subject = "CN=SERVER.CONTOSO.COM"
Exportable = TRUE ; Private key is exportable
KeyLength = 2048 ; Common key sizes: 512, 1024, 2048, 4096, 8192, 16384
KeySpec = 1 ; AT_KEYEXCHANGE
KeyUsage = 0xA0 ; Digital Signature, Key Encipherment
MachineKeySet = True ; The key belongs to the local computer account
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = CMC
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ;Server Authentication
OID=1.3.6.1.5.5.7.3.2 ;Client Authentication

Speichern Sie die Datei anschließend unter dem Namen replica.inf ab. Achten Sie auf die korrekte Endung der Datei. Auf Basis der Daten in dieser Datei erstellen Sie danach in der Befehlszeile eine weitere Datei mit der dazugehörigen Zertifikatsanfrage:

certreq -new replica.inf replica.req

Wechseln Sie dazu in das Verzeichnis, in dem Sie die INF-Datei gespeichert haben. Anschließend befinden sich zwei Dateien in diesem Verzeichnis. Mit der REQ-Datei stellen Sie bei Ihrer internen Zertifizierungsstelle – etwa den Active Directory-Zertifikatsdiensten – eine Online-Anfrage. Dazu verwenden Sie den Befehl:

certreq -submit -config "dc01.contoso.int\contoso-dc01-ca" 
 Replica.req replica.cer

Erhalten Sie eine Fehlermeldung, zum Beispiel, dass die Zertifikatvorlage nicht in Ordnung ist, verwenden Sie zusätzlich die Option „-attrib CertificateTemplate: Vorlage“. Alternativ erstellen Sie einen „Certifikate Signing Request“ (CSR). Mit dieser führen Sie eine Anfrage bei einer externen Zertifizierungsstelle durch. Aber auch von internen Zertifizierungsstellen können Sie diese Daten nutzen, zum Beispiel mit der Weboberfläche der Zertifikatsdienste. Dazu verwenden Sie den folgenden Befehl:

certutil -encode replica.req replica.csr

Anschließend öffnen Sie die CSR-Datei mit einem Texteditor und kopieren den Inhalt in die Zwischenablage. Mit diesen Daten schließen Sie die Anfrage ab. Rufen Sie dazu im lokalen Zertifikatespeicher des Servers (certlm.msc) die eigenen Zertifikate auf und lassen Sie sich die Eigenschaften des Zertifikats anzeigen. Sie sehen bei der erweiterten Verwendung des Schlüssels die „Client- und Serverauthentifizierung“, ohne die Sie ein Zertifikat nicht für Hyper-V-Replication nutzen können.

Im zweiten Teil des Workshops lesen Sie, wie Sie bei der Replikation mit selbstsignierten Zertifikaten arbeiten, virtuelle Server zwischen Hyper-V-Hosts replizieren und wie Sie ein Failover mit Hyper-V-Replica durchführen.

 

Hyper-V-Replica einrichten und betreiben (2)

Windows Server 2012 R2 verbessert die Ausfallsicherheit und Hochverfügbarkeit von Hyper-V deutlich. Bereits mit Windows Server 2012 führte Microsoft die Replikation von virtuellen Servern zwischen Hyper-V-Hosts ein, doch mit Hyper-V-Replica lassen sich virtuelle Server noch besser zwischen maximal drei Hyper-V-Hosts replizieren und synchron halten. Windows Server 2012 unterstützt in diesem Bereich nur zwei Hyper-V-Hosts für die Replikation. In der neuen Version können Administratoren die Replikation auch wie eine Serverkette anordnen. In diesem zweiten Teil des Workshops lesen Sie, wie Sie bei der Replikation mit selbstsignierten Zertifikaten arbeiten, virtuelle Server zwischen Hyper-V-Hosts replizieren und wie Sie ein Failover mit Hyper-V-Replica durchführen.
Hyper-V-Replica sind das doppelte Lottchen der Server-Virtualisierung.
Mit selbstsignierten Zertifikaten arbeiten
Alternativ zur Verwendung von richtigen Zertifikaten lässt sich auch mit selbstsignierten Zertifikaten auf den Hyper-V-Hosts arbeiten. In diesem Fall profitieren Sie von der Sicherheit der zertifikatsbasierte Authentifizierung, müssen aber keine komplizierten Maßnahmen vornehmen, um Zertifikate zu verwalten.

Dazu verwenden Sie makecert.exe aus dem Windows 8/8.1 SDK [1], das kostenlos zur Verfügung steht. Sie benötigen das Tool auf allen beteiligten Hyper-V-Hosts, um Zertifikate zu erstellen. Sie finden makecert.exe nach der Installation des Toolkits im Verzeichnis „C:\Program Files (x86)\ Windows Kits\8.0\bin\x64“. Die Installation kann auch auf einer Arbeitsstation erfolgen und lässt sich anschließend auf die beteiligten Server kopieren. Danach erstellen Sie zunächst auf dem ersten Server ein selbstsigniertes Zertifikat und dann auf den anderen Servern.

Für eine beispielhafte Replikation zwischen zwei Servern kopieren Sie zunächst makecert.exe auf alle beteiligten Hyper-V-Server. Nun öffnen Sie eine Befehlszeile auf dem ersten Server und geben den folgenden Befehl ein, um ein Zertifikat für eine Stammzertifizierungsstelle zu erstellen:

makecert -pe -n "CN=PrimaryRootCA" -ss root -sr LocalMachine 
 -sky signature -r "PrimaryRootCA.cer"

Geben Sie danach folgenden Befehl ein:

makecert -pe -n "CN=FQDN des Servers" -ss my -sr LocalMachine 
 -sky exchange -eku 1.3.6.1.5.5. 7.3.1,1.3.6.1.5.5.7.3.2 -in 
 "PrimaryRootCA" -is root -ir LocalMachine 
 -sp "Microsoft RSA SChannel Cryptographic Provider" 
 -sy 12 PrimaryCert.cer

Wechseln Sie danach auf den zweiten Server und führen Sie folgenden Befehl aus, um dort ein selbstsigniertes Stammzertifizierungsstellenzertifikat zu erstellen:

makecert -pe -n "CN=SecondaryRootCA" -ss root -sr LocalMachine 
 -sky signature -r "SecondaryRootCA.cer"

Nutzen Sie dann das Kommando

makecert -pe -n "CN=FQDN" -ss my -sr LocalMachine 
 -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 
 -in "SecondaryRootCA " -is root -ir LocalMachine 
 -sp "Microsoft RSA SChannel Cryptographic Provider" 
 -sy 12 SecondaryCert.cer

Jetzt liegen auf den Servern alle notwendigen Zertifikate vor. Diese müssen Sie jetzt noch auf den anderen Server kopieren. Kopieren Sie die Datei SecondaryRoot-CA.cer vom zweiten Server auf den primären Server und geben Sie anschließend den folgenden Befehl ein:

certutil -addstore -f Root "SecondaryRootCA.cer"

Kopieren Sie danach PrimaryRootCA.cer vom primären Server auf den Replikatserver und geben Sie danach

certutil -addstore -f Root "PrimaryRootCA.cer"

ein. Jetzt vertrauen die beiden Server sich jeweils gegenseitig, was die Ausstellung von Zertifikaten betrifft. Öffnen Sie danach auf beiden Servern den Registry-Editor und navigieren Sie zu „HKLM \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Virtualization \ Replication“. Hier setzen Sie den Wert „DisableCertRevocationCheck“ auf „1“. Wenn vorhanden, navigieren Sie zu „HKLM \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Virtualization \ FailoverReplication“ und setzen auch hier den Wert „DisableCertRevocationCheck“ auf „1“.

Achten Sie darauf, dass die erstellten Zertifizierungsstellen auf den beiden Servern, auf denen Sie die selbst signierten Zertifikate erstellt haben, als vertrauenswürdig angezeigt werden. Sie sehen die Zertifikate im Zertifikatespeicher der Server. Diesen rufen Sie über certlm.msc auf. Ohne diese Zertifikate können Sie später Hyper-V-Replica nicht einrichten.

Wollen Sie Hyper-V-Replica im Cluster nutzen, müssen Sie zusätzlich einen Hyper-V-Replica Broker im Clustermanager von Windows Server 2012 R2 erstellen. Dabei gehen Sie vor wie bei jeder anderen Clusterressource auch. In diesem Fall sollten Sie aber erst ein neues Computerkonto im Snap-In „Active Directory-Benutzer und -Computer“ erstellen. Rufen Sie die Registerkarte „Sicherheit“ des neuen Kontos auf und geben Sie dem Computerkonto des Clusters „Vollzugriff „.

Um SSL für die Replikation zu nutzen, rufen Sie anschließend auf beiden Hyper-V-Servern die Hyper-V-Einstellungen auf und klicken auf „Replikationskonfiguration“. Dort aktivieren Sie die Option „Zertifikatbasierte Authentifizierung verwenden (HTTPS)“ und wählen das Zertifikat aus. Diese Einstellungen müssen Sie auf allen beteiligten Servern vornehmen. Richten Sie danach die Replikation ein. Erscheinen hier Fehler, sind die Zertifikate nicht korrekt. Überprüfen Sie in diesem Fall die vorangegangenen Schritte.

Virtuelle Server zwischen Hyper-V-Hosts replizieren
Um virtuelle Server zwischen Hyper-V-Hosts mit Windows Server 2012 R2 oder Hyper-V Server 2012 R2 zu replizieren, klicken Sie mit der rechten Maustaste auf den entsprechenden virtuellen Server und wählen „Replikation aktivieren“. Auch wenn Sie die Replikation generell für den Hyper-V-Hosts aktiviert haben, werden nicht automatisch alle virtuellen Server repliziert, sondern Sie müssen diese Einstellungen für jede einzelne VM wiederholen. Die Einrichtung erfolgt über einen Assistenten, mit dem Sie festlegen, wie Sie den ausgewählten virtuellen Server vom Quellserver auf den Zielserver replizieren wollen. Der virtuelle Server auf dem Quellserver bleibt dabei unverändert und muss auch nicht neu gestartet oder herunter gefahren werden.

Im Assistenten legen Sie danach die Zielserver und auch den Authentifizierungstyp für die Datenübertragung fest. Für Testumgebungen können Sie hier auch die Kerberos-HTTP-Übertragung verwenden. So sparen Sie sich die Einrichtung von Zertifikaten. Allerdings ist die Verwendung der zertifikatsbasierten Authentifizierung wesentlich besser geeignet, auch in einer Testumgebung. Welche Authentifizierung der Zielserver akzeptiert, legen Sie auf dem Zielserver in den Hyper-V-Einstellungen über „Replikationskonfiguration“ fest. Hier steuern Sie genau, welchen Datenverkehr der Zielserver überhaupt zulässt.


Für jede Replikation lassen sich die Verbindungsparameter einzeln festlegen.

Haben Sie, wie zuvor gezeigt, auf den Servern Zertifikate installiert und in den Hyper-V-Einstellungen hinterlegt sowie die zertifikatsbasierte Authentifizierung aktiviert, können Sie für die Datenübertragung auch diesen sicheren Authentifizierungstyp wählen. Zusätzlich steuern Sie während der Einrichtung auch, welche virtuellen Festplatten der Server Sie replizieren wollen. Sie müssen nicht unbedingt alle Festplatten zwischen Quell- und Zielserver replizieren. Außerdem legen Sie hier auch das Intervall für die Replikation fest.

Im Assistenten zur Einrichtung der Hyper-V-Replikation lassen sich die Snapshots des virtuellen Servers berücksichtigen. Hier legen Sie auch fest, ob Sie die erste Replikation nach der Einrichtung über ein Speichermedium wie eine externe Festplatte durchführen oder über das Netzwerk. Auch einen Zeitplan für die erste Übertragung legen Sie während der Einrichtung fest.

Wenn Sie die Replikation durchgeführt haben, befindet sich der virtuelle Server auf den konfigurierten Zielservern, bleibt aber ausgeschaltet. Das ist auch sinnvoll, da der replizierte Server über den gleichen Namen und die gleiche IP-Adresse wie der Quellserver verfügt. Über das Kontextmenü des virtuellen Servers auf dem Quellserver passen Sie das Replikationsverhalten an und erhalten den Status. Die Replikation von virtuellen Servern können Sie auch zwischen verschiedenen Editionen von Windows Server 2012 R2 durchführen oder Hyper-V Server 2012 R2 als Quell- und Zielserver zu nutzen.

Über das Kontextmenü des replizierten virtuellen Servers auf dem Zielserver können Sie auch ein Failover durchführen. In einem solchen Fall übernimmt das Replikat die Aufgaben des virtuellen Servers auf dem Quellserver. Natürlich lässt sich die Replikation jederzeit beenden oder pausieren. Bei jeder neuen Replikation legt Hyper-V auf dem Zielserver auch einen Snapshot des replizierten virtuellen Servers an. Mit dem Cmdlet „MeasureVMReplication“ erhalten Sie den Status der Replikate auf den einzelnen Hyper- V-Hosts in der PowerShell.

Failover mit Hyper-V-Replica durchführen
Der Sinn von Hyper-V-Replica ist, dass Sie bei Ausfall eines Hyper-V-Hosts ein Failover zu einem anderen Hyper-V-Host durchführen können. Dazu klicken Sie den entsprechenden virtuellen Server im Hyper-V-Manager an und wählen im Kontextmenü „Replikation / Failover“. Für ein geplantes Failover starten Sie das Failover vom Server, auf dem Sie die Quell-VM betreiben. Vorteil dabei ist, dass noch einmal eine Replikation stattfindet, sodass der Zielserver dann über alle aktuellen Daten des Quellservers verfügt.

Anschließend wählen Sie aus, zu welchem Wiederherstellungspunkt Sie den Failover durchführen wollen und starten diesen anschließend. Das funktioniert aber nur, wenn die Quell-VM ausgeschaltet ist. Während des Failovers startet der Assistent den replizierten Server, der im Netzwerk dann exakt mit den Daten der ursprünglichen Quell-VM zur Verfügung steht.

Auch bei einem geplanten Failover müssen Quell-VM und Ziel-VM ausgeschaltet sein. Der Vorteil bei einem geplanten Failover auf dem Quell-Hyper-V-Host ist, dass Hyper-V noch nicht replizierte Daten an den Zielserver senden kann. Dieser verfügt anschließend über den neuesten Stand aller Daten der Quell-VM. Wenn Sie ein geplantes Failover durchgeführt haben, ist die ursprüngliche Quell-VM anschließend die neue Ziel-VM und die bisherige Ziel-VM die neue Quell-VM für die Replikation. Das heißt, Sie können diesen Vorgang auch wieder umkehren. Alle dazu notwendigen Aufgaben steuern Sie über den Hyper-V-Manager oder die PowerShell.

Fazit
Unternehmen, die mehrere Hyper-V-Hosts einsetzen, aber keinen Cluster betreiben wollen, sollten einen Blick auf die Möglichkeiten von Hyper-V-Replica werfen. Denn damit erhalten IT-Verantwortliche hohe Verfügbarkeit quasi zum Nulltarif. Die Einrichtung ist schnell abgeschlossen und der Nutzen kann enorm sein, vor allem wenn ein Hyper-V-Host komplett ausfällt. Gleichzeitig bringen die neuen Features von Windows Server 2012 R2 in diesem Bereich ein neues Maß an Flexibilität für den Administrator.

 
 

Erstellung der Zertifikate:
http://www.c-fi.de/8-blog/8-hyper-v-2012-r2-replikation-mit-hilfe-von-selbst-signierten-zertifikaten-keine-domaene-benoetigt.html

 

Diese Kleine Anleitung schreibe ich für mich, quasi als Dokumentation der notwendigen Schritte…

Ich gehe davon aus, dass die Hyper-V Verwaltungstools bereits Verfügbar sind. Idealer Weise direkt bei einem Windows Server 2012R2, wo die Hyper-V Verwaltungstools installiert wurden bzw. dieser auch gleich als Hyper-V Host dient. Des weiteren wird von 2 Hyper-V Hosts ausgegangen. Diese müssen nicht in der gleichen Arbeitsgruppe sein.

  • Die lokalen Server müssen trotz nichtangehörigkeit einer Domäne einen eindeutigen Domänennamen haben und darüber im Netzwerk erreichbar sein. Der Name muss also erfolgreich auflösen. Das erreicht man, indem man bei den Computereigenschaften, wo man die Arbeitsgruppe oder Domöne einstellen kann, unter den erweiteren Einstellungen den Domänensuffix einträgt. In diesem Beispiel sei dies mal: yourdomain.ending. Zusätzlich sollte man beide Hyper-V Hosts in der HOSTS-Datei in Windows\System32\drivers\etc\hosts eintragen (zwischen IP und Name ein TAB). Dies ist vorallem wichtig, wenn ein Domain-Controller als Virtuelle Maschine läuft. Dann ist beim Start der Hyper-V Hosts kein DNS Server verfügbar und die beiden würden sich nicht finden!
    • 10.0.0.1     hypervhost1.yourdomain.ending
      10.0.0.2     hypervhost2.yourdomain.ending
  • Windows Software Development Kit (SDK) for Windows 8 herunterladen und installieren. Aus dem SDK das Tool “makecert.exe” extrahieren und auf die Hyper-V Hosts kopieren.
  • Auf beiden Hyper-V Hosts die Firewall für die Replizierung öffnen:
    • netsh advfirewall firewall set rule group="Hyper-V-Replikat - HTTPS" new enable=yes
  • Mit Hilfe des makecert – Tools nun die Zertifikate erstellen. Falls mal ein Hyper-V Host ausfällt sollte man gleich zwei CAs erstellen damit man, wenn nötig, neue Zertifikate ausstellen kann.
    • Auf dem ersten Host (hier: hypervhost1.yourdomainname.ending) folgende Befehle in der Powershell ausführen:
    • > makecert -pe -n "CN=HV1RootCA" -ss root -sr LocalMachine -sky signature -r "HV1RootCA.cer"
      > makecert -pe -n "CN=hypervhost1.yourdomainname.ending" -ss my -sr LocalMachine -sky exchange -eku "1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2" -in "HV1RootCA" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 HV1Cert.cer
    • Auf dem zweiten Host (hier: hypervhost2.yourdomainname.ending) folgende Befehle in der Powershell ausführen:
    • > makecert -pe -n "CN=HV2RootCA" -ss root -sr LocalMachine -sky signature -r "HV2RootCA.cer"
      > makecert -pe -n "CN=hypervhost2.yourdomainname.ending" -ss my -sr LocalMachine -sky exchange -eku "1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2" -in "HV2RootCA" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 HV2Cert.cer
  • Die “*.CA.cer”-Dateien auf den jeweils anderen Host kopieren. Auf dem ersten Host das Zertifikat importieren:
    • certutil -addstore -f Root "HV2RootCA.cer"
  • Auf dem zweiten Host ebenfalls:
    • certutil -addstore -f Root "HV1RootCA.cer"
  • Auf beiden muss noch die Überprüfung der Sperre eines Zertifikats ausgeschaltet werden, sonst klappt es nicht:
    • reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

Das war es. Nun kann die Replizierung konfiguriert werden. Der Rest sollte durch die Assistenten selbsterklärend sein.

https://developer.microsoft.com/en-us/windows/downloads/windows-8-sdk

sonstiges:
https://www.one-tab.com/page/4W2iTGnERdetIr51d0n0Mw

Suche nach Windows Updates dauert ewig? – Eine mögliche Lösung
windows 2012 r2 hyper v replication – Google-Suche
Windows Server 2012: Replizierung virtueller Maschinen | ZDNet.de
Step-By-Step: Virtual Machine Replication Using Hyper-V Replica – CANITPRO
Hyper-V-Replica einrichten und betreiben (1) | it-administrator.de
zertifikate hyper-v replikation erstellen – Google-Suche
Hyper-V 2012 R2 Replikation mit Hilfe von selbst signierten Zertifikaten (keine Domäne benötigt) – c-fi.de – IT Blog & more
Windows SDK for Windows 8 – Windows app development
 

Written by Armin Senger

September 28th, 2016 at 9:36 am

Posted in IT

.htaccess Generator von All-Inkl

leave a comment

Mal merken:

https://all-inkl.com/wichtig/htaccessgenerator/

https://all-inkl.com/wichtig/anleitungen/#skripte_sonstiges

Written by Armin Senger

September 22nd, 2016 at 4:22 pm

Posted in IT

Exchange 2010 OWA http Error 500 nach Anmeldung

leave a comment

Error 500 nach OWA Login auf einen Exchange 2010.

Mit sicher nicht die ultimative Lösung, jedoch bei meinem Problem war sie es.

net start msexchangefba

Und den Dienst auf Automatisch/Verzögert setzen.

Im deutsch ist er unter den Diensten mit folgenden Namen zu finden:

Formularbasierter Microsoft Exchange-Authentifizierungsdienst

Ermöglicht eine formularbasierte Authentifizierung bei Outlook Web App und der Exchange-Systemsteuerung. Wenn dieser Dienst beendet wird, führen Outlook Web App und die Exchange-Systemsteuerung keine Benutzerauthentifizierung durch.

Offizell:

http://technet.microsoft.com/en-us/library/ff360220(EXCHG.140).aspx

PLS

 

Quelle: http://rh-netzwerk.de/joomla/index.php/windows/87-exchange-2010-owa-bringt-fehler-500-nach-anmeldung

Written by Armin Senger

September 22nd, 2016 at 3:54 pm

Posted in IT

Windows IPv4 und IPv6

leave a comment

Quelle: https://support.microsoft.com/de-de/kb/929852
Quelle englisch (besser): https://support.microsoft.com/en-us/kb/929852

Text folgt ggf. noch 😉

How to disable IPv6 or its components in Windows

Important Internet Protocol version 6 (IPv6) is a mandatory part of Windows Vista and later versions of Windows. We do not recommend that you disable IPv6 or its components. If you do, some Windows components may not function. Additionally, system startup will be delayed for 5 seconds if IPv6 is disabled by incorrectly, setting the DisabledComponents registry setting to a value of 0xfffffff. The correct value should be 0xff. For more information, see the „What are Microsoft’s recommendations about disabling IPv6?“ question in IPv6 for Microsoft Windows: Frequently Asked Questions.
Manually disable or re-enable IPv6 or its components

Disable IPv6

You can disable IPv6 on the host computer through the DisabledComponents registry value. The DisabledComponents registry value affects all network interfaces on the host.

Important Follow the steps in this section carefully. Serious problems might occur if you modify the registry incorrectly. Before you modify it, back up the registry for restoration in case problems occur.

To disable certain IPv6 components, follow these steps:

  1. Click Start, type regedit in the Start Search box, and then click regedit.exe in the Programs list.
  2. In the User Account Control dialog box, click Continue.
  3. In Registry Editor, locate and then click the following registry subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\
  4. Double-click DisabledComponents to change the DisabledComponents entry.Note If the DisabledComponents entry is unavailable, you must create it. To do this, follow these steps:
    1. In the Edit menu, point to New, and then click DWORD (32-bit) Value.
    2. Type DisabledComponents, and then press Enter.
    3. Double-click DisabledComponents.
  5. Type any of the following values in the Value data field to configure the IPv6 protocol to the intended state, and then click OK:
    1. Type 0 to re-enable all IPv6 components (Windows default setting).
    2. Type 0xff to disable all IPv6 components except the IPv6 loopback interface. This value also configures Windows to prefer using IPv4 over IPv6 by changing entries in the prefix policy table. For more information, see Source and destination address selection.
    3. Type 0x20 to prefer IPv4 over IPv6 by changing entries in the prefix policy table.
    4. Type 0x10 to disable IPv6 on all nontunnel interfaces (both LAN and Point-to-Point Protocol [PPP] interfaces).
    5. Type 0x01 to disable IPv6 on all tunnel interfaces. These include Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), 6to4, and Teredo.
    6. Type 0x11 to disable all IPv6 interfaces except for the IPv6 loopback interface.

Use the DisabledComponents registry value to verify whether IPv6 is disabled. To do this, run the following command at a Windows command prompt:

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents

When you do this, you may receive the following error message:

ERROR: The system was unable to find the specified registry key or value.

If you receive this error message, the DisabledComponents registry value is not set. If the DisabledComponents value is set, it overrides the settings in the connection properties.

Disable IPv6 on a specific network adapter

You can do this by unbinding the adapter in the Local Area Connection Properties dialog box:

  1. Click Start, and then click Control Panel.
  2. Click Network and Sharing Center.
  3. In the View your active networks area, click Local Area Connection, and then click Properties.
  4. On the Networking tab, clear the Internet Protocol Version 6 (TCP/IPv6) check box, and then click OK.

Note The Internet Protocol Version 6 (TCP/IPv6) check box affects only the specific network adapter and will unbind IPv6 from the selected network adapter. To disable IPv6 on the host, use the DisabledComponents registry value. The DisabledComponents registry value does not affect the state of the check box. Therefore, even if the DisabledComponents registry key is set to disable IPv6, the check box in the Networking tab for each interface can still be checked. This is expected behavior.

Prefer IPv6 over IPv4 in prefix policies

  1. Find the current value data of DisabledComponents.
  2. Change the data to binary data. It will be a 32-bit binary value.
  3. Find the sixth bit of the data, and then set it to 0. Do not change any other bits. For example, if the current data is 11111111111111111111111111111111, the new data should be 11111111111111111111111111011111.
  4. Change the data from binary to hexadecimal.
  5. Set the hexadecimal value as the new value data for DisabledComponents.

Re-enable IPv6 on all nontunnel interfaces

  1. Find the current value data of DisabledComponents.
  2. Change the data to binary data. It will be a 32-bit binary value.
  3. Find the fifth bit of the data, and then set it to 0. Do not change any other bits. For example, if the source data is 11111111111111111111111111111111, the new data should be 11111111111111111111111111101111.
  4. Change the data from binary to hexadecimal.
  5. Set the hexadecimal value as the new value data for DisabledComponents.

Re-enable IPv6 on all tunnel interfaces

  1. Find the current value data of DisabledComponents.
  2. Change the data to binary data. It will be a 32-bit binary value.
  3. Find the first bit of the data, and then set it to 0. Do not change any other bits. For example, if the source data is 11111111111111111111111111111111, the new data should be 11111111111111111111111111111110.
  4. Change the data from binary to hexadecimal.
  5. Set the hexadecimal value as the new value data for DisabledComponents.

Re-enable all IPv6 interfaces except for the IPv6 loopback interface

  1. Find the current value data of DisabledComponents.
  2. Change the data to binary data. It will be a 32-bit binary value.
  3. Find the first bit of the data and the fifth bit of the data, and then set them both to 0. Do not touch any other bits. For example, if current data is 11111111111111111111111111111111, the new data should be 11111111111111111111111111101110.
  4. Change the data from binary to hexadecimal.
  5. Set the hexadecimal value as the new value data for DisabledComponents.

Notes

  • Administrators must create an .admx file to expose the settings in step 5 in a Group Policy setting.
  • You must restart your computer for these changes to take effect.
  • value other than 0x0 or 0x20 causes the Routing and Remote Access service to fail after this change takes effect.
About the 6to4 tunneling protocol

By default, the 6to4 tunneling protocol is enabled in Windows 7, Windows Vista, Windows Server 2008 R2, and Windows Server 2008 when an interface is assigned a public IPv4 address (that is, an IPv4 address that is not in the ranges 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16). 6to4 automatically assigns an IPv6 address to the 6to4 tunneling interface for each such address that is assigned, and 6to4 will dynamically register these IPv6 addresses on the assigned DNS server. If this behavior is not desired, we recommend that you disable IPv6 tunnel interfaces on the affected hosts.

Written by Armin Senger

September 12th, 2016 at 2:42 pm

Posted in IT

Exchange Start – Stop via Batch

leave a comment

Quellen:
http://exchange.sembee.info/2010/shutdown-script.asp
http://kevin-olbrich.de/alle-exchange-2013-dienste-neu-starten-bat/

Exchange 2010 Server Shutdown Script

On This Page

  • Introduction – Why Use a Script to Shutdown Exchange?
  • Shutdown Script
  • What Does the Script Do?
  • Shutdown or Restart the Server After Stopping Exchange
  • Starting Exchange with a Script

Other Versions of Exchange

This article is available for other versions of Exchange:

Exchange 2003
Exchange 2007

Introduction – Why Use a Script to Shutdown Exchange?

If you are running Exchange 2010 on a domain controller, then you will find that it takes the machine a long time to shutdown. This is because the domain functionality stops quicker than Exchange, therefore Exchange is unable to write to the domain controller and has to be be „killed“ by the operating system.

This continual „killing“ of the Exchange services, instead of allowing them to shutdown gracefully is not good for the database and is one of the prime reasons for recommending that Exchange is not installed on a domain controller.

A better option is to stop the services before you begin to shutdown the server. This will also cause the server to shutdown more quickly because it isn’t waiting for the services to timeout. This can significantly decrease the shutdown/reboot time of SBS Server.

Even if you have a dedicated Exchange server, if you are using a UPS, then you may also want to shutdown the Exchange services before the UPS shuts down the OS. In many cases the domain controller may shut down before Exchange, which will cause delays as Exchange needs to communicate with the the domain controller during the shutdown process.

While you can stop the services yourself using the services administrative tool, instead use a batch script with a shortcut on the desktop.
Due to the dependencies required for some services, you can shortcut the list by stopping one service with the /y command.

Shutdown Script

Below is a sample script. Simply copy and paste it in to a new notepad document and save it as „stop-exchange.cmd“.

net stop msexchangeadtopology /y
net stop msexchangefba /y
net stop msftesql-exchange /y
net stop msexchangeis /y
net stop msexchangesa /y
net stop iisadmin /y
net stop w3svc /y

What does the script do?

net stop msexchangeadtopology /y

Stops the „Microsoft Exchange Active Directory Topology Service“ which will stop the following services

Microsoft Exchange Transport Log Search
Microsoft Exchange Transport
Microsoft Exchange Throttling
Microsoft Exchange Service Host
Microsoft Exchange Search Indexer
Microsoft Exchange RPC Client Access
Microsoft Exchange Replication
Microsoft Exchange Protected Service Host
Microsoft Exchange Mail Submission
Microsoft Exchange Mailbox Replication
Microsoft Exchange Mailbox Assistants
Microsoft Exchange File Distribution
Microsoft Exchange EdgeSync
Microsoft Exchange Anti-spam Update
Microsoft Exchange Address Book

It will also stop POP3, IMAP4 and Unified Messaging if those are enabled.

net stop msexchangefba /y

stops the „Microsoft Exchange Forms-Based Authentication“ service which does not have any dependencies

net stop msftesql-exchange /y

stops the „Microsoft Search (Exchange)“ service which does not have any dependencies

net stop msexchangeis /y

stops the „Microsoft Exchange Information Store“ service which does not have any dependencies

net stop msexchangesa /y

stops the „Microsoft Exchange System Attendant“ service which does not have any dependencies

net stop iisadmin /y

stops the IIS admin service, which does not have any dependencies.

net stop w3svc /y

stops the „World Wide Web Publishing“ service, which may have any dependencies – on SBS this will also stop the Remote Desktop Gateway service, which could kick you out of the server if you are using the RWW to access the server.

Shutdown or Restart the Server After Stopping Exchange

If you are using these scripts to shutdown Exchange before a server is shutdown (for example by a UPS) or rebooted, then you may want to fully automate the process by scripting the shutdown/restart as well. This can be easily achieved by adding an extra line to the end of the script:

Restart the server

shutdown /r /t 00

Shutdown the server

shutdown /s /t 00

Starting Exchange with a Script

Finally, you might also want a script to start Exchange again. This can be useful if you apply an update which requires a restart of the Exchange services, but don’t need to restart the server. However starting the services is a little more complex as the less number of the services are dependant on other services. Therefore more services have to be started manually. Simply copy and paste it in to a new notepad document and save it as „start-exchange.cmd“.

Remember to add POP3 and IMAP services if you are using those.

net start „World Wide Web Publishing Service“
net start „Microsoft Exchange System Attendant“
net start „Microsoft Search (Exchange)“
net start „Microsoft Exchange Information Store“
net start „Microsoft Exchange Unified Messaging“
net start „Microsoft Exchange Transport Log Search“
net start „Microsoft Exchange Transport“
net start „Microsoft Exchange Throttling“
net start „Microsoft Exchange Service Host“
net start „Microsoft Exchange Search Indexer“
net start „Microsoft Exchange RPC Client Access“
net start „Microsoft Exchange Replication“
net start „Microsoft Exchange Protected Service Host“
net start „Microsoft Exchange Mailbox Replication“
net start „Microsoft Exchange Mailbox Assistants“
net start „Microsoft Exchange Mail Submission“
net start „Microsoft Exchange Forms-Based Authentication service“
net start „Microsoft Exchange File Distribution“
net start „Microsoft Exchange EdgeSync“
net start „Microsoft Exchange Anti-spam Update“
net start „Microsoft Exchange Address Book“

Bemerkung: dieses Skript funkioniert nur mit der englischen Version. Umgearbeitet nach universell siehe anschließend: (Download meines Skripts ganz am Ende des Beitrags)

net start W3SVC
net start MSExchangeADTopology
net start MSExchangeEdgeSync
net start wsbexchange
net start MSExchangeAB
net start MSExchangeAntispamUpdate
net start MSExchangeFDS
net start MSExchangeServiceHost
net start MSExchangeThrottling
net start MSExchangeIS
net start MSExchangeMailSubmission
net start MSExchangeMailboxAssistants
net start MSExchangeMailboxReplication
net start MSExchangeRepl
net start MSExchangeRPC
net start MSExchangeSearch
net start MSExchangeSA
net start MSExchangeTransport
net start MSExchangeTransportLogSearch
net start msftesql-Exchange
net start MSExchangeMonitoring


Alle Exchange 2013-Dienste neu starten (Batch / PowerShell / .bat / .ps1)

By | September 24, 2014
 

Wer auf die Schnelle mal alle Exchange-Dienste neustarten möchte, der kann einfach folgendes in eine normale PowerShell-Konsole kopieren:

$services = Get-Service | ? { $_.name -like „MSExchange*“ -and $_.Status -eq „Running“}
foreach ($service in $services) {Restart-Service $service.name -Force}

Unter Umständen kommt eine Meldung wegen Timeout auf ausgelasteten Servern, diese kann einfach ignoriert werden.

Der Original-Beitrag:

Quick Tip: Restarting all Microsoft Exchange services

There are times when you need to restart all Exchange related services so here are 2 small scripts that will help you achieve this without going over each service in the Services mmc.

Of course restarting the “Microsoft Exchange Active Directory Topology” will restart a most of them but these 2 will restart them all.

Restarting All Running Services

This will get all services starting with MSexchange that are running and restart them.

$services = Get-Service | ? { $_.name -like „MSExchange*“ -and $_.Status -eq „Running“}

foreach ($service in $services) {Restart-Service $service.name -Force}

Restarting All Running Services with startup type Automatic

Although the above script should be enough in most cases, it will not restart any Microsoft Exchange related service that is supposed be running but is not for any reason. Here is another version of the script that would take care of this issue, note that we are looking for all services starting with MSExchange with startup type Automatic and restarting them

$services = get-wmiobject win32_service | ? {$_.name -like „MSExchange*“ -and $_.StartMode -eq „Auto“}

foreach ($service in $services) {Restart-Service $service.name -Force}

That’s it for now

via Quick Tip: Restarting all Microsoft Exchange services | zero hour sleep.

Mein Skript für Exchange 2010, Deutsch zum Download als Textfile.
Vor dem Einsatz bitte durcharbeiten und nach .cmd umbenennen. Ich übernehme keinerlei Haftung für eventuelle Schäden:

stop start exchange

Read the rest of this entry »

Written by Armin Senger

August 19th, 2016 at 9:42 am

Posted in IT

Step by Step : Installing & Configuring WSUS in Server 2012 R2

leave a comment

Quelle: https://mizitechinfo.wordpress.com/2013/08/19/step-by-step-installing-configuring-wsus-in-server-2012-r2/

Hier nur der Teil über die Verteilung via Gruppenrichtlinien:

22 – Next, let’s add Computer Group to WSUS, this method is to make sure that any computer listed in the Computer Group will get the Updates from WSUS Server…

On the WSUS console, click Options and then double click Computers

26

23 – In the Computers dialog box, select Use Group Policy or registry settings on computers then click OK…

** I choose Use Group Policy because I wanted all my Clients getting windows updates by GPO…

27

24 – Next, click All Computers, and then, in the Actions pane, click Add Computer Group…

28

25 – In the Add Computer Group dialog box, in the Name text box, type Comsystem Laptop, and then click Add…

29

26 – Once you successfully add a New Computer Group to WSUS, now we need tocreate new GPO and configure it so that all our clients will be effected by this GPO to get the Windows Updates…

** On the Domain Server, open Group Policy Management,  right click Comsystem Laptop and then click Create a GPO in this domain, and Link it here…

30

27 – In the New GPO dialog box, type WSUS Comsystem Laptop ,and then click OK…

31

28 – Next, right-click WSUS Comsystem Laptop, and then click Edit…

32

29 – Next, in the Group Policy Management Editor, under Computer Configuration, double-click Policies, double-click Administrative Templates, double-click Windows Components, and then click Windows Update…

33

30 – Next, in the Setting pane, double-click Configure Automatic Updates, and then click the Enabled option, under Options, in the Configure automatic updating field, click and select 3 – Auto download and notify for install, and then click OK…

34

31 – In the Setting pane, double-click Specify intranet Microsoft update service location, and then click the Enabled option, then in the Set the intranet update service for detecting updates and the Set the intranet statistics server text boxes, type http://dc01.comsys.local:8530, and then click OK…

35

32 – In the Setting pane, double click Enable client-side targeting, in the Enable client-side targeting dialog box, click the Enabled option, in the Target group name for this computer text box, type Comsystem Laptop, and then click OK…

36

33 – Next, let’s log in to our client PC as domain administrator and verify that our client is receiving the GPO by typing gpresult /r in the command prompt, In the output of the command, confirm that, under COMPUTER SETTINGS, WSUS Comsystem Laptop is listed under Applied Group Policy Objects…

37

34 – Next, we need to Initialize the Windows Update by typing Wuauclt.exe/reportnow /detectnow in the cmd…

38

35 – Next, we need to Approve and at the same time deploy an Update to our client PC…

in WSUS console, under Updates, click Critical Updates, right click any updates you prefer for your client PC and then click Approve…

40

36 – In the Approve Updates window, in the Comsystem Laptop drop-down list box, select Approved for Install…

41

37 – Next, Click OK and then click Close…

42

43

38 – Now, to deploy the selected updates, on the Client PC, in the cmd type Wuauclt.exe /detectnow…

44

39 – before you confirm the client can receive the update from the WSUS Server,return to WSUS Server and the on the WSUS console, on the Download Status, verify that the necessary / selected updates is finish downloading…

45

40 – Next, Click Critical Updates, an the right panes, verify that few updates is stated 100%…

46

41 – Now return to Client PC and open Windows Update from Control Panel, you should notice update available for your client PC and you can proceed with installation…

47

48

We done for now, please wait for my next post..:-)

Written by Armin Senger

August 17th, 2016 at 9:25 am

Posted in IT

WSUS auf Server 2012R2

leave a comment

Quelle: http://www.wsus.de/wsus_auf_w2012

HowTo > WSUS auf Windows Server 2012 installieren
WSUS auf Windows Server 2012 installieren

wsus_auf_w2012.pdf

Written by Armin Senger

August 17th, 2016 at 9:05 am

Posted in IT

Eigene Öffentliche IP ganz schnell und ohne Schnickschnak

leave a comment

http://checkip.spdns.de/

Zur Verfügung gestellt von Securepoint Gmbh (https://www.securepoint.de/)

Written by Armin Senger

August 16th, 2016 at 4:30 pm

Posted in IT

Lizenz-Server 2012 für Terminaldienste (Session Hosts) installieren

leave a comment

Quelle: https://www.windowspro.de/wolfgang-sommergut/lizenz-server-fuer-terminaldienste-windows-2012-installieren

Remotedesktop-Lizenzserver installierenDie Terminaldienste (Remote Desktop Sessions) gehören zu den Features von Windows Server, die eigene CALs erfordern. Ihre Verwaltung erfolgt über einen eigenen Lizenz-Server, der Bestandteil der Remote Desktop Services ist. Unter Windows Server 2012 (R2) sind für seine Installation und Konfi­guration nicht mehr die gewohn­ten Tools zuständig, dafür spielt der Server Manager eine zentrale Rolle.

Nachdem Session Hosts zu Farmen (Sammlungen) zusammengefasst werden, in denen sich Sessions dynamisch auf die verschiedenen Server verteilen, wäre es nicht praktikabel, Lizenzschlüssel fest an einzelne Maschinen zu binden. Daher übernimmt der Lizenz-Server die Aufgabe, die vorhandenen CALs zentral zu verwalten und sie nach Bedarf an aktive Sitzungen zuzuweisen.

Lizenzierung pro User oder pro Gerät

Wie in vorgehenden Versionen von Windows Server stehen zwei Arten von CALs zu Auswahl: pro User oder pro Gerät. Die Entscheidung für eine der beiden Varianten hängt primär davon ab, welche für die vorherrschenden Nutzungsgewohnheiten günstiger ausfällt. Wenn viele Benutzer mit mehreren Endgeräten auf die Terminaldienste zugreifen, werden sich Per-User-Lizenzen empfehlen. Teilen sich jedoch häufig mehrere Mitarbeiter einen PC, dann spricht dies für die Lizenzierung pro Gerät.Wenn man Session Hosts, die unter verschiedenen Versionen von Windows Server laufen, über einen gemeinsamen Lizenz-Server verwalten möchte, dann gilt es zu bedenken, dass ältere Server keine neueren Lizenzen vergeben können. Auch wenn man also nur einzelne Session Hosts unter Windows Server 2012 (R2) betreibt, muss der Lizenz-Server ebenfalls unter dieser Version installiert werden. Dieser ist dann in der Lage, auch CALs für Server 2003 oder 2008 (R2) zu verwalten.

120 Tage ohne Lizenz-Server

Die Installation eines Lizenz-Servers ist dann nötig, wenn reguläre Benutzer auf Session Hosts ganze Desktops oder einzelne Anwendungen starten. Für den administrativen Zugriff von maximal zwei gleichzeitigen Benutzern braucht man ihn nicht.

Nach Ablauf der 120-Tage-Frist verweigern die RDS den Aufbau von Verbindungen, wenn noch kein Lizenz-Server eingerichtet wurde.

Außerdem erlaubt Microsoft die vorläufige Einrichtung von RD Session Hosts ohne Installation eines Lizenz-Servers, den man dann innerhalb der Gnadenfrist von 120 Tagen nachliefern muss. Ist diese verstrichen, dann starten die RDS nicht mehr. Das System gibt in diesem Fall die Meldung aus: „Der Remotedesktop-Lizenzierungsmodus ist nicht konfiguriert“.

Installation des Lizenz-Servers

Wie die Remote Desktop Services insgesamt, so wird auch der dazugehörige Lizenz-Server über den Server Manager installiert. Dazu wechselt man auf die auf die Rollenübersicht für die Remotedesktop-Dienste und klickt in derBereitstellungsübersicht auf das grüne Plus-Icon über Remotedesktop­lizenzierung. Wenn bereits ein Lizenz-Server installiert ist, dann kann man einen weiteren über das Kontextmenü der Remotedesktop­lizenzierung hinzufügen.

Die Installation eines Lizenz-Servers erfolgt im Server Manager (in der Bereitstellungsübersicht über das grüne Plus-Icon)

Im nachfolgenden Assistenten wählt man all jene Server aus, auf denen diese Rolle eingerichtet werden soll. Nach dem abschließenden Bestätigungsdialog startet die Installation.

Konfiguration überprüfen

Im nächsten Schritt muss der frisch eingerichtete Lizenz-Server bei Microsoft aktiviert werden. Dies erfolgt über den Remotedesktop­lizenzierungs-Manager, den man im Server Manager entweder aus dem Tools-Menü oder aus dem Kontextmenü des betreffenden Rechners in der Ansicht Server startet.

Der Remotedesktop­lizenzierungs-Manager und die RD-Lizenzierungsdiagnose lassen sich aus dem Server Manager starten.

Das Programm zeigt für einen neuen Lizenz-Server grundsätzlich den StatusNicht aktiviert an. Bevor man den Aktvierungsassistenten startet, sollte man jedoch die Gelegenheit nutzen, und die Konfiguration des Lizenz-Servers durch den RD-Lizenzierungsmanager prüfen lassen. Zu diesem Zweck klickt man auf den Link Überprüfen neben dem Server-Eintrag oder man führt im MenüAktionen den Befehl Konfiguration prüfen aus.

Der RD-Lizenzierungsmanager aktiviert den Lizenz-Server und nimmt ihn zudem in die AD-Gruppe Terminalserver-Lizenzserver auf.

In der Regel hat man den neuen Lizenz-Server noch nicht manuell in die AD-Gruppe Terminalserver-Lizenzserver aufgenommen, so dass er keine benutzergebundenen Lizenzen ausstellen kann. Die Prüfroutine des RD-Lizenzierungs-Managers moniert diesen Zustand und bietet an, den Server in die AD-Gruppe einzutragen.

Lizenz-Server aktivieren

Die eigentliche Aktivierung übernimmt dann ein Assistent, den man über den Befehl Server aktivieren aus dem Kontextmenü des Server-Eintrags starten kann. Im ersten Dialog nach der Begrüßung wählt man die Art der Verbindung aus, die mit Microsoft hergestellt werden soll. Wenn der Lizenz-Server einen Zugang zum Internet hat, dann empfiehlt das Tool, die voreingestellte OptionAutomatische Verbindung beizubehalten. Alternativ kann man den Lizenz-Server von einem anderen PC aus via Web-Browser aktivieren, und wenn auch das nicht passt, dann bleibt noch das Telefon.

Der Assistent zur Aktivierung des Lizenz-Servers empfiehlt den direkten Kontakt mit Microsofts Clearing House via Internet.

Bei der Aktivierung über das Internet folgt im nächsten Schritt ein Formular, in das man Vorname, Name, Firma und Land eingeben muss. Die zusätzlichen Daten zur Firma bzw. zum Mitarbeiter, darunter E-Mail und Adresse, die anschließend abgefragt werden, sind keine Pflichtangaben. Mit dem Abschicken des letzten Formulars erfolgt die Aktivierung des Lizenz-Servers.

Einheitlicher Lizenztyp erforderlich

Der Aktivierungsassistent bietet zum Abschluss an, den Wizard für die Eingabe von Lizenzen zu starten. Zuvor sollte man jedoch prüfen, ob durchgängig der gleiche Lizenztyp konfiguriert wurde. Der Lizenz-Server kann nur einen davon verwalten, entweder pro Benutzer oder pro Gerät. Die Lizenzen, die man dann im RD-Lizenzierungsmanager eingibt, müssen zur Konfiguration des Lizenz-Servers passen.

Über das Aufgabenmenü der Bereitstellungsübersicht lässt sich der Lizenztyp konfigurieren.

Die Art der RD-Lizenzierung legt man im Server Manager fest, indem man auf der Rollenseite für die RDS über dem Fenster Bereitstellungsübersicht das MenüAufgaben öffnet und dort den Befehl Bereitstellungseigenschaften bearbeitenausführt.

Im anschließenden Dialog kann man unter RD-Lizenzierung verifizieren, ob der gewünschte Lizenzierungstyp konfiguriert wurde und ob dieser mit den erworbenen Lizenzen übereinstimmt. Zusätzlich besteht hier noch die Möglichkeit, die Reihenfolge der eingetragenen Lizenz-Server zu verändern und so die Prioritäten zu verschieben.

Lizenzschlüssel installieren

Sind alle Voraussetzungen gegeben, dann kann man nun die Lizenzschlüssel imRD-Lizenzierungs-Manager installieren. Grundsätzlich sollten Clients danach in der Lage sein, eine Sitzung auf einem Session Host zu öffnen. Es empfiehlt sich aber, vorsichtshalber die RD-Lizenzierungsdiagnose auszuführen, um eventuellen Fehlkonfigurationen auf die Schliche zu kommen. Das Programm findet sich im Server Manager unter Tools => Terminal Services.

Mit Hilfe der RD-Lizenzierungsdiagnose kann man die Konfiguration des Lizenz-Servers überprüfen.

Zuordnung zu Session Hosts über GPOs

Wenn man mehrere Lizenz-Server eingerichtet hat und festlegen möchte, dass jeder von ihnen nur für bestimmte Session Hosts zuständig ist, dann kann man das wie gewohnt über Gruppenrichtlinien steuern. Die entsprechende Einstellung heißt Sicherheitsgruppe Lizenzserver und findet sich unterComputerkonfiguration => Richtlinien => Administrative Vorlagen => Windows-Komponenten => Remotedesktopdienste => Remotedesktop­lizenzierung.

— eigene Ergänzung aus https://technet.microsoft.com/de-de/library/cc742819(v=ws.11).aspx

Angeben eines Lizenzservers, der vom Remotedesktop-Sitzungshostserver verwendet wird

Betrifft: Windows Server 2008 R2 (funktioniert auch bei 2012R2)

Ein Server mit dem Host für Remotedesktopsitzungen muss einen Remotedesktop-Lizenzserver kontaktieren können, um Remotedesktopdienste-Clientzugriffslizenzen (Remote Desktop Services Client Access Licenses, RDS-CALs) für Benutzer oder Computer anzufordern, die eine Verbindung zum Server mit dem Host für Remotedesktopsitzungen herstellen.

Unter Windows Server 2008 R2 müssen Sie einen Lizenzserver angeben, der vom Server mit dem Host für Remotedesktopsitzungen verwendet wird. Die automatische Lizenzserverermittlung wird für einen Server mit dem Host für Remotedesktopsitzungen, auf dem Windows Server 2008 R2 ausgeführt wird, nicht mehr unterstützt.

Verwenden Sie das folgende Verfahren, um einen Lizenzserver anzugeben, der vom Server mit dem Host für Remotedesktopsitzungen verwendet wird.

Sie müssen mindestens Mitglied der lokalen Gruppe Administratoren oder einer entsprechenden Gruppe auf dem zu konfigurierenden Hostserver für Remotedesktopsitzungen sein, um dieses Verfahren ausführen zu können. Weitere Informationen zum Verwenden der passenden Konten und Gruppenmitgliedschaften finden Sie unter http://go.microsoft.com/fwlink/?LinkId=83477.

So geben Sie einen Lizenzserver an, der vom Remotedesktop-Sitzungshostserver verwendet wird

  1. Öffnen Sie auf dem Hostserver für Remotedesktopsitzungen die Konfiguration des Hosts für Remotedesktopsitzungen. Zum Öffnen der Konfiguration des Hosts für Remotedesktopsitzungen zeigen Sie im Startmenü auf Verwaltung, zeigen Sie auf Remotedesktopdienste, und klicken Sie dann auf Konfiguration des Remotedesktop-Sitzungshosts.
  2. Wenn das Dialogfeld Benutzerkontensteuerung eingeblendet wird, bestätigen Sie die angegebene Aktion und klicken dann auf Ja.
  3. Doppelklicken Sie unter Lizenzierung im Abschnitt Einstellungen bearbeiten auf Remotedesktop-Lizenzserver.
  4. Klicken Sie auf Hinzufügen.
  5. Wählen Sie im Dialogfeld Lizenzserver hinzufügen einen Lizenzserver aus der Liste bekannter Lizenzserver aus, und klicken Sie dann auf Hinzufügen. Falls der Lizenzserver, den Sie hinzufügen möchten, nicht aufgelistet ist, geben Sie im Feld Lizenzservername oder IP-Adresse den Namen oder die IP-Adresse des Lizenzservers ein, den Sie hinzufügen möchten, und klicken Sie dann auf Hinzufügen.

    Sie können für den Server mit dem Host für Remotedesktopsitzungen mehr als einen Lizenzserver angeben. Der Server mit dem Host für Remotedesktopsitzungen kontaktiert die Lizenzserver in der Reihenfolge, in der sie im Feld Angegebene Lizenzserver aufgeführt sind.

  6. Klicken Sie auf OK, um das Dialogfeld Lizenzserver hinzufügen zu schließen, und klicken Sie dann auf OK, um die Änderungen an den Lizenzierungseinstellungen zu speichern.

Sie können einen Lizenzserver für die Verwendung durch den Server mit dem Host für Remotedesktopsitzungen auch angeben, indem Sie die Gruppenrichtlinieneinstellung Angegebene Remotedesktop-Lizenzserver verwenden anwenden. Diese Gruppenrichtlinieneinstellung befindet sich unter Computerkonfiguration\Richtlinien\Administrative Vorlagen\Windows-Komponenten\Remotedesktopdienste\Remotedesktop-Sitzungshost\Lizenzierung und kann mithilfe des Editors für lokale Gruppenrichtlinien oder der Gruppenrichtlinien-Verwaltungskonsole (Group Policy Management Console, GPMC) konfiguriert werden. Beachten Sie, dass die Gruppenrichtlinieneinstellung Vorrang vor den in der Konfiguration des Hosts für Remotedesktopsitzungen konfigurierten Lizenzservern hat.

Weitere Informationen zu den Gruppenrichtlinieneinstellungen für Remotedesktopdienste finden Sie in der technischen Referenz für die Remotedesktopdienste unter http://go.microsoft.com/fwlink/?LinkId=138134 (möglicherweise in englischer Sprache).

Written by Armin Senger

August 16th, 2016 at 4:21 pm

Posted in IT