Stempel für den Adobe Acrobat Reader erstellen („Eingescannte Unterschrift stempeln“)

Manchmal möchte man schnell ein Dokumuent unterschrieben, das als PDF vorliegt. Das PDF auszudrucken, zu unterschrieben und wieder einzuscannen ist heute glücklicherweise nicht mehr nötig.

So scannt man seine Unterschrift ein, um diese im Adobe reader als „Stempel“ zu verwenden.

1. Unterschrift einscannen

Das Autogramm muss natürlich einmal digitalisiert werden. Das geht durch das einscannen oder auch direkt digital, zum Beispiel mit einem Stift auf einem Tablet.

2. Unterschrift freistellen

Mit einem Grafikprogramm muss die Unterschrift von ihrem „Untergrund“ befreit werden. Wenn beispielsweise ein weißes Stück Papier mit eingescannt wurde, muss dies entfernt werden. Andernfalls würde der Stempel auch das weiße Rechteck „mitstempeln“, aber wir benötigen ja nur die Unterschrift. Das Speicherformat muss hinterher ein transparentes PNG oder GIF sein.

Das geht beispielsweise mit Photoshop – und hier kann man das Ergebnis auch direkt als transparentes PNG aufspeichern.

3. Die Signatur als PDF ablegen

Da das in keine Programm (außer dem Acrobat) direkt zu funktionieren scheint, nutzen wir diesen recht zuverlässigen Weg :

  1. Die Unterschrift in Microsoft Word einfügen (sonst nichts tun)
  2. Das neue Dokument „Als PDF speichern“

4. Dieses PDF im Adobe Acrobat Reader als Stempel einfügen

  1. Reader öffnen
  2. Oben auf den Tab „Werkzeuge“ wechseln, dann „Stempel“ öffnen
  3. „Benutzerdefinierte Stempel“ -> „Durchsuchen“ und die PDF-Datei auswählen
  4. Namen und wenn gewünscht Kategorie vergeben, fertig.

Ab jetzt steht der Stempel zur Auswahl beim einfügen zur Verfügung.

Installation RRAS (Routing und Ras) schlägt fehl: „Der Vorgang kann nicht abgeschlossen werden, da der angegebene Server neu gestartet werden muss.“

Problem

Die Rolle „Routing und RAS“ als Kernkomponente für den sicheren Fernzugriff via VPN hat seit Windows Server 2016 einen schlechten Ruf. Leider ist dieser unter Server 2019 noch mehr gerechtfertigt; die RRAS Services und deren Konfiguration sind bis zur Unbenutzbarkeit mit Fehlern behaftet.

Neu ist für uns aber der Installationsfehler: Fügt man via „Install-WindowsFeature Routing“ oder dem Server-Manager den RRAS Service hinzu („Remotezugriff“), beschwert sich der Server nach einer erfolglosen Installation:

Der Vorgang kann nicht abgeschlossen werden, da der angegebene Server neu gestartet werden muss.

Ein Neustart hilft hier (natürlich) nicht weiter.

Lösung

Die Installation scheitert an der WID, der „Internen Windows Datenbank“. WID ist eine SQL Express Instanz, die „Als Dienst anmelden“ Berechtigungen benötigt. Etwas ungeschickt ist hier, das der Dienst als „NT SERVICE“ starten will, der diese Rechte auf DCs (und einigen anderen Rollen) nicht (mehr) hat.

Also muss man die Default Domain Controllers Policy (bei DCs), die Default Domain Policy (bei „Hardened Networks“) oder die jeweils zutreffende Policy anpassen. Das macht man am besten nach einem sauberen Neustart.

Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Lokale Richtlinien > Zuweisen von Benutzerrechten > Anmelden als Dienst

Hier müssen die folgenden Identities Mitglied sein:

  • DIENST
  • NETZWERK
  • Netzwerkdienst
  • IIS_WPG (wenn SSTP oder DirectAccess genutzt werden soll)

Schliessen, GPUPDATE /FORCE udn schon läuft die Installation fehlerfrei durch.

Windows Server 2019 „Set-RDWorkspace“ Fehler „Ausnahme beim Aufrufen von ‚Put‘ mit 0 Argument(en):“

Das CMDlet Set-RDWorkspace ist unter Windows Server 2019 (wie so vieles andere ebenfalls) kaputt. Man sollte eigentlich den Workspace-Namen so setzen können:

Set-RDWorkspace -Name "Welt der Wunder"

Aber der Befehl produziert nur einen Fehler:

Set-RDWorkspace : Fehler beim Aktualisieren des Arbeitsbereichs für den RD-Verbindungsbrokerserver
 "FQDN.MEINESSERVERS".
 Fehler: Ausnahme beim Aufrufen von "Put" mit 0 Argument(en):  ""
 In Zeile:1 Zeichen:1
 Set-RDWorkspace -Name "Welt der Wunder"
 ~~~~~~~~~ CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
 FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Set-RDWorkspace 

Lösung

Den Workspace-Namen und die Beschreibung („Description“) setzt man am besten direkt in der Registry in dem Schlüssel HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralizedPublishing

Windows Registry Editor Version 5.00

 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralizedPublishing]
 "WorkspaceName"="Welt der Wunder"

Windows 10 Offlinedateien zurücksetzen (reset)

Problem

Manchmal macht der (prinzipiell gutmeinende) Windows 10 Offline-Cache, namentlich „Offlinedateien“ oder auch „CSC“ für Client-Side Caching, absurde Sachen. Gerne lässt sich diese fiese kleine Mimose auch durch Serverumzüge verwirren und präsentiert unlösbare Konflike im Synccenter. Es „entstehen“ auch manchmal unlöschbare Ordner, neue Dokumente kommen auf Dateiservern nicht mehr (zuverlässig) an und generell ist das was der Explorer zeigt nicht mehr das selbe was der Explorer auf dem Fileserver auflistet.

Lösung

In den meisten Fällen hilft ein Zurücksetzen des Caches. Achtung, dabei wird sämtlicher zwischengespeicherter Inhalt entfernt, man sollte also von den betroffenen Daten eine Sicherung haben.

Möglichkeit 1: Cache neu erstellen lassen (liebevolle Variante)

Einen neuen DWORD-Wert (32bit) “ FormatDatabase“ mit dem Wert „1“ erstellen:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CSC\Parameters]
"FormatDatabase"=dword:00000001

Danach rebooten.

Die meisten Synchronisationsfehler sind damit schon behoben. Als hätten die Programmierer des CSC geahnt das dieses transparente Caching-Konzept … „anfällig“ sein könnte.

Möglichkeit 2: Cache komplett löschen (krasse Variante)

Der Offline-Cache wohnt in %windir%\CSC. Dieser Inhalt muss komplett entsorgt werden.

  1. Als ein anderer Benutzer anmelden (man kann seinen „eigenen“ Cache nicht wärend man aangemeldet ist löschen)
  2. Besitz von „C:\Windows\CSC“ als Benutzer (keine Gruppe!) übernehmen (mit Unterordnern und Dateien)
  3. Rechte in „C:\Windows\CSC“ für den Vollzugriff vererben
  4. Ordnerinhalt komplett löschen
  5. Registry-Eintrag (siehe oben) erstellen
  6. Rebooten
takeown /r /f C:\Windows\CSC
rd /s C:\Windows\CSC
reg add HKLM\SYSTEM\CurrentControlSet\Services\CSC\Parameters /v FormatDatabase /t REG_DWORD /d 1
shutdown -r -f -t 0

AADConnect Kennwort eines Benutzers neu in das Azure AD synchronisieren

Problem

Nach der „Kennwort zurücksetzen“ Aktion der Administrators einer lokalen Domäne wird das neue Kennwort eines Benutzes nicht automatisch in das Azure AD (Office 365) synchronisiert.

Der Benutzer kann sich zwar in dem lokalen AD mit seinem neuen Kennwort anmelden, in Office 365 aber weiterhin nur mit dem alten.

Ändert ein Benutzer selbser sein Kennwort (STRG+ALT+ENTF), wird das neue Kennwort sofort (max 120 Sekunden) synchronisiert.

Lösung

Von manuellen Datenbank-Änderungen an der Client-API „vorbei“ bekommt AADConnect (ADsync) nichts mit. Da es (ohne weiteres) nicht möglich ist, Kennworthashes aus dem AzureAD für einen Vergleich zu exportieren, bleiben die Kennwörter bis zur nächsten Änderung unterschiedlich.

Das Kennwort kann aber einfach manuell (nachträglich) neu synchronisiert werden.

  • PowerShell auf der AADConnect Maschine öffnen („Als Administrator“, mit ExecutionPolicy auf mindestens „RemoteSigned“)
  • Distinguished Name (DN) des Benutzers besorgen:
    • Get-ADUser NAME | select D*
  • Assistenten zur Synchronisation des Kennworthashes des DNs starten:
    • Invoke-ADSyncDiagnostics
  • Dem Assistenten folgen (2 > 3 …)

Schon fertig 🙂