Folgt man den Anweisungen aus dem TechNet von Microsoft, so muss man für einen 2012er Terminal Server ordentlich Features auf dem Server installieren. Um einen Lizenzierungsserver zu hinterlegen, muss eine komplette Infrastruktur mit oft gar nicht benötigtem Zeug installiert werden. Bestes Beispiel hierfür wäre der RD Connection Broker, der bei einem einfachen Terminal Server einfach keinen Sinn macht.

Sollten Sie also vor dem selben Problem stehen, können Sie folgende Anleitung befolgen:

  1. Installieren Sie nicht wie empfohlen die ganze “Remote Desktop Services Installation” sondern wechseln Sie zur Rollen- und Featurebasierten Installation. Unter Rollen wählen Sie bitte nur “Remote Desktop Session Host“, mehr wird nicht benötigt.
  2. Nach dem Abschluss der Installation öffnen Sie bitte den Editor für die lokale Gruppenrichtlinie (gpedit.msc). Navigieren Sie dort zu folgendem Pfad:
    Local Computer Policy\Computer Configuration\ Administrative Vorlagen\Windows-Komponenten\Remotedesktopdienste\Remotedesktopsitzungs-Host\Lizenzierung
  3. Bearbeiten Sie bitte folgende Keys:

    Angegebene Remotedesktop-Lizenzserver verwenden:
    Status: Aktiviert
    Zu verwendende Lizenzserver: [FQDN des Lizenzservers]

    Remotedesktop-Lizenzierungsmodus festlegen:
    Status: Aktiviert
    Optionen: [Je nach Lizenztyp auf dem Lizenzserver]

Das sollte es gewesen sein. Wenn Sie jetzt die Lizenzierungsdiagnose öffnen, müsste alles grün sein. Ist dem nicht so, kann ich Ihnen noch folgenden Artikel ans Herz legen:

technet: Terminal Services/Remote Desktop Services: Credentials für Lizenzserver werden nicht gespeichert

Problem:
Schon seit dem Windows Server 2008 kann es zu Problemen kommen beim Hinterlegen der Credentials zum Zugriff auf den Lizenzserver. Oft wird die Benutzerkennung einfach nicht gespeichert und beim nächsten Öffnen der Lizenzierungsdiagnose besteht wieder keine Verbindung zum Lizenzserver.

Ursache:
Der Anmeldedatenspeicher (später Anmeldeinformationsverwaltung) speichert die Benutzerkennung unter Verwendung eines falschen Anmeldedaten-Typs. Richtig wäre “Windows Logon Credential”.

Lösung:
Gehen Sie auf dem betroffenen Terminal Server in die Systemsteuerung (klassische Ansicht) -> Anmeldeinformationsverwaltung. Löschen Sie (falls vorhanden) die für den Lizenzserver gesetzten “Generic”-Anmeldeinformationen und fügen Sie anschließend per Klick auf “Windows Anmeldeinformationen hinzufügen” die Credentials erneut ein:

Internet- oder Netzwerkadresse: [FQDN des Lizenzservers]
Benutzername: DOMAIN\user
Kennwort: Sollte klar sein

Sobald Sie dies mit OK bestätigt haben, sollte die Lizensierungsdiagnose ohne Fehler aufgehen und alles korrekt anzeigen.

Problem: SecureDrive wählt den Speicherort der Cache-Dateien unter Verwendung einiger Kriterien selbst. Nun kann es passieren, dass das Ziel nicht unbedingt immer glücklich gewählt ist, z.B. eine externe Festplatte o.ä.

Lösung: Um das Problem zu beheben, befolgen wir folgende Schritte:

  • SecureDrive beenden, auch aus dem Traymenü
  • Öffnen Sie den Explorer und geben Sie oben folgendes ein:
    %localappdata%\RfUserData
  • Darin befindet sich die ClientPcConfiguration.cfg. Diese bitte mit dem Notepad oder einem vergleichbaren Programm editieren.
  • In der Konfigurationsdatei finden Sie drei Variablen, die zu verändern sind:
    – DataDrive
    – FilePath
    – TempFilePath
    Hinter diesen Variablen steht ein Laufwerksbuchstabe und manchmal noch Verzeichnisse dahinter. Diesen Laufwerksbuchstaben können Sie nun gegen den gewünschten Buchstaben ersetzen.
  • Anschließend kopieren Sie bitte den RushFiles-Cacheordner noch vom alten aufs neue Laufwerk.
  • Jetzt können Sie das SecureDrive wieder starten.

Wenn sich ein bestimmter User nicht für Unified Messaging aktivieren lässt und Sie folgende Fehlermeldung bekommen, dann haben wir hier die Lösung:

Error occurred during execution of UM Mailbox Cmdlet for user “/o=XXX/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=929fc9a62f634c198ea7f630a2593615-XXX”, Error: “Microsoft.Exchange.UM.UMCommon.UmUserException: Access to Active Directory failed.
at Microsoft.Exchange.UM.UMCommon.UmPasswordManager.CommitPasswordAndUpdateChecksum()
at Microsoft.Exchange.UM.UMCommon.UmPasswordManager.SetPassword(EncryptedBuffer digits, Boolean isExpired, LockOutResetMode lockoutResetMode)
at Microsoft.Exchange.UM.UMCommon.Utils.SetUserPassword(MailboxSession mbxSession, UMMailboxPolicy umMbxPolicy, ADUser adUser, String pin, Boolean expired, Boolean lockedOut)
at Microsoft.Exchange.UM.UMCommon.CrossServerMailboxAccess.XSOUMUserMailboxAccessor.<>c__DisplayClassa.b__9()
at Microsoft.Exchange.UM.UMCommon.CrossServerMailboxAccess.XSOUMUserMailboxAccessor.ExecuteXSOOperation(Action function)”

Ursache: Diese typisch nichtssagende Meldung bekommen wir dann, wenn das Postfach aus irgendeinem Grund nicht in den (in der Address Book Policy festgelegten) Adresslisten eingetragen ist.

Behebung: Im ersten Schritt sollte man sich die Address Book Policy anschauen und feststellen, in welche Adresslisten das Postfach gehören sollte. Anschließend schauen wir uns das Postfach an und überprüfen, in welchen Listen es auch eingetragen ist. Im dritten Schritt überprüfen wir die Aufnahmeregeln der Listen, in denen das Postfach nicht ist aber sein sollte und führen dementsprechende Anpassungen durch.

Nach der Auswahl der Server-Version (Standard oder DTC) kann es vorkommen, dass man mit solchen Fehlern konfrontiert wird:

Windows cannot find the Microsoft Software License Terms. Make sure the installation sources are valid and restart the installation.

Keine Sorge, Ihr Installationsmedium ist nicht beschädigt. Dieser Fehler taucht auch meines Wissens nach nur bei virtuellen Maschinen auf.

Die Lösung ist einfach: Die Maschine hat zu wenig Arbeitsspeicher beim Systemstart. Erhöhen Sie bei dynamischem RAM einfach den beim Start verfügbaren und ansonsten den insgesamt bereitgestellten Arbeitsspeicher. Damit sollte das Problem behoben sein.

Manchmal kommt es vor, dass aus heiterem Himmel plötzlich keine Office-Dokumente mehr direkt aus dem SharePoint heraus geöffnet werden können. Folgende Fehlermeldung ist dann zu sehen:

‘[Dateiname]’ konnte nicht geöffnet werden.

Wenn die Datei heruntergeladen und anschließend geöffnet wird, so taucht dieses Problem nicht auf.

Ursache: Office speichert temporär auf dem lokalen Pfad C:\Users\[Benutzername]\AppData\Local\Microsoft\Office\[VersionsNr.]\OfflineFileCache die Dateien ab. Es scheint dabei vorzukommen, dass diese temporären Files nicht vernünftig bereinigt werden. Beim nächsten Öffnen einer Datei aus dem SharePoint bekommen Sie dann eine Fehlermeldung, da er wohl die Dateien nicht mehr richtig überschreiben oder lesen kann.

Lösung: Schließen Sie alle Office-Programme und entfernen Sie nun alle Dateien, die sich in dem Pfad C:\Users\[Benutzername]\AppData\Local\Microsoft\Office\[VersionsNr.]\OfflineFileCache befinden. Anschließend sollten die Dateien wieder aufgehen.

Die Möglichkeit, eine öffentliche Kontaktliste im SharePoint (2010) anzulegen wird von vielen genutzt, um innerhalb des Unternehmens eine Synchronisation der Kontakte zu realisieren.

Nun hat man meistens schon zu diesem Zeitpunkt eine gepflegte Kontaktliste und würde diese gerne in den SharePoint zu integrieren.

Leider gibt es hier eine Einschränkung, welche dafür sorgt dass Kontakte mit einem abweichenden Format in der Website von “https://(www.)domain.tld” nicht synchronisiert werden. Nun kann man von Hand jeden Kontakt überprüfen und bearbeiten, was bei 100+ Kontakten tierisch nerven könnte oder aber man nützt folgendes Script, das die Sache für Sie erledigt:

Download: Prepare-Contacts-For-SP

Für die technisch interessierten hier das Script im Klartext:

"##########################################"
"#            cloud4you GmbH              #"
"#          Webseiten-Korrektur           #"
"##########################################"
""
"    Bitte als Administrator ausführen!!"
""
""
""
"  Die folgende Abfrage bitte bestätigen:"
""
set-executionpolicy remotesigned
""
""
"Sofern bestätigt, läuft das Script nun"
"durch."
"Sollte statt der Abfrage eine rote"
"Fehlermeldung gekommen sein, wurde das"
"Script nicht als Administrator"
"ausgeführt. Sollte dies der Fall sein,"
"müssen Sie es nochmals ausführen, "
"trotz Erfolgsmeldung unten."
""
""
$outlook = new-object -com outlook.application

$contacts = $outlook.Session.GetDefaultFolder(10)

$contacts.Items | % { if($_.BusinessHomePage -NotMatch "http://")
{
    $_.BusinessHomePage = "http://" + $_.BusinessHomePage
    $_.save()    
}}
""
""
"Die Bearbeitung der Kontakte ist abgeschlossen."
""
"Nun können Sie die Kontakte in den SP schieben,"
"natürlich nur, wenn nichts rot geschrieben war."

Interessant für folgende Szenarien:

  • Einfache Verteilung von Software
  • Als Hoster für die Weitergabe von Outlook an Kunden (mit eingetragenem Product Key)

So geht’s:

Als erstes benötigen Sie ein Installationsmedium bzw. einen Ordner welcher die Installationsfiles beinhaltet. Diese Daten kopieren Sie nun einfach auf C:\Temp (Sie können auch einen anderen Pfad nehmen, den müssen Sie dann bei dem Rest der Anleitung immer umschreiben). Nun klicken Sie auf [Start] -> [Ausführen] und geben dort folgende Zeile ein:

C:\Temp\setup.exe /admin

Hiermit öffnet sich das OCT/OAT (en/de). Hier sind nun kaum Grenzen gesetzt. Ein paar Highlights:

  • Setup -> Lizenzierung und Benutzeroberfläche: Hier kann der Product Key fest gesetzt werden
  • Features -> Featureinstallationsstatus festlegen: Hier können alle Features schon im Voraus definiert werden.
  • Weitere Inhalte -> Verknüpfungen konfigurieren: Hier können bei der Installation noch weitere Verknüpfungen angelegt werden.
  • Outlook: Hier können schon ganze Konten eingerichtet werden.

Wenn die Konfiguration soweit durchgenommen wurde und alles passen sollte, so kann man oben über Datei -> Speichern unter… die Settings abspeichern. Als Speicherpfad wird aber nicht irgendeiner gewählt sondern folgender Pfad verwendet:

C:\Temp(\x86)\Updates
\x86 ist je nach Installationsmedium zu verwenden oder nicht.

Jetzt kann das Paket wieder auf CD gebrannt, als ISO gebuildet oder so herausgegeben werden. Wenn der User dann das Setup ausführt, wird automatisch die Patch-Datei eingelesen und die Installation läuft mit all den gewünschten Anpassungen durch.

Ein Szenario, welches viele wohl so oder so ähnlich schon kennen: Sie haben ein Exchange Postfach vor sich, höchst ordentlich verschachtelt und organisiert mit zwei- oder gar dreistelligen Zahlen von Ordnern und Unterordnern.
Und nun plötzlich benötigt der Kollege am anderen Schreibtisch Zugriff auf einen dieser Ordner. An für sich nicht schwer denken Sie sich eventuell nun, einfach dem Benutzer Rechte vergeben auf den Ordner und die Sache ist erledigt.
Soweit richtig, doch wie sieht das ganze bei diversen Unterordnern aus? Um es kurz zu machen, äußerst bescheiden. Sie müssten für jeden Unterordner explizit nochmal die Rechte vergeben, eine Vererbung wird nicht auf bereits bestehende Ordner angewendet.

Doch wir schaffen Abhilfe! Führen Sie Add-Inheritet-Rights.ps1 auf Ihrem Exchange-Server aus, und Sie können bequem vererbte Rechte vergeben. Für technisch interessierte oder vorsichtige Leute auch hier nochmal das Script im Klartext:

<#
.SYNOPSIS
    Mit Hilfe dieses Scripts können im Nachhinein Rechte auf bestimmte Ordner UND Unterordner in Outlook vergeben werden.
.PARAMETER AffectedMailbox
    Hier das Postfach bestimmen, aus welchem Ordnerrechte geändert werden sollen. Format: (user@domain.de) 
.PARAMETER UserWhoGetsRights
    Benutzer/Mailbox definieren, die nun Rechte bekommt auf das bestimmte Postfach. Format: (user@domain.de)
.PARAMETER PathOfTheFolder
    Pfad des bestimmten Ordners (Format: /Posteingang/Ordner/Unterordner)
.EXAMPLES
    ohne Parameter: ".\Add-Inheritet-Rights.ps1"
    mit  Parameter: ".\Add-Inheritet-Rights.ps1 -AffectedMailbox="a@b.com" -UserWhoGetsRights="d@e.com" -PathOfTheFolfer="/Inbox"
#>

Param
(
    [string]$AffectedMailbox,
    [string]$UserWhoGetsRights,
    [string]$PathOfTheFolder
)


Write-Host "Exchange Snapin Loading...."
Add-PSSnapin Microsoft.Exchange.Management.Powershell.Snapin
Write-Host "Exchange Snapin Loaded."
Write-Host ""
Write-Host "=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-"
Write-Host "Script für Vererbbare Rechte - (c) by cloud4you.biz  -=-=-=-=-=-=-=-=-=-=-=-"
Write-Host "=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-"
Write-Host ""
If ($AffectedMailbox -eq "")
{
    $AffectedMailbox = Read-Host "Auf welchem Postfach werden neue Rechte hinzugefügt? (Format: user@domain.de)"
}
Write-Host ""
$GetMailbox = Get-Mailbox $AffectedMailbox
Write-Host "Zutreffende Postfächer:" $GetMailbox.Length
Write-Host ""
If ($GetMailbox.Length -eq 1)
{
    If ($UserWhoGetsRights-eq "")
    {
        $UserWhoGetsRights = Read-Host "Welcher Benutzer bekommt in dem Postfach Rechte? (Format: user@domain.de)"
    }
	Write-Host ""
	$GetMailbox = Get-Mailbox $UserWhoGetsRights
	Write-Host "Zutreffende Postfächer:" $GetMailbox.Length
	Write-Host ""
	If ($GetMailbox.Length -eq 1)
	{
		If ($PathOfTheFolder -eq "")
        {
            $PathOfTheFolder = Read-Host "Und nun benötige ich den Pfad (Format: /Posteingang/Ordner/Unterordner)"
        }
		$GetFolders = Get-MailboxFolderStatistics -identity $AffectedMailbox | WHERE {$_.FolderPath.Contains($PathOfTheFolder) -eq $true}
		If ($GetFolders.Length -gt 0)
		{
			ForEach($folder in (Get-MailboxFolderStatistics -identity $AffectedMailbox | WHERE {$_.FolderPath.Contains($PathOfTheFolder) -eq $true} ) )
			{
				$foldername = $AffectedMailbox + “:” + $folder.FolderPath.Replace(“/”,”\”);
				Add-MailboxFolderPermission $foldername -User $UserWhoGetsRights -AccessRights PublishingEditor
			}
			Write-Host ""
			Write-Host $GetFolders.Length "Ordner wurden bearbeitet"
		}
		Else
		{
			Write-Host ""
			Write-Host "Es wurden keine Ordner unter diesem Pfad gefunden."
		}
	}
	Else
	{
		Write-Host ""
		Write-Host "Der Benutzer wurde nicht gefunden oder war nicht eindeutig."
	}
}
Else
{
	Write-Host ""
	Write-Host "Das Postfach wurde nicht gefunden oder war nicht eindeutig."
}
Write-Host ""
$Unnoetig = Read-Host "Drück Eingabe"

Um Freeswitch ordentlich debuggen zu können, sind folgende Konsolenbefehle hilfreich:

Loglevel der Konsole setzen:
console loglevel – Gibt das aktuelle Loglevel aus
console loglevel [0-7] – Stellt das Loglevel ein

Beschreibung der Loglevel:
0 – Console (Hotkey F7)
1 – Alert
2 – Critical
3 – Error
4 – Warning
5 – Notice
6 – Info
7 – Debug (Hotkey F8)

SIP-Logging aktivieren:
sofia profile internal siptrace on – Aktiviert SIP-Logs für interne Kommunikation
sofia profile external siptrace on – Aktiviert SIP-Logs für externe Kommunikation

Einfärben der Konsole:
console colorize [on|off|toggle] – Aktiviert/Deaktiviert die Einfärbung