Archive

Archive for the ‘Exchange Server’ Category

OneDrive for Business | Neues von der Ignite in Chicago


OneDrive for Business, Microsoft

Lange Zeit gab es von Microsoft nichts neues zu hören. Außer Terminverschiebungen. Aber auf der Ignite in Chicago werden viele Neuigkeiten verkündet werden. Wer nicht vor Ort ist, also nicht zu den 23000 Teilnehmern zählt, der hat trotzdem die Möglichkeit, Live, oder aufgezeichnet, diese Neuheiten rund um Office 365, SharePoint, Exchange und Lync  zu erfahren.

Als erstes hat Microsoft einen neuen Blog zu OneDrive (for Business) ins Leben gerufen. den Customer Success Blog, also Erfahrungen von Kunden.

OneDrive for Business, Customer Success Blog

Natürlich in englischer Sprache.

Heute, am 5.5.2015 um 20:30 Uhr MEZ wird Microsoft durch Reuben Krippner endlich die lang erwarteten Neuheiten zu OneDrive for Business vorstellen. Unter dem Titel

A File’s Future with OneDrive for Business

erwartet die Zuhörerschaft nicht nur strategische Aussagen.

A File’sFuture with OneDrive for Business

Wer also Zeit hat…

Exchange Server 2010 SP3 Upgrade | Remove Exchange Folders

1. September 2014 Hinterlasse einen Kommentar

ExchangeSvr2010

Ja, man findet noch Exchange-Server, die noch nicht auf dem Service-Pack 3 sind. Während die Vorbereitung ohne Probleme durchlaufen wurde, gab es aber beim Punkt Remove Exchange Files Probleme und das Upgrade Programm war in einer Endlosschleife gefangen. Recherchen im Internet führten zu keinem Erfolg. Der Prozess musste im Taskmanager beendet werden.

Exchange Server 2010 SP3 Upgrade: Prozess Remove Exchange Files

Untersucht man das Logfile für die Installation findet sich wiederholende Einträge.


MSI (s) (0C:88) [15:25:57:987]: SOURCEMGMT: Now checking product {4934D1EA-BE46-48B1-8847-F1AF20E892C1}
MSI (s) (0C:88) [15:25:57:987]: SOURCEMGMT: Media is enabled for product.
MSI (s) (0C:88) [15:25:57:987]: SOURCEMGMT: Attempting to use LastUsedSource from source list.
MSI (s) (0C:88) [15:25:57:987]: SOURCEMGMT: Trying source \\Werbung.intra\data\Software\Microsoft Software\Exchange Server 2010 SP2\.
MSI (s) (0C:88) [15:27:22:262]: Note: 1: 1314 2: \\Werbung.intra\data\Software\Microsoft Software\Exchange Server 2010 SP2\
MSI (s) (0C:88) [15:27:22:262]: ConnectToSource: CreatePath/CreateFilePath failed with: -2147483648 1314 -2147483648
MSI (s) (0C:88) [15:27:22:262]: ConnectToSource (con’t): CreatePath/CreateFilePath failed with: -2147483648 -2147483648
MSI (s) (0C:88) [15:27:22:262]: SOURCEMGMT: net source ‘\\Werbung.intra\data\Software\Microsoft Software\Exchange Server 2010 SP2\’ is invalid.
MSI (s) (0C:88) [15:27:22:262]: Note: 1: 1706 2: -2147483647 3: exchangeserver.msi
MSI (s) (0C:88) [15:27:22:262]: SOURCEMGMT: Processing net source list.
MSI (s) (0C:88) [15:27:22:262]: Note: 1: 1706 2: -2147483647 3: exchangeserver.msi
MSI (s) (0C:88) [15:27:22:262]: SOURCEMGMT: Processing media source list.
MSI (s) (0C:88) [15:27:23:325]: SOURCEMGMT: Trying media source E:\.
MSI (s) (0C:88) [15:27:23:325]: Note: 1: 2203 2: E:\exchangeserver.msi 3: -2147287038
MSI (s) (0C:88) [15:27:23:325]: SOURCEMGMT: Source is invalid due to missing/inaccessible package.
MSI (s) (0C:88) [15:27:23:325]: Note: 1: 1706 2: -2147483647 3: exchangeserver.msi
MSI (s) (0C:88) [15:27:23:325]: SOURCEMGMT: Processing URL source list.
MSI (s) (0C:88) [15:27:23:325]: Note: 1: 1402 2: UNKNOWN\URL 3: 2
MSI (s) (0C:88) [15:27:23:325]: Note: 1: 1706 2: -2147483647 3: exchangeserver.msi
MSI (s) (0C:88) [15:27:23:325]: Note: 1: 1706 2: 3: exchangeserver.msi
MSI (s) (0C:88) [15:27:23:325]: SOURCEMGMT: Failed to resolve source
MSI (s) (0C:88) [15:27:23:325]: Failed to generate patch cache opcodes for: {4934D1EA-BE46-48B1-8847-F1AF20E892C1} product
MSI (s) (0C:88) [15:27:23:325]: Resolving source.
MSI (s) (0C:88) [15:27:23:325]: User policy value ‘SearchOrder’ is ‘nmu’
MSI (s) (0C:88) [15:27:23:325]: SOURCEMGMT: Media enabled only if package is safe.
MSI (s) (0C:88) [15:27:23:325]: SOURCEMGMT: Looking for sourcelist for product {4934D1EA-BE46-48B1-8847-F1AF20E892C1}


Die ursprüngliche SP2 Konfiguration von Exchange 2010 wurde von einem DFS Pfad gestartet und verweist auf einen DFS Link …\data\…  Diese DFS-Konfiguration wurde jedoch vom Administrator nach der Installation verändert zu …\daten\… Auf den ursprünglichen Pfad konnte das SP3 Upgrade-Programm nicht mehr zugreifen. Also musste temporär erst wieder ein DFS-Link …\data\ erzeugt werden, und danach lief das SP3 Upgrade-Programm ohne Probleme in kürzester Zeit durch.

Exchange Server 2010 SP3 Upgrade: Prozess Remove Exchange Files

Work Folders | Zertifikate ausrollen

14. Januar 2014 4 Kommentare

der 4. Teil der Implementierung der Work Folders geht es um den DNS Einträge und der Implementierung des Zertifikates, damit wir mit allen Geräten nicht nur innerhalb unseres Firmennetzwerkes Zugriff haben, sondern auch über das Internet von jeder beliebigen Stelle. Dabei gehe ich auch auf die Problematik eines bestehenden Exchange Servers und der mittlerweile von Microsoft abgekündigten Firewall Thread  Management Gateway (TMG 2010) einNetzwerk-Diagramm  für Work Folders

Wenn in einer Firma sowohl ein Sync-Server als auch ein Mail Server eingesetzt werden sollen, so ergibt sich auf Grund des verwendeten Protokolls (hppts= Port 443) ein Problem. Der Datenstrom muss an der Firewall getrennt werden. Die nachfolgende Beschreibung hier gilt für folgende Komponenten:

  • Proxy-Server: TMG 2010 auf Windows Server 2008 R2
  • Mail-Server: Exchange Server
  • Sync-Server: Windows Server 2012 R2
  • Es ist nur eine externe IP Adresse vorhanden
    Exchange Server verlangt beim Protokoll Outlook Web Access (OWA) SSL Verschlüsselung. Für den Zugriff muss öffentlich ein DNS Eintrag beim Provider eingerichtet werden. Der Sync- Server benötigt für die Work Folders ebenfalls einen öffentlichen DNS Eintrag
  • mail.contoso.com
  • workfolders.contoso.com
    ich habe im DNS Manger der Domäne auch noch einen Host-Eintrag workfolders erzeugt, dessen  IP auf den Sync-Server (Fileserver) zeigt:

DNS Eintrag für Workfolders

 

Und natürlich benötigen wir in SAN-Zertifikat (Multi-Domain Zertifikat), bei dem beide Einträge vorhanden sind. Dann kann auf der TMG mittels Bridging der SSL Datenstrom je nach Anforderung zum Mail-Server also auch zum Sync-Server weitergeleitet werden.

Dieses Zertifikat muss sowohl auf dem Mail-Server (Exchange) als auch auf dem Sync-Server und natürlich auf dem Proxy-Server (TMG) ausgerollt werden.

Exchange-Server

Es gibt genügend Beschreibungen im Internet, wie ein Zertifikat auf dem Exchange Server aus zu rollen ist, das ist auch abhängig von der Version des Exchange Servers. Hier ein paar Links:

 

Sync-Server (File Server)

hier ist eine Besonderheit zu beachten, weil eine SSL-Bindung ans den Web-Server IIS nicht über die Oberfläche funktionierten kann, weil der Web-Server (IIS) gar nicht installiert werden muss und auch gar nicht installiert wurde.

Besonderheiten bei den Rollen: Workfolders und Web Server

Es wurde aber (automatisch) mit den Work Folders die IIS Hostable Web Core installiert, die aber keine graphische Oberfläche hat.

PowerShell Abfrage: welche Komponenten sind installiert?

Das Powershell-Kommando hierfür: get-windowsfeature | where {$_.installed -eq $True}

Ist die Rolle Web Server (IIS) installiert, dann gibt es hier eine Beschreibung, wie Sie da Zertifikat an die Website binden können.

und hier der Weg, bei dem wir mit  Powershell und der CMD die Bindung vornehmen können.

1- Zuerst muss das Zertifikat importiert werden: (Powershell)

PS C:\>Import-PfxCertificate –FilePath <certFile.pfx> -CertStoreLocation cert:LocalMachine\My

natürlich können wir das ganze auch über das über das Zertifikats Snap-in der MMC erledigen. Dann sollte nach dem Import die Einstellung so aussehen:

MMC: installierte Zertifikate

 

2– Danach müssen den thumbprint des soeben importierten ermitteln:

PS C:\>Get-ChildItem –Path cert:\LocalMachine\My

Powersehll Abfrage: Thumbprint der installierte Zertifikate ermitteln

3- Das SSL Zertifikat muss nun mittel einer CMD-Konsole (!!!) gebunden werden.

netsh http add sslcert ipport=0.0.0.0:443 certhash=<Cert thumbprint> appid={CE66697B-3AA0-49D1-BDBD-A25C8359FD5D} certstorename=MY

Nachdem die Zeile in die CMD Konsole eingegeben (kopiert) wurde, wechseln wir wieder in die Powershell und kopieren den richtigen Thumprint des weiter oben installierten Zertifikates. und ersetzen in der Kommando-Zeile (CMD) <Cert thumbprint> durch die Zeichenfolge und dann erst wird das Kommando mit Return abgesetzt.

CMD: Zertifikat an WebServer binden 

Das  Kommando bindet das Zertifikat an das Root (alle Hostnamen dieses Servers) dieses Servers mit Port 443


Eine Besonderheit ist noch zu beachten, wenn sich ein Exchange Server in der Domäne befindet.Diese Beschreibung hier setzte aber auf bestimmte Gegebenheiten auf:
  • Es ist nur eine feste IP Adresse vorhanden
  • Benutzer nutzen auch OWA um auf Ihre Mail-Daten des Exchange Servers zuzugreifen
  • Als Firewall wird ein Thread Management Server 2010 (TMG) eingesetzt
    Das Problem ist, das sowohl OWA als auch Work Folders SSL (Port 443) benutzen und wir auf an der Firewall Bridging einsetzen müssen, um die SSL Daten entweder zum Exchange Server oder aber zum Sync-Server weiter zu leiten.
    1- Zertifikat importieren
    Das Zertifikat ist mit der MMC (Zertifikats Snap in)  auf der der TMG zu importieren. Danach sieht der persönliche Zertifikatsspeicher so ausSmiley mit geöffnetem Mund:

MMC: welche Zertifikate sind installiert

        Der rote Pfeil zeigt auf das “alte” OWA Zertifikat, der blaue auf das neue Zertifikat
          2- Web Listener erstellen bzw. umstellen
          Der existierende Web-Listener muss nun umgestellt werden:
      TMG Weblistener für SSL Ich habe nicht nur den Namen, sondern auch die Beschreibung geändert.
      TMG Weblistener : für welche IP er muss zwingend auf die externe Adressen “lauschen”
      TMG Weblistener : für SSL Traffic es geht um SSL Verkehr an Port 443
      TMG Weblistener : SAN Zertifikat zuweisen im Kartenreiter Certifikate müssen wir jetzt das neue Zertifikat zuweisen

      Hier noch einmal der Hinweis, dass auch der Exchange Server natürlich mit dem neuen Zertifikat versehen wurde!

      Der Weblistener lauscht ja auf Port 443 und weil in dieser Konfiguration nur eine externer IP Adresse vorhanden ist, gilt dieser Web Listener sowohl für OWA als auch für WEorkfolders und erst im Bridging wird unterschieden …

      Klick auf Select Certificate…

      TMG Weblistener : SAN Zertifikkat auswählen Das Bild zeigt jetzt das ich bereits auf das neue Zertifikat (Blau) geklickt habe.

      Anschließend auf “Select” klicken

      TMG Weblistener : Authentifizierung Im Kartenreiter Authentication habe ich “no Authentication” eingestellt (gehabt).

      Wir reichen ja nur durch und authentifizieren im Exchange Server bzw. im Sync Server

    Damit haben wir die Änderung des Web Listeners an der TMG abgeschlossen und klicken auf OK

    3- Regel OWA ändern
    TMG Regel für OWA: Weblistener auswählen Alle Einstellungen bleiben, nur der Weblistener muss richtig ausgewählt werden.
    4- Work Folder Regeln erstellen
    Der Einfachheit habe ich die “OWA” Regel in der TM kopiert , den Namen dann geändert und dann die Änderungen durchgeführt.
    TMG Regel für Work Folders: Name und Beschreibung Name und Beschreibung geändert
    TMG Regel für Work Folders: Erlaubnis  
    TMG Regel für Work Folders: für welche Quelle?  
    TMG Regel für Work Folders: Webserver eintragen Der Client kennt den externen oder internen DNS Namen (publish Sites) und als Computer habe wird der Namen des Sync-Servers eingetragen
    TMG Regel für Work Folders: Protokoll https eintragen Es geht um HTTPS (Port 443)
    TMG Regel für Work Folders: Weblistener auswählen hier wieder den Web-Listener eintragen.

    TMG Regel für Work Folders: DNS eintragen hier wird der öffentliche DNS Name eingetragen

    (beim der OWA Regel steht hier der öffentliche DNS Name für OWA)

    TMG Regel für Work Folders: Pfad umsetzen bei dem internen Pfad tragen wir ein:

    /sync/1.0/*

    Danke an meinen MVP Kollegen Christian Gröbner, der mich bei den Zertifikaten unterstützt hat und der diesen Eintrag aus dem Live-Logging ausgelesen hat.

    TMG Regel für Work Folders: keine Authentifizierung an der Firewall wird nicht authentifiziert, sondern nur weitergereicht…
    TMG Regel für Work Folders: WebServer und Protokoll 443 Traffic wird an den Web-Server weitergeleitet.
    TMG Regel für Work Folders: Benutzer auswählen und eintragen Ich habe hier “alle Benutzer” eingetragen…
    TMG Regel für Work Folders: Regel testen Ein Klick auf “Test Rue” zeigt, dass die Weiterleitung korrekt ist.
    Damit ist die Konfiguration an der TMG 2010 abgeschlossen. Im nächsten Blog Post werde ich dann den Abschluss dieser Work Folders Serie beschreiben, nämlich die Implementierung der Work Folders unter Windows 8.1, und zwar für ein Gerät in der Domäne als auch ein BYOD Gerät.
  1. Work Folders | Überblick
  2. Work Folders | Einrichtung Server und Konfiguration
  3. Work Folders | Quota und SMB
  4. Work Folders | Zertifikate ausrollen
  5. Work Folders | Client Konfiguration

        Exchange 2010 | SP2 Installation Update Rollup 6 | Fehler 80070643

        3. März 2013 2 Kommentare

        Microsoft Exchange Server 2010

        Im Oktober 2012 habe ich schon einmal einen Blogbeitrag geschrieben. Damals handelte es sich um das
        Rollup 4 für Exchange Server 2010 SP2 und dem Fehler 0×80070643.

        Dann im Dezember
        Rollup 5-v2 für Exchange Server 2010  SP2 und dem Fehler 0×80070643.

        Auch beim Update Rollup 6 für Exchange Server 2010 kommt es zum identischen Fehler.
        Den ursprünglichen Blogbeitrag habe ich geändert. Damit wird es in Zukunft nicht mehr zum Fehler kommen.

        Exchange 2010 | SP2 Installation Update Rollup 5-v2 | Fehler 80070643

        18. Dezember 2012 1 Kommentar

        Im Oktober habe ich schon einmal einen Blogbeitrag geschrieben. Damals handelte es sich um das

        Rollup 4 für Exchange Server 2010 SP2 und dem Fehler 0x80070643.

        Und jetzt passiert es wieder beim  Rollup 5-v2 für Exchange Server 2010 wieder. Es müssen die gleichen Schritte wie in obigem Blogbeitrag beschrieben getätigt werden. Wäre schön, wenn Microsoft das einmal hinbekommen würde .

        Exchange 2010 | SP2 Installation Update Rollup 4-v2 | Fehler 80070643

        13. Oktober 2012 11 Kommentare

        Exchange Server 2010

        seit ein paar Tagen hat Microsoft das Rollup 4 für Exchange 2010 SP2 zur Verfügung gestellt. Bei der Installation über Windows Server Update Service erhalte ich jedoch den Fehler 0x80070643 und das Rollup wird nicht installiert.

        Beim polnischen Kollegen wurde ich jetzt fündig:

        und die Anweisung funktionierte:

        1. Deinstallieren Sie Windows Server Windows Management Framework (WMF 3.0)

        2. Den Server manuell Rebooten.

        3. Installieren Sie das Update Rollup 4-v2 für Exchange Server 2010 SP2 KB2756485

        4. Den Server manuell Rebooten.

        5. Installieren Sie Windows Management Framework 3.0 ((Windows6.1-KB2506143-x64)

        Das WMF 3.0 baucht nicht mehr installiert werden

        6. ein letzter Reboot.

         

        Bei mir war es eine Beta-Version des Windows Management Framework 3.0 (dort stand noch das Word “Beta” drin) die die Installation verhinderte.

        [Update]
        das gleiche Problem taucht auf beim Rollup 5-v2 für Exchange Server 2010 (siehe Blog)

        [Update]

        das gleiche Problem taucht auf beim Rollup 6 für Exchange Server 2010 (siehe Blog)

        Folgen

        Erhalte jeden neuen Beitrag in deinen Posteingang.

        Schließe dich 134 Followern an

        %d Bloggern gefällt das: