Kategorien
ADFS CRM Server SharePoint Windows

ADFS 3.0 – Login Timeout verlängern

Ohne weitere Konfiguration ist der Timeout eines beliebigen Relying Party Trusts sehr knapp bemessen. Man muss sich gefühlt ständig erneut anmelden. Um das zu verhindern, kann man die Lifetime des Tokens per PowerShell erhöhen. Dazu geht man wie folgt vor:

Über das ADFS Management holen wir uns den Anzeigenamen (Display Name) des Relying Party Trusts.

Anschließend führen wir mit Hilfe der PowerShell-Konsole folgenden Befehl aus:

Get-ADFSRelyingPartyTrust -Name "[Anzeigename]" | Set-ADFSRelyingPartyTrust -TokenLifetime 720

Wobei wir mit dem Parameter „-TokenLifetime“ die Lifetime in Minuten setzen. In unserem Fall wären wir dann bei 12 Stunden.

Die Änderung wird sofort übernommen und gilt dann für alle neu ausgestellten Tokens.

Kategorien
Exchange Server Windows

Mail-aktivierter öffentlicher Ordner empfängt keine Mails von extern

Wird ein öffentlicher Ordner bzw. ein darin untergeordneter Ordner für das Empfangen von Mails aktiviert, kann es seit dem SP1 für Exchange 2013 sein, dass dies nicht mehr für den Empfang externer Mails genügt. Schuld daran ist die fehlende Berechtigung für Anonymous (das sind externe Sender in diesem Fall), in dem Ordner Elemente zu erstellen.

Führt man eine Sendungsverfolgung auf dem Exchange aus, wird uns folgender Fehler angezeigt:

RecipientStatus: {[{LRT=};{LED=550 5.7.1 RESOLVER.RST.AuthRequired; authentication required [Stage: CreateMessage]};{FQDN=};{IP=}]}

Aus diesem Grund muss für jeden für den Mailempfang aktivierten Ordner folgender Befehl noch über die Exchange-Shell ausgeführt werden:

Add-PublicFolderClientPermission –identity “\Ordner\Unterordner” –User Anonymous –AccessRights CreateItems

Damit ist das Problem schon behoben.

Kategorien
Exchange Server Windows

Script: „Senden als“-Berechtigung für alle Gruppenmitglieder eines Verteilers vergeben

Oft bietet es sich an, mit der Adresse einer Verteilergruppe eine Mail zu versenden. Beispielsweise um sicherzugehen, dass die Antwort des Empfängers auch wieder an den Verteiler geht. Nun pflegt man dies entweder von Anfang an mit ein, oder es fällt einem erst nach einer gewissen Zeit ein, so dass man nun gefühlte hundert Verteiler vor sich hat und das nachtragen darf. So geschehen bei mir.

Klarer Fall, es musste ein Script her:

Grant-SendAs-To-Group

Dieses Script durchläuft alle Verteiler und fügt jeweils den Verteiler gleich als SendAs-Berechtigten hinzu.

Kategorien
Hyper-V Server VMM Windows

Häufige VMM-Migrationsfehler und Lösungsansätze

Migrationen über den VMM (vorallem zwischen Clustern) können oft zu merkwürdigen Fehlern führen, die sich nicht immer logisch erklären lassen. Aus diesem Grund habe ich hier mal die mir widerfahrenen Probleme aufgelistet, gemeinsam mit Lösungsansätzen.

  • Es konnte keine verfügbare Verbindung mit dem ausgewählten VM-Netzwerk gefunden werden.
  • Es wurde keine Verbindung zu „[VM-Netzwerkname]“ mit ausreichenden Ressourcen gefunden.

Das ist ein seltsamer Bug. Wenn wir jedoch im VMM aus dem Menüband die PowerShell-Konsole öffnen, und darüber die Migration durchführen, so funktioniert es ohne Probleme – Vorausgesetzt natürlich, dass das Netzwerk tatsächlich an dem Zielhost anliegt. Hierzu gehen wir folgendermaßen vor:

$VMHost = Get-VMHost -ComputerName "[Ziel-Host]"
$VM = Get-VM -Name "[Zu migrierdende VM]"
$VMPath = $VMhost.Vmpaths[[Index des korrekten Speicherorts]]
Move-VM -VM $VM -VMHost $VMHost -Path $VMPath

Move-VM : Die VM „XXXXX“ kann aufgrund von Inkompatibilitätsproblemen nicht zu Host „XXXXXXX“ migriert
werden. The virtual machine ‚XXXXX‘ is using processor-specific features not supported on physical computer ‚XXXX‘.
To allow for migration of this virtual machine to physical computers with different processors, modify the virtual
machine settings to limit the processor features used by the virtual machine. (Virtual machine ID
xxxxxxxx-xxxxxx-xxxxxxx-xxxxxxxx) (Fehler-ID: 23008, Detaillierter Fehler: )

Beheben Sie das Inkompatibilitätsproblem, und wiederholen Sie den Migrationsvorgang.

Hier ist die VM auf einem Host erstellt worden, dessen Prozessorgeneration neuer ist, als der Zielhost der Migration. Behoben werden kann das Ganze, in dem man die VM herunterfährt, den Haken unter „Hardware“ -> „Prozessor“ -> „Migration zu einem virtuellen Maschinenhost mit abweichender Prozessorversion zulassen“ setzt und dann die Migration erneut durchführt. Nach der Migration sollte die Maschine erneut heruntergefahren werden, um diesen Haken wieder zu entfernen.

Move-VM : Der Hostvorgang auf dem Server „XXXXXXXXX“ kann von VMM aufgrund des folgenden Fehlers nicht
abgeschlossen werden: Virtual machine migration operation for ‚XXXXXXXX‘ failed at migration source ‚XXXXXXX‘. (Virtual
machine ID xxxxxxxx-xxxxxx-xxxxxx-xxxxxxxxx)
Virtual machine migration for ‚XXXXXXX‘ failed because configuration data root cannot be changed for a clustered
virtual machine. (Virtual machine ID xxxxx-xxxxxxxxx-xxxxxxxx-xxxxxx) (Fehler-ID: 12700, Detaillierter Fehler:
Unknown error (0x8005))

Beheben Sie das Problem auf dem Host, und wiederholen Sie dann den Vorgang.

Dieser Fehler kann behoben werden, indem man im Anschluss an den Fehler auf „Reparieren“ -> „Ignorieren“ klickt, und anschließend die Migration erneut triggert. Notfalls über PowerShell. 

Kategorien
Hyper-V Server Windows

VMM: Hinzufügen von HyperV-Hosts und -Cluster in vertrauenswürdigen Domänen

In unserer Infrastruktur haben wir uns dazu entschieden, jeden HyperV-Cluster in eine eigene Domain zu packen. Zusätzlich gibt es noch einen Management-Cluster, in dem unter anderem die Virtual Machine Manager-Server stehen. Die Domains sind untereinander über Forest-Trusts verbunden. Dieser Aufbau lässt zwar extrem hohe Sicherheitsstandards zu, bringt aber auch Probleme mit sich – Unter anderem beim Hinzufügen neuer HyperV-Cluster.

Vorgang:
Wie gewohnt öffnet man per Rechtsklick auf „All Hosts“ oder einer Untergruppe den Assistent zum Hinzufügen von Ressourcen. Da wir wie erwähnt einen Cluster bzw. Host aus einer vertrauenswürdigen Domain hinzufügen wollen, wählen wir den obersten Punkt („Windows-Server in einer vertrauenswürdigen Active Directory-Domäne“) aus. Anschließend wählen wir die zu verwendenden Anmeldeinformationen aus. Im darauffolgenden Fenster geben wir nun die Hostnamen der Server an, welche wir hinzufügen wollen. Da sich diese nicht in der selben Domain wie der VMM bewegen, geben wir die FQDNs an (hyperv-server01.cluster-domain01.dom). Klicken wir nun auf weiter, schlägt die Überprüfung nach einiger Wartezeit fehl, da er die Hostnamen (hyperv-server01) nicht auflösen kann.

Problem:
VMM ist hier ziemlich doof. Wir geben ihm die FQDNs, doch er will während dem Überprüfungsvorgang plötzlich die Hostnamen auch ohne Domain-Endung ansprechen. Nichts anderes sagt uns auch die Fehlermeldung.

Behebung:
Um das Problem zu umgehen, gibt es zwei Möglichkeiten. Bei einer von beiden von schön zu reden, wäre etwas vermessen:

  1. Hinzufügen der Hostnames aller Hosts in die DNS-Zone der Managementdomain: Die weniger unsaubere Lösung – Einfach in die DNS-Verwaltung der Management-Domain gehen um dort alle Hosts (und Cluster) als A-Records mit deren entsprechender IP einzutragen.
  2. Modifizieren der Hosts-Datei: Nicht schön aber selten – Wir öffnen das Notepad als Admin und öffnen die Hosts-Datei unter C:\Windows\System32\drivers\etc. Dort tragen wir gemäß dem auskommentierten Beispiel alle Host- (und Cluster-) Namen ein sowie deren IP (vorangestellt)

Anschließend kann im VMM auf „Retry“ gedrückt werden. Sollte noch immer was fehlen, zeigt er dies zum Glück in der Fehlermeldung an.

Kategorien
Allgemein Cisco Windows

NTP zwischen Cisco und Windows

Windows „spricht“ in der Regel nur NTP und Cisco SNTP, daher gibt es Probleme wenn man seine Windows Computer gegen z.B. seinen Cisco Router als Zeitquelle synchronisieren lässt.

Um das zu beheben gibt es viele Tools. Allerdings hat sich NetTime für uns bewehrt, da es einfach zu bedienen ist sowie schnell und unkompliziert zu installieren sowie konfigurieren ist.

1. Unter timesynctool.com herunterladen.

2. Installieren mit folgendem Feld aktiv:

install

3. Standardeinstellungen ist

gegen diese austauschen soll

4. Update now und immer gut in der Zeit liegen. fertig

Kategorien
Lync Server Windows

Lync/Skype4B: Nummern filtern in der Dialin-Page

Angenommen Sie haben in Ihrer Lync-/Skype for Business-Umgebung mehrere Dialin-Nummern, die aber zum Teil nicht von jedem gesehen werden sollen. Nun ist es aber so, dass auf der Dialin-Seite standardmäßig alle Einwahlnummern angezeigt werden. Um das zu unterbinden, kann man die Nummern in der PhoneList-Datei filtern. Diese finden wir wie folgt:

  • Melden Sie sich am Server an und öffnen Sie den IIS Manager
  • Navigieren Sie in der linken Baumstruktur auf folgenden Pfad:
    <Servername> → Sites → <Lync-/Skype-Version> External Web Site → dialin
  • Nun können Sie rechts in den Actions Explore auswählen, um im entsprechenden Dateiverzeichnis zu landen
  • Dort können Sie die Datei PhoneList.xslt finden. Diese können Sie erstmal nehmen und an den selben Ort nochmal kopieren mit dem Präfix „OLD_“. Somit haben Sie die originale Datei auf jeden Fall gesichert.
  • Nun öffnen Sie die PhoneList.xslt-Datei mit Hilfe des Notepads. (Zum anschließenden Speichern in den Pfad muss Notepad eventuell als Admin gestartet werden!)

Nun sollte sich in etwa ein solcher Eintrag öffnen:

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl">
 <xsl:output method="xml" indent="yes"/>
 <xsl:template match="/PhoneList">
  <xsl:for-each select="Region/PhoneNumber">
   <tr>
    <td class="region">
     <xsl:value-of select="@Name"/>
    </td>
    <td class="number">
     <xsl:value-of select="@Value"/>
    </td>
    <td class="language">
     <span class="defaultLanguage">
      <xsl:value-of select="@Primary"/>
     </span>
     <xsl:value-of select="@Secondary"/>
    </td>
   </tr>
  </xsl:for-each>
 </xsl:template>
</xsl:stylesheet>

Interessant für uns ist eigentlich nur eine Zeile, an welche wir den Filter anbringen werden:

<xsl:for-each select="Region/PhoneNumber">

Mit Filter sieht das Ganze dann folgendermaßen aus:

<xsl:for-each select="Region/PhoneNumber[<Variable>='<Wert>']">

Als Variable sind folgende Elemente verwendbar:

  • @Name – Das ist der Name der Dialin-Nummer, der in der Tabelle auf der Seite unter der Spaltenüberschrift „Region“ zu finden ist.
  • @Value – Das ist die tatsächliche Telefonnummer, auch in der Tabelle unter „Nummer“ zu finden.
  • @Primary – Die primäre Region, in der Tabelle dick abgebildet unter „Verfügbare Sprachen“
  • @Secondary – Die sekundären Regionen, in der Tabelle rechts von der primären Sprache unter „Verfügbare Sprachen“ zu finden.

Der einzutragende Wert ist dann eben das, was man sehen möchte. Statt dem ‚=‘ können auch noch die Operatoren ‚!=‘ (ist nicht gleich), ‚&lt‘ (kleiner als) und ‚&gt‘ (größer als) verwendet werden.

Ein fertiger Filter kann dann zum Beispiel so aussehen:

<xsl:for-each select="Region/PhoneNumber[@Name!='Geheime Einwahl']">

Nach dem Speichern ist der Filter sofort aktiv und bereits beim nächsten Aktualisieren der Seite ist die Änderung zu sehen.

Kategorien
Allgemein

Skype for Business 2015 Enterprise – In-Place Upgrade von Lync 2013

Vorwort

Es scheiden sich noch immer die Geister, ob ein In-Place-Upgrade wirklich das Gelbe vom Ei ist. Man muss hier tatsächlich in jedem Fall neu entscheiden. Für uns war dieses Upgrade sinnvoll da wir viel um die ehemaligen Lync-Server gebaut haben. Wenn Sie unser Portfolio kennen, wissen Sie vielleicht, dass unsere Kunden auch direkt bei uns die Telefonie dazubuchen können. Entweder über einen Partner von uns, oder mit einem SIP-Provider ihrer Wahl. Dies alles nachher umzustellen auf neue Server, mit neuen Adressen, wäre in unserem klein bemessenen Zeitfenster ein Ding der Unmöglichkeit gewesen.

Ich schreibe hier alles aus persönlichen Erfahrungen, werde deswegen keine Garantie übernehmen für etwaige Abweichungen zu Ihrer Infrastruktur. Dennoch würde ich mich freuen, wenn es den einen oder anderen weiterbringt und bin froh über jede Kritik. Nun viel Spaß beim Lesen und vielleicht schon bald viel Spaß mit Skype for Business 2015!

 

Vorbereitung

Folgende Voraussetzungen sind vor der Skype for Business-Installation zu erfüllen:

  • .net Framework 3.5 – Beziehbar, in dem man die zum Betriebssystem gehörige Windows-Disk einlegt, später mehr.
  • Lync Server 2013 Cumulative Update 5 (Feb. 2015) – Beziehbar über den Lync Update Installer
  • Service Pack 1 für die pro Server installierten SQL Express 2012-Instanzen – Beziehbar über diesen Link: SQLEXPR_x64_ENU.exe

Zusätzlich sind anscheinend je nach verwendetem Betriebssystem folgende Updates notwendig:

Anscheinend deshalb, da der Skype-Installer diese Updates wohl nachinstalliert, sofern nicht vorhanden. Wenn man hier sicher gehen will, kann man sie aber auf jeden Fall schon vorher installieren.

Ich habe für meinen Teil noch auf den FrontEnd-Servern, sowie auf den Edge-Servern ein SQL-Management Studio benötigt. Auf diesen Bug komme ich allerdings während der Installation noch zu sprechen und werde dieses dann auch entsprechend verlinken.

Installation der Voraussetzungen

Von nun an können alle Tätigkeiten zu Dienstunterbrechungen führen und sind deshalb grundsätzlich außerhalb der Geschäftszeiten zu erledigen.

.net Framework 3.5: Beim Windows Server 2008R2 ging es meines Wissens nach noch recht einfach: Über den „Add Feature“-Assistenten konnte hier noch ganz einfach .net Framework 3.5 nachgezogen werden. Anders bei 2012 und 2012R2: Auch wenn der Bezug der Dateien recht einfach ist, hat es uns Microsoft hier doch nicht ganz leicht gemacht. Wir legen also die für das Betriebssystem passende Windows-CD ins Laufwerk. Das ist wichtig! Eine 2012R2-CD bringt bei einem 2012-Server genau nichts. Anschließend öffnen wir wie beim 2008er Server diesen Rollen- und Featureassistent und wählen unter Features .net Framework 3.5 aus. Im darauffolgenden Fenster wird uns nun angeboten, alternative Quellen anzugeben. Hier verweisen wir auf den „sxs“-Ordner, wobei der Pfad wie folgt angegeben werden muss:

<Laufwerksbuchstabe>:\sources\sxs

Anschließend wird mit ein paar Klicks auf „Next“ und „OK“ das Feature installiert.

Lync Server Cumulative Update 5: Wenn Sie sich diesen Lync Update Installer besorgt haben, kopieren Sie diesen einfach auf jeden einzelnen Lync Server in Ihrer Site. Dann wirds eigentlich ziemlich einfach: Sie führen den Update Installer aus, sehen alle benötigten Updates und klicken nur noch auf „Install Updates„. Wir werden hier nicht speziell auf das CU5 gehen, sondern Lync einfach soweit aktualisieren, wie es die Updates hergeben. Sie werden dann auch sehen, dass auf den unterschiedlichen Servern unterschiedlich viele Updates anstehen. Das hängt damit zusammen, dass der Updater die installierten Rollen erkennt und wirklich nur das aktualisiert, was auch zu aktualisieren ist.

SQL Server Express Service Pack 2: Ja, Service Pack 2 ist kein Schreibfehler, diesen hab ich auch oben verlinkt. Grund hierfür ist, dass im SP2 der SP1 integriert ist. Und da wir eh gern aktuell sind, nehmen wir doch auch hier das aktuellste Produkt. Installieren werden wir das Ganze mit einem simplen Mehrzeiler. Dieser sorgt dafür, dass zum einen die Lync-Dienste zu diesem Zeitpunkt nicht mehr in die Datenbank schreiben, und zum anderen wird wirklich nur das versteckte Service Pack Update ausgeführt anstatt dem großen Installer. In dem Beispiel gehen wir davon aus, dass wir die „SQLEXPR_x64_ENU.exe“ unter „C:\Temp\“ abgelegt haben:

PS C:\Users\demo-user> Stop-CsWindowsService
PS C:\Users\demo-user> cd..
PS C:\Users> cd..
PS C:\> cd .\Temp
PS C:\Temp> .\SQLEXPR_x64_ENU.exe /ACTION=Patch /allinstances /IAcceptSQLServerLicenseTerms

Die daraufhin folgende Setup-Routine sollte selbstverständlich sein, da werde ich nicht näher darauf eingehen.

Installation des (temporären) Management-Servers

Jetzt geht’s los. Wir benötigen zum Start einen Server ohne irgendwelche Lync-Dienste und dergleichen installiert. Da dieser Server wirklich erstmal gar nichts können muss, haben wir hier kurzerhand eine neue VM aufgesetzt, kurz ein 2012R2-OS installiert, Netzwerktechnisch neben die Lync-Server gestellt und in deren Domain aufgenommen. Sobald dies erledigt ist, kann man die Skype for Business-ISO einhängen und auf dem Laufwerk dann zu Setup -> AMD64 -> setup.exe navigieren. Wenn wir diese Ausführen, werden erstmal die Kernkomponenten installiert.

Danach sehen wir ein neu eingefärbtes, aber wohl bekanntes Fenster, den Deployment Wizard. Hier klicken wir auf Install Administrative Tools. Nun werden weitere Komponenten installiert, die wir unter anderen Einfärbungen so schon kennen. Die für uns wichtigste ist hierbei der Skype for Business 2015 Topology Builder.

Upgrade des FrontEnd-Pools

Wir öffnen nun also das erste Mal den Skype for Business 2015 Topology Builder. Die einzige Änderung, die wir feststellen können, ist ein weiterer „Ordner“ mit dem Namen Skype for Business Server 2015. Da dieser ernüchternd leer ist, werden wir nun dafür sorgen, dass er voller wird. Hierzu werden wir auf den Lync 2013 FronEnd-Pool rechtsklicken und Upgrade to Skype for Business Server 2015… wählen. Den Hinweis können wir mit OK bestätigen. Nun ist der FrontEnd-Pool verschoben, aber nur im Topology-Builder. Damit die Änderung wirksam wird, müssen wir nun die Topology publishen. Im Publishing-Wizard werden wir dann auch darauf hingewiesen, dass die Datenbank bearbeitet wird. Das finden wir gut, klicken auf Next und die Topologie ist publiziert.

Nun schalten wir uns auf den ersten FrontEnd-Server. Da wir alle Voraussetzungen schon installiert hatten, beenden wir nur schnell über den Befehl

Stop-CsWindowsService

alle Lync-Dienste und können dann direkt auch hier die Skype-ISO einlegen und wieder über <Laufwerksbuchstabe>:\Amd64\Setup.exe den Installer ausführen. Nachdem wir das Lizenzabkommen bestätigt haben, startet direkt das Setup. Wenn wir Glück haben, ist er in etwa 30min. durch, da wir aber nie Glück haben, schreibe ich hier mal die uns bekannten und möglicherweise auftretenden Probleme auf. Sollte ein solches Problem auftreten und die Problemlösung wäre gezwungenermaßen mit einem Neustart verbunden, so ist das nicht schlimm. Das Setup merkt sich ganz genau, wo wir stehen geblieben sind. Hier die uns bekannten Fehler:

  • Schritt 1 – Verifying upgrade readiness: Das hat recht wenig mit Glück zu tun. Wer diesen Fehler bekommt, hat die Vorbereitung zumindest teilweise übersprungen. Aber nicht schlimm, hier sagt uns der Installer ganz genau, was ihm noch fehlt.
  • Schritt 12 – Installing roles: Hier bekamen wir folgenden Fehler: „An error occured while applying SQL script for the feature RtcDatabaseStore. For details, see the log file […]“. In dem Logfile stand dann am Ende „The server principal ‘<FE-Server>\RTC Component Local Group’ already exists“. Sollte der Fehler bei Ihnen auch auftreten, dann müssen Sie sich nun das oben erwähnte SQL Management Studio beziehen. Dieses installieren Sie dann lokal auf dem FrontEnd-Server, um damit auf die RTCLOCAL-Datenbank zuzugreifen. Dort angekommen, erweitern Sie unter Security die Logins, worunter auch unten stehende Einträge zu sehen sein sollten. Diese müssen gelöscht werden. Anschließend kann im Setup der Retry-Knopf gedrückt werden.
    • <FE-Server>\RTC Components Local Group
    • <FE-Server>\RTC Local Administrators
    • <FE-Server>\RTC Local Config Replicator
    • <FE-Server>\RTC Local Read-only Administrator
    • <FE-Server>\RTC Local Group
  • Sollten noch weitere Probleme auftauchen – lassen Sie uns teilhaben! Die Kommentarfunktion darf hierfür gerne hergenommen werden.

Sobald der Installationsassistent komplett durchgelaufen ist, haben wir den ersten Server komplett upgedatet. Dieses Verfahren ist nun für sämtliche FrontEnd-Server zu wiederholen.

Ist dies erledigt, so dürfen wir an dieser Stelle einen tollen neuen Befehl ausführen:

Start-CsPool <Name des Pools>

Dieser Befehl ist in der Lage, den gesamten FrontEnd-Pool zu starten. Während die Dienste hochgefahren werden, können Sie einiges an Informationen in der Konsole sehen. Wenn alles geklappt hat, sehen wir als abschließende Meldung folgende Ausgabe:

The final state of servers:
Server                Status
-------               -------
<Servernamen>         Running

Hiermit läuft der ganze FrontEnd-Pool bereits auf Skype for Business 2015. Die anderen Server werden wir dann in den kommenden Schritten nachziehen.

Upgrade des Edge-Pools

— ACHTUNG, BUG! — (Stand: 21. Juli 2015)

Das Setup läuft fast gleich ab, wie auf den FrontEnd-Servern. Fast. Denn hier kann man sich ein richtiges Ei legen durch einen kleinen aber feinen Bug (Tritt nur bei Nichtverwendung von XMPP-Federation in Erscheinung). Dieser äußert sich wie folgt (Die nun kommenden Schritte sind theoretisch, nicht nachmachen!):

  • Wir klicken im Topology Builder auf den Edge Pool und veranlassen das Upgrade
  • Wir legen wieder auf dem ersten Edge-Server die Disk ein und starten das Setup
  • Das Setup wird bei Schritt 12 – das ist der Schritt mit dem SQL Management Studio – eventuell erstmal wieder wegen der RTC-Datenbank meckern, sobald dies aber gefixt ist, aus einem ganz anderen Grund: Es wurde kein gültiges Zertifikat für den XMPP-Dienst gefunden. Diese Aussage ist soweit schon korrekt, schließlich verwenden wir keine XMPP-Federation. Dumm nur, dass es ohne Zertifikat gar nicht weiter geht. 
  • Nun müssen wir dafür Sorge tragen, dass ein sich mitten in einem Update befindlicher Server irgendwie noch die XMPP-Rolle annimmt, diese installiert, so dass wir dann nach dem Anwenden eines Zertifikats auf diesen Dienst das Setup fortführen können. Sämtliche Versuche, die Replikation anzustoßen, werden fehlschlagen.
  • Kurz gesagt, es ist möglich und ich werde auch hier kurz aufschreiben, wie man es zu erledigen hat. Wir werden aber den Bug in der ausführlichen Anleitung gleich gezielt umschiffen. Wenn man sich also in den Schlingen des Bugs verfangen hat, geht man folgendermaßen vor:
    • Erneut den Topology-Builder auf dem FrontEnd-Server oder der neuen MGMT-Maschine aufmachen und erst über die Properties des Edgepools generell die XMPP-Federation aktivieren
    • Dann über die Properties der Site nochmal die XMPP-Federation starten.
    • Anschließend die Topology publishen
    • Über den Befehl Export-CsConfiguration -FileName „<Pfad>\export.zip“ die Topologie exportieren.
    • Auf dem Edge-Server nun den Deployment Wizard öffnen. Er wird uns sagen, dass momentan ein Setup läuft und wir es nur noch mit dem Deployment Wizard beenden können. Das passt aber, somit bestätigen wir das.
    • Nun klicken wir auf Install or Update […] und führen Step 1 erneut aus. Er wird dann die exportierte Zip-Datei öffnen wollen. Nachdem wir ihm diese gegeben haben, arbeitet er kurz im Hintergrund ein paar Dinge ab.
    • Danach führen wir Step 2 aus, der uns den XMPP-Dienst installieren wird und anschließend den bereits bekannten Fehler auswirft.
    • Nun können wir über Step 3 dem XMPP-Dienst ein Zertifikat hinzufügen
    • Abschließend können wir mit Step 2 die Installation abschließen. Nochmal gut gegangen.

— BUG ENDE —

Um den Bug gleich zu umschiffen, werden wir folgendermaßen vorangehen:

Wir öffnen auf dem FrontEnd-Server oder auf dem (temporären) Management-Server den Topology Builder. Im ersten Schritt werden wir nun nur die XMPP-Dienste aktivieren. Dazu öffnen wir die Properties des Edge-Pools und setzen den Haken bei XMPP Federation. Anschließend müssen wir noch auf der Site in den Properties die Einstellung ebenfalls setzen. Auch hier heißt unser Haken Enable XMPP Federation. Im Anschluss daran werden wir die Topologie publishen. Mittels dem Befehls

Get-CsManagementStoreReplicationStatus

kann geprüft werden, ob die Änderungen schon auf dem Edge-Server angekommen sind. Sobald unter UpToDate der Wert „true“ zu finden ist, sind die Änderungen durch. Nun können wir auf dem Edge-Server den Deployment Wizard öffnen, um über den Knopf Install or Upgrade Lync 2013 Server System auf Setup or Remove Lync 2013 Server Components klicken zu können. Nun rattert das Setup schnell durch und wird XMPP aktivieren. Dies können wir dann über Request, Install or Assign Certificates mit einem Zertifikat versehen. Idealerweise natürlich einfach mit dem bestehenden.

Nachdem das erledigt ist, beginnt die alte Routine, bekannt von den FrontEnd-Servern: Über den Skype Topology Builder rechtsklicken wir auf den Edge-Pool und wählen Upgrade to Skype for Business Server 2015… . Anschließend publishen wir die Topologie.

Nun gehen wir auf den Edge-Server und führen folgenden Befehl aus:

Stop-CsWindowsService

Anschließend legen wir dort das Skype for Business-Image ein. Auf dem Laufwerk angelangt starten wir wieder unter Setup\AMD64 die Setup.exe, bestätigen das Lizenzabkommen und der gewohnte Installer startet durch. Auch hier wieder die bekannten Probleme kurz zusammengefasst:

  • Schritt 1 – Verifying upgrade readiness: Wer diesen Fehler bekommt, hat die Vorbereitung zumindest teilweise übersprungen. Hier sagt uns der Installer aber nochmal ganz genau, was ihm noch fehlt.
  • Schritt 12 – Installing roles: Hier kann wieder folgender Fehler auftreten: „An error occured while applying SQL script for the feature RtcDatabaseStore. For details, see the log file […]“. In dem Logfile stand dann am Ende „The server principal ‘<Edge-Server>\RTC Component Local Group’ already exists“. Sollte der Fehler bei Ihnen auch auftreten, dann müssen Sie sich nun das oben erwähnte SQL Management Studio beziehen. Dieses installieren Sie dann lokal auf dem Edge-Server, um damit auf die RTCLOCAL-Datenbank zuzugreifen. Dort angekommen, erweitern Sie unter Security die Logins, worunter auch unten stehende Einträge zu sehen sein sollten. Diese müssen gelöscht werden. Anschließend kann im Setup der Retry-Knopf gedrückt werden.
    • <Edge-Server>\RTC Components Local Group
    • <Edge-Server>\RTC Local Administrators
    • <Edge-Server>\RTC Local Config Replicator
    • <Edge-Server>\RTC Local Read-only Administrator
    • <Edge-Server>\RTC Local Group
  • Sollten noch weitere Probleme auftauchen – lassen Sie uns teilhaben! Die Kommentarfunktion darf hierfür gerne hergenommen werden.

Diese Schritte sind auch wieder für jeden einzelnen Edge-Server zu wiederholen. Anschließend kann man über den Befehl

Start-CsWindowsService

auf jedem Server die Edge-Dienste starten. Somit sind auch diese abgeschlossen.

Upgrade des Mediation-Pools 

Kein Bug bekannt, keine Sonderregeln zu beachten, deswegen viel Copy-Paste:

Über den Skype Topology Builder rechtsklicken wir auf den Mediation-Pool und wählen Upgrade to Skype for Business Server 2015… . Anschließend publishen wir die Topologie.

Nun gehen wir auf den ersten Mediation-Server und führen folgenden Befehl aus:

Stop-CsWindowsService

Danach legen wir dort das Skype for Business-Image ein. Auf dem Laufwerk angelangt starten wir wieder unter Setup\AMD64 die Setup.exe, bestätigen das Lizenzabkommen und der gewohnte Installer startet durch. Auch hier wieder die bekannten Probleme kurz zusammengefasst:

  • Schritt 1 – Verifying upgrade readiness: Wer diesen Fehler bekommt, hat die Vorbereitung zumindest teilweise übersprungen. Hier sagt uns der Installer aber nochmal ganz genau, was ihm noch fehlt.
  • Sollten noch weitere Probleme auftauchen – lassen Sie uns teilhaben! Die Kommentarfunktion darf hierfür gerne hergenommen werden.

Diese Schritte sind auch wieder für jeden einzelnen Mediation-Server zu wiederholen. Anschließend kann man über den Befehl

Start-CsWindowsService

auf jedem Server die Mediaton-Dienste starten. Somit sind auch diese abgeschlossen.

Upgrade des Persistent Chat-Pools

Auch hier soweit kein Bug bekannt, nichts besonderes, erneut straight forward:

Über den Skype Topology Builder rechtsklicken wir auf den Persistent Chat-Pool und wählen Upgrade to Skype for Business Server 2015… . Anschließend publishen wir die Topologie.

Nun gehen wir auf den ersten Persistent Chat-Server und führen folgenden Befehl aus:

Stop-CsWindowsService

Danach legen wir dort das Skype for Business-Image ein. Auf dem Laufwerk angelangt starten wir wieder unter Setup\AMD64 die Setup.exe, bestätigen das Lizenzabkommen und der gewohnte Installer startet durch. Auch hier wieder die bekannten Probleme kurz zusammengefasst:

  • Schritt 1 – Verifying upgrade readiness: Wer diesen Fehler bekommt, hat die Vorbereitung zumindest teilweise übersprungen. Hier sagt uns der Installer aber nochmal ganz genau, was ihm noch fehlt.
  • Sollten noch weitere Probleme auftauchen – lassen Sie uns teilhaben! Die Kommentarfunktion darf hierfür gerne hergenommen werden.

Diese Schritte sind auch wieder für jeden einzelnen Persistent Chat-Server zu wiederholen. Abschließend kann man über den Befehl

Start-CsWindowsService

auf jedem Server die Mediaton-Dienste starten. Somit sind auch diese abgeschlossen.

Upgrade der Trusted Application Servers

Dies ist in einem In-Place-Upgrade denkbar einfach, da sich für die Server weder Ziel-FQDN noch sonst was ändert. Wir nehmen also unseren Topology Builder und klicken einfach per Rechtsklick jeden Eintrag einmal an und wählen den gewohnten Eintrag Upgrade to Skype for Business Server 2015… . Anschließend noch einmal publishen und wir sind mit unserem In-Place-Upgrade so weit durch.

Kategorien
Lync Server SQL Windows

Lync 2013 Enterprise – Umzug der Datenbanken auf einen neuen SQL-Server

In diesem Beitrag werden wir den Umzug aller Datenbanken betrachten, die in einer Lync Enterprise-Umgebung auftreten. Diese nennen sich wie folgt:

— BackEnd —
CPSDYN – Dynamische Informationsdatenbank für das Call Parking-Feature
RGSCONFIG – In ihr liegt die Konfiguration aller Response Groups
RGSDYN – Dynamische Informationsdatenbank für Runtime-Daten der Response Groups
RTCAB – In ihr liegen die Daten aller Adressbücher
RTCSHARED – Beinhaltet Konferenzdaten
RTCXDS – Ist für das Backup der Benutzerdaten zuständig

— Persistent Chat —
MGC – Speichert alle Persistent Chats und deren Protokolle

— Monitoring —
LCSCDR – Speichert Details aller Calls
LCSLOG – Beinhaltet Daten aller Instant Messages und Konferenzen
QOEMETRICS – Beinhaltet QoE-Daten um die Qualität der Dienste für User sicherzustellen

Vorbereitung

Als erstes, und dies ist äußerst wichtig, muss dafür gesorgt werden, dass die Central Management Datenbank während des Umzugs nicht auf einem der FrontEnd-Server läuft. Da dessen Dienste während des Umzugs nur eingeschränkt bzw. gar nicht verfügbar sind, wir allerdings über die Topologie nachher auf den neuen SQL-Server verweisen, könnte dies fatale Folgen haben. Ist dies also der Fall, muss ein temporärer Lync-Server aufgesetzt werden, der keine Rolle besitzt, sondern nur den Central Managent Store besitzt. Erst wenn dies sichergestellt wurde und die CMS Replikation auf „healthy“ steht, können wir fortfahren. Überprüfen können wir dies mit folgendem Befehl:

Get-CsManagementStoreReplicationStatus

Um sicherzustellen, dass keine Zugriffe mehr auf die Datenbank entstehen, müssen die Lyncdienste im gesamten FrontEnd- und auch im Persistent Chat-Pool beendet werden. Das heißt: Diese Arbeit ist auf jeden Fall außerhalb der Geschäftszeiten zu erledigen und kann sich ordentlich in die Länge ziehen.

Wie erwähnt gehen wir also als erstes auf sämtliche Server, die sich in den oben genannten Pools befinden und führen folgenden Befehl aus:

Stop-CsWindowsService

Dieser Befehlt stoppt sämtliche Lync-Dienste auf dem jeweiligen Server. Bitte notieren Sie sich die Reihenfolge der Abschaltung der Server in einer Handnotiz, um später zum Abschluss die Server wieder in entgegengesetzter Richtung zu starten.

Export

Als erstes müssen wir die Datenbanken für den Umzug vorbereiten. Dazu verwenden wir folgendes Script:

ALTER DATABASE cpsdyn SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE cpsdyn SET SINGLE_USER
ALTER DATABASE cpsdyn SET ONLINE
ALTER DATABASE rgsconfig SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE rgsconfig SET SINGLE_USER
ALTER DATABASE rgsconfig SET ONLINE
ALTER DATABASE rgsdyn SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE rgsdyn SET SINGLE_USER
ALTER DATABASE rgsdyn SET ONLINE
ALTER DATABASE rtcab SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE rtcab SET SINGLE_USER
ALTER DATABASE rtcab SET ONLINE
ALTER DATABASE rtcshared SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE rtcshared SET SINGLE_USER
ALTER DATABASE rtcshared SET ONLINE
ALTER DATABASE rtcxds SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE rtcxds SET SINGLE_USER
ALTER DATABASE rtcxds SET ONLINE
ALTER DATABASE mgc SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE mgc SET SINGLE_USER
ALTER DATABASE mgc SET ONLINE
ALTER DATABASE LcsCDR SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE LcsCDR SET SINGLE_USER
ALTER DATABASE LcsCDR SET ONLINE
ALTER DATABASE LcsLog SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE LcsLog SET SINGLE_USER
ALTER DATABASE LcsLog SET ONLINE
ALTER DATABASE QoEMetrics SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE QoEMetrics SET SINGLE_USER
ALTER DATABASE QoEMetrics SET ONLINE




Von diesem Zeitpunkt an kann man nur noch eine Verbindung pro Datenbank öffnen. Das heißt man kann auch nur eine Query im Management-Studio gleichzeitig geöffnet haben. Die alten Hasen werden nun vermutlich lachen, aber ich bin fast verzweifelt, bevor ich das kapiert habe…


Nun denn, nachdem das erledigt wurde, können wir die Datenbanken in einem Ordner unserer Wahl sichern. Dies erledigen wir über folgendes Script:




USE Master;
GO
BACKUP DATABASE cpsdyn
TO DISK = 'D:\BackUp\cpsdyn.bak'
GO
BACKUP DATABASE rgsconfig
TO DISK = 'D:\BackUp\rgsconfig.bak'
GO
BACKUP DATABASE rgsdyn
TO DISK = 'D:\BackUp\rgsdyn.bak'
GO
BACKUP DATABASE rtcab
TO DISK = 'D:\BackUp\rtcab.bak'
GO
BACKUP DATABASE rtcshared
TO DISK = 'D:\BackUp\rtcshared.bak'
GO
BACKUP DATABASE rtcxds
TO DISK = 'D:\BackUp\rtcxds.bak'
GO
BACKUP DATABASE mgc
TO DISK = 'D:\BackUp\mgc.bak'
GO
BACKUP DATABASE lcscdr
TO DISK = 'D:\BackUp\lcscdr.bak'
GO
BACKUP DATABASE lcslog
TO DISK = 'D:\BackUp\lcslog.bak'
GO
BACKUP DATABASE qoemetrics
TO DISK = 'D:\BackUp\qoemetrics.bak'






Kopieren der Daten und Umstellung der Topologie


Die gesicherten Daten können wir nun nehmen und schon mal zum Zielserver verschieben. Damit es zu keinen Irritationen kommt: Wir haben auch auf dem Zielserver wieder unter dem Laufwerk D: einen „BackUp“-Ordner erstellt. Dieser Pfad ist noch nicht der entgültige Pfad, dieser wird später beim Import der Datenbanken gesetzt.


Nun gehen wir auf unseren CMS-Host, laden uns die Topologie herunter und passen die Einstellungen an:


    

  1. Erstellung des SQL Server Stores:
    
Unter Lync Server ->  <Site> -> Shared Components rechtsklicken wir auf „SQL Server stores“ und klicken dann auf New SQL Server Store… . Die hier benötigten Daten sollten klar sein, FQDN des Servers und der Instanzname. Im Anschluss mit OK bestätigen.
    2. 

  2. Nun können wir auf den FrontEnd-Pool rechtsklicken und gehen dann auf Edit Properties… . Unter dem Punkt „Associations“ können wir nun den neuen SQL Server store auswählen. Direkt darunter können wir auch noch für die Archivierung den Server auswählen.
    3. 

  3. Nun werden wir die Topologie publishen. Dabei wird uns auch gesagt, dass er nun eine Datenbank auf dem Server anlegen wird. Das ist schön, denn das wollen wir. Wenn der Wizard mit einer Warning bei „Creating Database“ erfolgreich abschließt, ist der erste Schritt getan.
    4. 

  4. Nun widmen wir uns erneut der Topologie, rechtsklicken diesmal auf den Persistent Chat-Pool, öffnen wieder die Properties und wählen auch hier den neuen SQL Server store.
    5. 

  5. Nun wiederholen wir Schritt 3 nochmal, publishen erneut die Topologie und lassen uns wieder eine Datenbank erstellen. Auch hier kann wieder eine Warnung beim letzten Schritt stehen.
    6. 



Damit sind die Änderungen in der Topologie abgeschlossen.


Import der Bestandsdaten in die neue Datenbank


Bevor wir beginnen, müssen wir auf dem neuen Server die eben erstellten Datenbanken ebenfalls in diesen SingleUser-Modus bekommen. Dazu führen wir unser bereits von oben bekanntes Script erneut aus:




ALTER DATABASE cpsdyn SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE cpsdyn SET SINGLE_USER
ALTER DATABASE cpsdyn SET ONLINE
ALTER DATABASE rgsconfig SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE rgsconfig SET SINGLE_USER
ALTER DATABASE rgsconfig SET ONLINE
ALTER DATABASE rgsdyn SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE rgsdyn SET SINGLE_USER
ALTER DATABASE rgsdyn SET ONLINE
ALTER DATABASE rtcab SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE rtcab SET SINGLE_USER
ALTER DATABASE rtcab SET ONLINE
ALTER DATABASE rtcshared SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE rtcshared SET SINGLE_USER
ALTER DATABASE rtcshared SET ONLINE
ALTER DATABASE rtcxds SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE rtcxds SET SINGLE_USER
ALTER DATABASE rtcxds SET ONLINE
ALTER DATABASE mgc SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE mgc SET SINGLE_USER
ALTER DATABASE mgc SET ONLINE
ALTER DATABASE LcsCDR SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE LcsCDR SET SINGLE_USER
ALTER DATABASE LcsCDR SET ONLINE
ALTER DATABASE LcsLog SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE LcsLog SET SINGLE_USER
ALTER DATABASE LcsLog SET ONLINE
ALTER DATABASE QoEMetrics SET OFFLINE WITH ROLLBACK AFTER 10 Seconds
ALTER DATABASE QoEMetrics SET SINGLE_USER
ALTER DATABASE QoEMetrics SET ONLINE






Nun können wir unseren Bestand in die neuen Datenbanken integrieren. Hierzu ist folgendes Script nötig, wobei wieder der Quellpfad und Zielpfad auf die individuellen Einstellungen anzupassen sind:




USE Master;
RESTORE DATABASE [cpsdyn] FROM DISK = N'D:\BackUp\cpsdyn.bak' WITH FILE = 1,
MOVE N'cpsdyn_data' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\cpsdyn.mdf',
MOVE N'cpsdyn_log' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\CPSDYN.LDF',
NOUNLOAD, REPLACE, STATS = 10
GO
RESTORE DATABASE [rgsconfig] FROM DISK = N'D:\BackUp\rgsconfig.bak' WITH FILE = 1,
MOVE N'rgsconfig_data' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\rgsconfig.mdf',
MOVE N'rgsconfig_log' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\rgsconfig.LDF',
NOUNLOAD, REPLACE, STATS = 10
GO
RESTORE DATABASE [rgsdyn] FROM DISK = N'D:\BackUp\rgsdyn.bak' WITH FILE = 1,
MOVE N'rgsdyn_data' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\rgsdyn.mdf',
MOVE N'rgsdyn_log' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\rgsdyn.LDF',
NOUNLOAD, REPLACE, STATS = 10
GO
RESTORE DATABASE [rtcab] FROM DISK = N'D:\BackUp\rtcab.bak' WITH FILE = 1,
MOVE N'rtcab_data' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\rtcab.mdf',
MOVE N'rtcab_log' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\rtcab.LDF',
NOUNLOAD, REPLACE, STATS = 10
GO
RESTORE DATABASE [rtcshared] FROM DISK = N'D:\BackUp\rtcshared.bak' WITH FILE = 1,
MOVE N'rtcshared_data' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\rtcshared.mdf',
MOVE N'rtcshared_log' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\rtcshared.LDF',
NOUNLOAD, REPLACE, STATS = 10
GO
RESTORE DATABASE [rtcxds] FROM DISK = N'D:\BackUp\rtcxds.bak' WITH FILE = 1,
MOVE N'rtcxds_data' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\rtcxds.mdf',
MOVE N'rtcxds_log' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\rtcxds.LDF',
NOUNLOAD, REPLACE, STATS = 10
GO
RESTORE DATABASE [mgc] FROM DISK = N'D:\BackUp\mgc.bak' WITH FILE = 1,
MOVE N'mgc_data' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\mgc.mdf',
MOVE N'mgc_log' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\mgc.LDF',
NOUNLOAD, REPLACE, STATS = 10
GO
RESTORE DATABASE [LcsCDR] FROM DISK = N'D:\BackUp\LcsCDR.bak' WITH FILE = 1,
MOVE N'LcsCDR_data' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\LcsCDR.mdf',
MOVE N'LcsCDR_log' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\LcsCDR.LDF',
NOUNLOAD, REPLACE, STATS = 10
GO
RESTORE DATABASE [LcsLog] FROM DISK = N'D:\BackUp\LcsLog.bak' WITH FILE = 1,
MOVE N'LcsLog_data' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\LcsLog.mdf',
MOVE N'LcsLog_log' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\LcsLog.LDF',
NOUNLOAD, REPLACE, STATS = 10
GO
RESTORE DATABASE [QoEMetrics] FROM DISK = N'D:\BackUp\QoEMetrics.bak' WITH FILE = 1,
MOVE N'QoEMetrics_data' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\QoEMetrics.mdf',
MOVE N'QoEMetrics_log' TO N'D:\MSSQL12.SKYPE4BUSINESS\MSSQL\DATA\QoEMetrics.LDF',
NOUNLOAD, REPLACE, STATS = 10
GO




Damit ist der Import an sich erledigt.


Abschließende Einstellungen


Zum Abschluss nehmen wir die Datenbanken wieder in den MultiUser-Mode. Erledigt wird das mit folgendem Script:




ALTER DATABASE cpsdyn SET multi_USER
ALTER DATABASE rgsconfig SET multi_USER
ALTER DATABASE rgsdyn SET multi_USER
ALTER DATABASE rtcab SET multi_USER
ALTER DATABASE rtcshared SET multi_USER
ALTER DATABASE rtcxds SET multi_USER
ALTER DATABASE mgc SET multi_USER
ALTER DATABASE LcsCDR SET multi_USER
ALTER DATABASE LcsLog SET multi_USER
ALTER DATABASE QoEMetrics SET multi_USER




Dann muss man noch ein sogenanntes „Cross-Database Ownership Chaining“ auf der RTCshared-Datenbank aktivieren. Hierzu rechtsklicken wir auf die Datenbank und führen eine neue Query aus mit folgendem Inhalt:




ALTER DATABASE rtcshared SET DB_CHAINING ON;




Reaktivierung der Lync-Dienste + Funktionsüberprüfung


Dank der Notizen, die wir bzgl. der Reihenfolge der Abschaltungen der Frontend-Serverdienste gemacht hatten, können wir nun in entgegengesetzter Richtung die Server wieder anfahren. Dies geschieht mit folgendem Befehl:




Start-CsWindowsService




Währenddessen können wir zur Funktionsprüfung den Eventlog aufmachen (RUN -> eventvwr). Dort sehen wir dann schön die Statusmeldungen beim Starten der einzelnen Dienste und auch die sich öffnenden Verbindungen auf den neuen Datenbankserver.


Damit sind wir durch. Lediglich den CMS können wir noch zurückverlagern auf einen FrontEnd-Server.


		


	


	

		
		


			

		


		
	


	






	



	


		
			

				
					Kategorien				
				

					Zertifikate Exchange Server Windows				

			


			
Exchange 2007-2013: Umstellen der internen URLs auf die externen Namen

		


			

		


		
	





	


		


			
Um den vollen Funktionsumfang aller Exchange-Dienste ausnutzen zu können, müssen alle Namen, sowohl intern als auch extern, mit einem oder mehreren Zertifikaten abgedeckt werden. Nun hat man zwei Möglichkeiten, das ganze zu bewerkstelligen:


    

  1. Verwendung von zwei unterschiedlichen Zertifikaten: Eins ausgestellt von der internen CA zur Abdeckung aller internen URLs und eins ausgestellt von einem Zertifikatsanbieter Ihrer Wahl zur Abdeckung der externen URLs.
    2. 

  2. Umstellung der internen URLs auf die externen, um anschließend im internen DNS die öffentlichen URLs zusätzlich zu pflegen, allerdings unter Verwendung von internen IPs. Hier wird dann nur ein Zertifikat benötigt.
    3. 



Die bisherige dritte Möglichkeit, nämlich sowohl lokale als auch öffentliche URLs in ein Zertifikat zu packen, wird ab dem 1. November 2015 nicht mehr unterstützt. Für mehr Informationen hierzu klicken Sie bitte auf folgenden Link: https://www.icann.org/en/system/files/files/sac-057-en.pdf


Die zweite Möglichkeit werden wir nun durchführen. Hierfür müssen wir allerdings einige Befehle in der Exchange Management Shell absetzen. Diese lauten wie folgt:


Set-ClientAccessServer -Identity <HostName> -AutodiscoverServiceInternalUri https://mail.example.de/autodiscover/autodiscover.xml


Set-WebServicesVirtualDirectory -Identity "<HostName>\EWS (Default Web Site)" -InternalUrl https://mail.example.de/ews/exchange.asmx


Set-OABVirtualDirectory -Identity "<HostName>\oab (Default Web Site)" -InternalUrl https://mail.example.de/oab


Set-ActiveSyncVirtualDirectory -Identity "<HostName>\Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl https://mail.example.de/Microsoft-Server-ActiveSync


Set-OWAVirtualDirectory -Identity "<HostName>\owa (Default Web Site)" -InternalUrl https://mail.example.de/owa


Set-ECPVirtualDirectory -Identity "<HostName>\ecp (Default Web Site)" -InternalUrl https://mail.example.de/ecp


Optional (kann zuvor über Get-OutlookAnywhere getestet werden):


Set-OutlookAnywhere -Identity "<HostName>\Rpc (Default Web Site)" -InternalHostname  -InternalClientsRequireSsl $true


Im Anschluss daran muss man den IIS Application Pool recyclen, damit die Änderungen wirksam werden. Hierfür muss der IIS Manager geöffnet werden. Darin angekommen, klicken wir unter Application Pools auf den MSExchangeAutodiscoverAppPool und anschließend auf Recycle. Sobald dies erledigt ist, sind die Einstellungen übernommen und die Clients ziehen sich bei der nächsten Autodiscover-Abfrage die neuen URLs.