Firewall Regeln in unbeaufsichtigter Windows Installation aktivieren

Aus dem Leben: Aufgabe war, eine automatisierte Installation eines Windows 2016 Servers zu generieren, bei der sofort RDP aktiv ist. Sieht einfach aus, ist auch überall dokumentiert, z.B. hier.

Funktioniert auch soweit, bis auf das Aktivieren der nötigen Firewall Regeln. Meine erste Idee war, das es ein Problem mit der deutschen Serverversion ist, weil die Regelgruppe, die aktiviert werden soll, im Deutschen „Remotedesktop“ heißt (statt „Remote Desktop“ im Englischen). War es aber nicht. Nach insgesamt 9! Versuchen habe ich dann das hier gefunden:

<FirewallGroups>
      <FirewallGroup wcm:action="add" wcm:keyValue="RemoteDesktop">
      <Active>true</Active>
      <Group>@FirewallAPI.dll,-28752</Group>
      <Profile>all</Profile>
   </FirewallGroup>
</FirewallGroups>

Zu beachten die Zeile „@FirewallAPI.dll,-28752“. Ich war also schon auf der richtigen Spur. Aber das die Abfrage beim Setup nicht auf den übersetzten Namen, sondern auf den Link in die DLL zur Ressource prüft, darauf bin ich dann doch nicht gekommen.
Die komplette Sektion in der unattended.txt für das Aktivieren von RDP sieht für den Windows Server 2016 wie folgt aus:

<settings pass="specialize">
    <component name="Microsoft-Windows-TerminalServices-LocalSessionManager" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
        xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <fDenyTSConnections>false</fDenyTSConnections>
    </component>
    <component name="Microsoft-Windows-TerminalServices-RDP-WinStationExtensions" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
        xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <UserAuthentication>0</UserAuthentication>
    </component>
    <component name="Networking-MPSSVC-Svc" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
        xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <FirewallGroups>
                    <FirewallGroup wcm:action="add" wcm:keyValue="RemoteDesktop">
                    <Active>true</Active>
                    <Group>@FirewallAPI.dll,-28752</Group>
                    <Profile>all</Profile>
                </FirewallGroup>
        </FirewallGroups>
    </component>
</settings>
Mehr

PRTG per Powershell bedienen

PRTG (https://www.de.paessler.com/prtg), mein Lieblingstool zur Netzwerküberwachung, hatte für mich bisher immer den Nachteil, das man es nicht so richtig auf der Kommandozeile bedienen konnte. Immer mal wieder kam die Aufgabe eine bestimmten Sensor zu allen bestehenden Server- Objekten hinzuzufügen. Kann man von Hand machen. Ist aber bei vielen Servern echt lästig.

Kurze Suche fördert das Projekt PrtgApi bei GitHub zu Tage. Gut gepflegt und aktuell lässt es praktisch keine Wünsche offen und mir das Herz höher schlagen.
Nachdem ich mir die richtigen Dateien zu einem Powershell- Modul zusammen kopiert und installiert hatte war das hinzufügen eines Sensors zu allen Servern eine Sache von ein paar Minuten:

import-module prtgapi 
connect-prtgserver servername

# Quelle
$quellSensor = get-device quellServer | get-sensor Quelle

# Und auf ein anderes Device klonen
get-device zielServer | clone-object -SourceID $quellSensor.id

# jetzt noch starten:
get-device zielServer | get-sensor Quelle | Resume-Object

Das geht natürlich auch mit einem Array an Zielservern…. sehr cool.
Die API kann noch viel mehr und es lohnt sich da mal etwas tiefer zu graben.

Mehr

PDFs aus Worddateien im Explorer erstellen

Microsoft Word hat ja seit einiger Zeit eine Möglichkeit direkt aus der Anwendung ein PDF zu erzeugen. Das ist praktisch und macht Adobe Acrobat für meine Zwecke komplett überflüssig. Ich hatte jedoch heute das Problem, das ich aus einer großen Anzahl von Dokumenten PDFs erzeugen wollte. Alle nacheinander öffnen und als PDF speichern kam mir so 90er vor. 😉

Nach kurzer Suche im Internet bin ich auf einen coolen Artikel hier gestoßen. Ist nichts weiter als ein kleines Makro in der „normal.dotx“ des Benutzers und ein Registry Key der über „HKEY_Classes_Root“ einen Eintrag in das Rechts- Klick- Menu einer Word- Datei zaubert. Der ruft dann das Makro auf, welches die Datei als PDF speichert. Sehr elegant. Man kann auch mehrere Dateien selektieren und sie konvertieren. Fast genau was ich wollte, bis auf zwei Kleinigkeiten:

  1. ich habe Office 2016 (nicht 2013 wie im Beispiel)
  2. ich will das pro Benutzer haben und nicht pro Rechner

Hier die korrigierten Dateien um meine Problem zu lösen:

Makro in der „normal.dotx“ des Benutzers:

Sub ExportToPDFext()
ChangeFileOpenDirectory ThisDocument.Path
ActiveDocument.ExportAsFixedFormat _
OutputFileName:=Left(ActiveDocument.FullName, InStrRev(ActiveDocument.FullName, ".")) + "pdf", _
ExportFormat:=wdExportFormatPDF, _
OpenAfterExport:=False, _
OptimizeFor:=wdExportOptimizeForPrint, _
Range:=wdExportAllDocument, _
From:=1, _
To:=1, _
Item:=wdExportDocumentContent, _
IncludeDocProps:=True, _
KeepIRM:=True, _
CreateBookmarks:=wdExportCreateNoBookmarks, _
DocStructureTags:=True, _
BitmapMissingFonts:=True, _
UseISO19005_1:=False
Application.Quit SaveChanges:=wdDoNotSaveChanges
End Sub

Registry- Einträge für „Als PDF speichern“ pro Benutzer:

Windows Registry Editor Version 5.00
 
[HKEY_CURRENT_USER\Software\Classes\Word.Document.8\shell\SavePDFhere]
@="Als PDF speichern"
 
[HKEY_CURRENT_USER\Software\Classes\Word.Document.8\shell\SavePDFhere\command]
@="\"C:\\Program Files\\Microsoft Office\\Office16\\WINWORD.EXE\" /mExportToPDFext /q \"%1\""
 
[HKEY_CURRENT_USER\Software\Classes\Word.Document.12\shell\SavePDFhere]
@="Als PDF speichern"
 
[HKEY_CURRENT_USER\Software\Classes\Word.Document.12\shell\SavePDFhere\command]
@="\"C:\\Program Files\\Microsoft Office\\Office16\\WINWORD.EXE\" /mExportToPDFext /q \"%1\""

Achtung: Das ist für die 64-Bit Version von Office 2016, für die 32-Bit Version die Pfade in der Registry entsprechend anpassen.

Mehr

Windows 10 Startmenu geht nicht…

oder genauer gesagt: Es funktioniert KEINE EINZIGE der „Modern“- Apps mehr. Das Startmenu ist nichts anderes. So geschehen, bei einem meiner Kunden beim Windows 10 Rollout. Passiert ist das nach der Installation einer bestimmten Anwendung. Welche, ist völlig egal. Wichtig ist, das das System nach der Installation unbrauchbar ist.
Es gibt echt viele Beschreibungen des Problems und auch einige Lösungen, nur leider funktionierten die alle nicht.

Schlussendlich, nach langen procmon– Sitzungen hab ich dann den Übeltäter gefunden:

HKLM\Software\Microsoft\Ole\DefaultAccessPermission

löschen per „regedit.exe“ (oder zum Test umbenennen, ihr wisst schon: Zu Risiken und Nebenwirkungen von Änderungen in der Registry fragen Sie vertrauensvoll…). Danach funktionierten sofort alle Apps wieder. Neustart war nicht nötig. Und, oh Wunder, die Anwendung die das Problem verursacht hat läuft auch noch.

Ende gut, alles gut.

Mehr

SharePoint führt Workflows doppelt aus…

Folgende Situation: Beim Eingehen einer E-Mail in einer Dokumentenbibliothek soll in einer Liste per Workflow ein neues Element erstellt werden.

Funktioniert auch, aber leider doppelt. Komische Sache.sharepoint

Problem ist die Option „Ursprüngliche E-Mail speichern?“ (siehe Screenshot). In diesem Falle wird der Workflow sowohl für den erstellten Ordner als auch für die gespeicherte E-Mail ausgeführt.

Lösung: Einfach in den Workflow eine Bedingung einbauen die überprüft, ob der Content- Type „Ordner“ ist.

sharepoint2

Mehr