5ain7 ga11 . CH || i7-l3ak5. CH || g07r007.CH

Grundkonfig löschen:

Cat2950# delete flash:vlan.dat
Delete filename [vlan.dat]?

!— Press Enter.

Delete flash:vlan.dat? [confirm]y

Cat2950# reload
Proceed with reload? [confirm]y
4w5d: %SYS-5-RELOAD: Reload requested

VLAN DB löschen:

Cat2950# delete flash:vlan.dat
Delete filename [vlan.dat]?

!— Press Enter.

Delete flash:vlan.dat? [confirm]y

Cat2950# reload
Proceed with reload? [confirm]y
4w5d: %SYS-5-RELOAD: Reload requested

Wie repariert man eine defekte Exchange 2013 Search Index Database?

Zuerst einmal checken, ob die DB überhaupt Probleme hat.

 

<Get-MailboxDatabaseCopyStatus -Server SERVERNAME | FL Name,*Index*>

 

In diesem Fall steht:  Reseeding of the index is required

Na, dann machen wir das:

1.

• “Microsoft Exchange Search” und “Microsoft Exchange Search Host Controller” Dienst stoppen

• In den Ordner mit der Datenbank browsen. Darin findet man einen Ordner mit langen Strings.In diesem Ordner ist der Index gespeichert. Den Order umbenennen oder ganz löschen

• Danach die soeben gestoppten Dienste wieder starten.
• Nach ein paar Minuten sollte der Ordner wieder erscheinen.

<Get-MailboxDatabaseCopyStatus -Server optivevs01 | FL Name,*Index*>

..zeigt wiederum den aktuellen Status an: The Microsoft Exchange Search Service is crawling the database.

 

Wenn der Task durch ist, sollte folgender Status ersichtlich sein:

ContentIndexState            : Healthy

 

Beim Versand eines Emails via Exchange sieht ein Header normalerweise so aus, dass der interne Servernamen  im Header mitgegeben wird:

<Received: from mailout.in-the-cloud.ch (18.18.18.18) by vex10.itc.local
(192.168.10.19) with Microsoft SMTP Server id 14.2.347.0; Thu, 19 Feb 2015
14:19:50 +0100
Received: from mail.external.ch (mail.external.ch [81.81.81.81]) by
mailout.in-the-cloud.ch with ESMTP id tdORrIH8XGrJEANV for <me@in-the-cloud.ch>; Thu, 19
Feb 2015 14:22:05 +0100 (CET)
Received: from exchange.internal.local ([fe80::7598:91fd:6be7:2967]) by
exchange.internal.local ([fe80::7598:91fd:6be7:2967%11]) with mapi id
14.03.0224.002; Thu, 19 Feb 2015 14:22:04 +0100>

 

Wenn man will, dass diese Information verschleiert wird, dann kann man dies via Exchange Shell unterbinden.

<Get-SendConnector “Send-Connector Name” | Remove-ADPermission -AccessRight ExtendedRight -ExtendedRights ms-Exch-Send-Headers-Routing -user “NT AUTHORITY\Anonymous Logon”>

ACHTUNG, bei einem deutschsprachigem Exchange heisst es: <NT-AUTORITÄT\ANONYMOUS-ANMELDUNG>

Der Header sieht danach so aus:

<Received: from mailout.in-the-cloud.ch (18.18.18.18) by vex10.itc.local
(192.168.10.19) with Microsoft SMTP Server id 14.2.347.0; Thu, 19 Feb 2015
14:19:50 +0100
Received: from mail.external.ch (mail.external.ch [81.81.81.81]) by
mailout.in-the-cloud.ch with ESMTP id tdORrIH8XGrJEANV for <me@in-the-cloud.ch>; Thu, 19
Feb 2015 14:22:05 +0100 (CET)>

Microsoft hat am 12. September 2012 entschieden, den Thread Management Gateway einzustellen. Jetzt müssen Alternativen im Bereich des Reverse Proxies her. Einige Anbieter buhlen um die Vorherrschaft in diesem Segment. Firewall Hersteller via Sophos, Barracuda und Citrix mit dem Netscaler mischen in diesem Segment ebenfalls mit. Möchte man jedoch der Microsoft-Linie treu  bleiben, so bleibt einem nur die Möglichkeit, das Web Application Proxy Feature des Server 2012 R2 einzusetzen.

 

Hier darum ein Step-by-Step Guide auf der Cloud-Werkstatt…

 

Rahmenbedingungen / Ausgangslage

• 1 x Windows 2008 Domänencontroller (bestehend) => itc.local
• 1x Windows 2012 R2 Domänencontroller inkl ADFS Rolle (neu)
• 1x Exchange 2010 SP3 Rollup 8 (bestehend)
• 1x Windows Server 2012 R2 als Reverse Proxy (neu)
• Split Scope DNS Konfiguration mit SSL Wildcard (in-the-cloud.ch)
• AutoDiscover funktionsfähig
• sämtliche Server up to date (erspart viele Kindenkrankheiten)

 

Hostnames und IPs

• TESTVS01-MHU – 2008 R2 DC
• TESTVS02-MHU – 2008 R2 & Exchange 2010 SP3+
• TESTVS03-MHU – 2012 R2 DC & ADFS
• TESTVS04-MHU – 2012 R2 WAP (normalerweise in OPT Zone, war im Testlab aber nicht möglich)

 

 

DNS ScplitScope Records

• autodiscover.in-the-cloud.ch =>für AutoDiscover
• mail.in-the-cloud.ch =>  nur für SMTP Traffic (spielt hier keine Rolle)
• owa.in-the-cloud.ch => OWA, EAS, ECP
• sts.in-the-cloud.ch => Security Token Service, URL für ADFS

 

Installation

ADFS Server in Betrieb nehmen

1. via Powershell <Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)> hinzufügen

 

2. ADFS Verbundsdienste installieren

3. Konfiguration nach Bereitstellung aktivieren

4. mit AD DS Verbinden (ein Domänenadmin)

5. Diensteigenschaften angeben

 

• SSL Wildcard importieren
• Verbunddienstname: sts.in-the-cloud.ch
• Anzeigename: frei wählbar

6. Dienstkonto angeben

• Ich nehme hier den gleichen Serviceuser
• ein gruppenverwaltetet Dienstkonto ist IMHO nur mit DFL 2012 R2 möglich

7. Datenbank

• Fürs Testlab genügt die Windows DB
• Installation abschliessen

8. ADFS MMC starten und Konfiguration anpassen

• Verbunddiensteigenschaften bearbeiten…

• Settings überprüfen
  • Verbunddienstname: sts.in-the-cloud.ch
  • Bezeichner des Verbunddienstes: http://sts.in-the-cloud.ch/adfs/services/trust

 

“Ansprüche nicht unterstützender Vertauensstellungen….” hinzufügen

 

Anzeigename

• Name frei wählbar (ist für Exchange 2010 und Ex 2013 gleich)

Bezeichner eingeben

• https://owa.in-the-cloud.ch/adfs/services/trust

 

Mehrstufige Authentifizierung

• Jetzt keine Einstellungen für die Mehrstufige Authentifizierung konfigurieren…

Assistent zum Hinzufügen einer Ausstellungs-Authorisierungs-Anspruchsregel

 

• Benutzer den Zugriff auf Grundlage…gewähren…
• Allen Benutzer Zugriff gewähren

 

• Konfiguration abschliessen

 

ADFS Installation testen

https://sts.in-the-cloud.ch/adfs/ls/IdpInitiatedSignon.aspx$

eingeben. Hier sollte die ADFS Anmeldemaske erscheinen. Die Creds eingeben…

• Es sollte die Meldung kommen: “Sie sind angemeldet”

 

WAP Server in Betrieb nehmen

• Als erstes sollte das SSL Wildcard im lokalen Computer Konto importiert werden

 

Remotezugriffdienste mit Web Anwendungsproxy installieren

Nach der Grundinstallation den Assistent für den Webanwendungsproxy starten

 

Verbundserver

• Name des Verbunddienstes => sts.in-the-cloud.ch
• Creds angeben, dann auf weiter
• zuvor importiertes SSL Zertifikat wählen

Die Grundinstallation ist jetzt abgeschlossen. Anschliessend die WAP Konsole starten.

• Der WAP sollte jetzt voll funktionsfähig sein.

 

Remotzugriffsverwaltung starten und Exchange Dienst veröffentlichen

ECP und OWA (mit ADFS)

 

• Vorauthentisierung => ADFS wählen

 

vertrauende Seite

• selbst erstellte Exchange 2010/2013 ADFS Page wählen

Veröffentlichungseinstellungen

 

• Name => frei wählbar => Exchange 2013 OWA
• Zertifikat: importiertes Wildcard wählen
• Externe URL & URL Backend Server => https://owa.in-the-cloud.ch/owa/ (Wichtig / am Schluss nicht vergessen)
• Dienstprinzipialname des Backendservers = > http/owa.in-the-cloud.ch (Schreibweise beachten!!)
  • den SPN müssen wir noch registrieren…folgt

==> /ECP genau gleich veröffentlichen!!

• https://owa.in-the-cloud.ch/ecp/
• http/owa.in-the-cloud.ch

 

AutoDiscover, EAS, OAB und RPC via Passtrough

 

Die Passtrough Regeln werden nach folgendem Schema aktiviert:

 

 

Achtung : Exchange 2013 und Exchange 2010 unterscheiden sich hier :

 

Ex 2010 => https://owa.in-the-cloud.ch/Microsoft-Server-ActiveSync/

Ex2013 => https://owa.in-the-cloud.ch/Exchange-Server-ActiveSync/

 

Folgende Regeln sollten vorhanden sein:

 

Auszug aus: <get-Webapplicationproxyapplication | fl > output.txt>

Get-WebApplicationProxyapplication

 

Hier noch der Feinschliff im AD, damit der SPN auch funktioniert….

SPN Record im AD hinzufügen

Die erweiterten Attribute des Exchange AD Objektes öffnen und unter

“ServicePrincipalName”

“HTTP/owa.in-the-cloud.ch” hinzufügen

 

Dann aufs WAP Server Computerkonto wechseln

Delegierung auf WAP Server Objekt

• Anschliessend auf dem WAP Server AD Objekt die Delegierung auf den erstellten SPN aktivieren

Letzter Schritt….Exchange Server anpassen

auf Exchange 2010

auf dem CAS Server Authentifizierung für OWA und ECP anpassen auf “integrierte Windows Authentifzierung”

IIS reset und GO!!!

https://owa.in-the-cloud.ch/owa sollte jetzt die neue Anmeldemaske vorweisen..

nach dem Login erscheint dann das bekannt Fenster..

 

DONE!!

 

 

Troubleshooting EAS mit Android Clients

Ich hatte noch das Problem, dass Android Clients nicht synchen konnten. Das Problem liegt an der SNI (Server Name Indication” des IIS 8. Android Clients haben Probleme damit.

Folgendes schafft Abhilfe ( in Netz gefunden)

http://blog.kloud.com.au/tag/web-application-proxy/

</SNIP>

<SNIP/>

Finding the solution took a lot of searching. This TechNet blog Server Name Indication (SNI) with IIS 8 (Windows Server 2012) pointed me in the right direction when talking about how IIS 8 has a way to add a legacy SSL binding to support non-SNI compliant clients. Web Application Proxy however is not based on IIS. That blog mentioned using netsh to view the HTTP SSL bindings:

<netsh http show sslcert>

• Appid und Hash von owa.in-the-cloud.ch notieren..

 

The MSDN article How to: Configure a Port with an SSL Certificate showed how to add a new binding. The trick is to add an IP:port binding in addition to the Hostname:port which acts as a legacy non-SNI binding. As all of the WAP applications have the same certificate and Application ID, I reused those and created the new binding:

 

Lösung

<netsh http add sslcert ipport=0.0.0.0:443 certhash= 428b73e7d5e863b438fb547b133f3bda7a9daa1b appid={f955c070-e044-456c-ac00-e9e4275b3f04}>

 

 

 

 

 

 

 

Troubleshooting EAS mit Android Clients

Ich hatte noch das Problem, dass Android Clients nicht synchen konnten über WAP 2012 R2 mit ADFS. Das Problem liegt an der SNI (Server Name Indication” des IIS 8. Android Clients haben Probleme damit.

Folgendes schafft Abhilfe ( in Netz gefunden)

http://blog.kloud.com.au/tag/web-application-proxy/

</SNIP>

<SNIP/>

Finding the solution took a lot of searching. This TechNet blog Server Name Indication (SNI) with IIS 8 (Windows Server 2012) pointed me in the right direction when talking about how IIS 8 has a way to add a legacy SSL binding to support non-SNI compliant clients. Web Application Proxy however is not based on IIS. That blog mentioned using netsh to view the HTTP SSL bindings:

<netsh http show sslcert>

• Appid und Hash von owa.in-the-cloud.ch notieren..

 

The MSDN article How to: Configure a Port with an SSL Certificate showed how to add a new binding. The trick is to add an IP:port binding in addition to the Hostname:port which acts as a legacy non-SNI binding. As all of the WAP applications have the same certificate and Application ID, I reused those and created the new binding:

 

Lösung

<netsh http add sslcert ipport=0.0.0.0:443 certhash= 428b73e7d5e863b438fb547b133f3bda7a9daa1b appid={f955c070-e044-456c-ac00-e9e4275b3f04}>

 

 

 

 

 

 

 

Ich hatte die Angewohnheit bei Exchange Servern ohne vorgeschalteten Reverse Proxy (wie z.B. TMG) ein IIS Root redirect auf /owa zu konfigurieren.

Dabei ist mir aufgefallen, dass es bei vielen Installationen nicht mehr möglich war, das OAB via RPC herunter zu laden. Beim manuellen download bliebt die Status Bar im Outlook einfach hängen und zeigte kein Fortschritt an.

Das Problem dabei ist folgendes. Exchange legt beim Redirect die Datei

web.config im Verzeichnis

“C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\OAB” an und ändert deren Berechtigungen.

Folgendes schafft Abhilfe.

1. Im Outlook Client die Autokonfiguration starten und den OAB URL auslesen.

 

Via Browser auf https://myfqdn/OAB/generischeID verbinden. Erscheint die Meldung “interner Fehler 500″ so sind wir auf der richtigen Spur.

2. Anschliessend die Berechtigungen des Files “C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\OAB\web.config” checken.  Hier sollten die “Authentifizierten Benuter” Read und Write Zugriff haben. Falls die User nicht vorhanden sind, einfach hinzufügen.

3. Nachdem der User hinzugefügt wurde, einfach noch einen IIS reset durchführen. Danach sollte es wieder funktionieren.

 

 

Ich hatte folgendes Szenario. Ich wollte einen Exchange 2013 Server mit CU6 auf den neusten Stand bringen und dann auf CU7 updaten. Das Update schlug fehl…das Update GUI ist einfach verschwunden. Sämtliche Dienste waren deaktiviert. Nach einem Reboot konnte man die Dienste wieder manuell aktivieren, Outlook blieb jedoch offline. Fehlermeldungen gab es keine. Selbst ein Restore einer vorherigen Version vor dem Updaet brachte den Client nicht online.

Schuld daran ist der Exchange 2013 Maintenance Mode. Das Update setzte den Exchange in den Maintenace Status. Dieses Status wird im Active Directory und in der lokalen Registry publiziert.

 

 

Darum bringt folglich ein Restore das Outlook auch nicht wieder online.

Mit folgenden Befehl kann man den Status checken:

<Get-ServerComponentState –Identity SERVERNAME>

In meinem Fall waren hier sämtliche Komponenten “inaktiv”.

 

Mit folgenden Befehl kann man die Komponenten wieder reaktivieren:

<Set-ServerComponentState SERVER1 -Component ServerWideOffline -State Active -Requester Maintenance>

 

Dann braucht es noch folgenden Befehl um die Transport Queue wieder zu aktivieren:

<Set-ServerComponentState SERVER1 -Component HubTransport -State Active -Requester Maintenance>

Nach einem Reboot war Outlook war wieder online. Heureka…jetzt fehlt nur noch Part 2…warum das Update abgebrochen ist…dies wir ein weiterer Thread.

Der Maintenance Mode kann übrigends via:

<Set-ServerComponentState MBX1 -Component HubTransport -State Draining -Requester Maintenance>

aktiviert werden.