Manchmal muss man Abhängikeiten von Windows-Diensten untereinander bearbeiten. Die Abhängigkeiten machen auch genau das was sie sagen: Dienste starten damit erst, wenn ein Anderer fertig ist.
Sinnvoll ist das zum Beispiel bei Lizenzdiensten die erst nach dem USB-Link starten sollen oder Middleware-Services erst nach einer Datenbank.
Lösung
An der guten alten CMD-Shell (als Administrator) lassen sich Abhängigkeiten schnell hinzufügen:
sc config <DIENST> depend=<ABHAENGIG VON ANDEREM DIENST>
Manchmal sieht man sich beim Setup/Update der Microsoft Visual C++ Redistributeable Runtime(s) mit diesem Fehler konfrontiert. Spannederweise ist die Fehlermeldung („Error Message“ höhö) auch auf einem deutschen Windows auf englisch:
The feature you are trying to use is on a network resource that is unavailable.
Lösung
In den allermeisten Fällen reicht es aus, diese Registry-Schlüssel samt Inhalt zu löschen:
Unterhalb von
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products
jeden Schlüssel der "Microsoft Visual C++ ..." im "ProductName" enthält
Wenn das nicht ausreicht: Prüfen ob der Windows-Installer Dienste korrekt läuft, machmal stürzt dieser ab und startet nicht richtig neu.
„Aus gegebenem Anlass“ schon wieder ein PowerShell Script. Mit leichtem Schmunzeln, denn die Zeit der Tippfehler ist in der IT noch nicht vorbei 😉
„Seral“ ohne „i“ (hier mit wenig hilfreichem Inhalt)
Ein Kunde möchte die Seriennummer seiner neuen Computer als Windows-Computernamen im AD verwendet wissen. Während einer „normalen“ Installation oder auch einer Cloud-Installation (ohne Autopilot) wird der Computername abgefragt, aber niemand kennt seine Seriennummer – und Menschen tendieren gerne mal zu äußerst seltsamen Namen. Daher führt der einfachste Weg zu Lösung über ein Script das die Namensvergabe automatisch nachträglich erledigt.
Das funktioniert nur richtig, wenn die Computer eine Seriennummer imn BIOS (EFI) hinterlegt haben. Ist das Feld leer, gibt Windows „To Be Filled by O.E.M.“ zurück und das Script setzt eine 10-Stellige Zufallszahl ein.
In diesem Fall soll(t)en alle Computer „CMP-<Serial>“ heissen und es gibt nur Clients von HP und Lenovo (mit gefülltem Serial-Feld). Selbige nutzen allerdings unterschiedlich lange Seriennummer, daher kürzen wir diese ein.
Lösung
Hier ist das kommentierte Script. Via Intune oder GPO ausgeführt bekommt so jeder PC nach dem nächsten Start seinen einmaligen Namen.
# Prefix festlegen
# - Achtung, der "Computername" hat maximal 15 Zeichen.
$prefix = "CMP-"
# Serial holen
# - Achtung, KEIN Tippfehler, die Property heisst "BiosSeralNumber"
$serial = Get-ComputerInfo | Select-Object BiosSeralNumber
$serial = $serial.BiosSeralNumber
# Kürzen (auf die ersten 10 Stellen)
$serial = $serial.substring(0, 10)
# leerzeichen entfernen
$serial = $serial.replace(' ','')
# Wenn leer, Warnung ausgeben und Random-Nummer verwenden
if ($serial -like "*ToBeFill*") {
$serial = Get-Random -Minimum 100000000 -Maximum 9999999999
Write-Warning "No Serial found, using Random Number '$serial' instead."
}
# Namen zusammenbauen (und anzeigen)
$computername = $prefix + $serial
Write-Host Henceforth you shall be known as: $computername
# Computer umbenennen
Rename-Computer -NewName $computername -Force -ErrorAction SilentlyContinue
Man registriert sein Windows-Gerät, auch den Home-PC, automatisch ins Microsot 365 AzureAD eines Unternehmens, indem man nach einer Office 365 Installation den Haken bei „Verwaltung meines Gerätes durch meine Organisation zulassen“ nicht entfernt. Alternativ kann man auch links unten auf den „unsichtbaren“ Button „Nein, nur bei dieser App anmelden“ klicken.
Wenn man sein Gerät registiert hat taucht es auch nach wenigen Cloudmomenten im AzureAD Device Manager auf:
Und bekommt von dort einige Richtlinien. Vor allem die Sicherheitsrichtlinien greifen dann auf dem Gerät – machmal ist das bei „Privat-PCs“ etwas überraschend.
Fehler CAA2000B (AADSTS500014)
Standardmäßig tritt beim zurücksetzen der Windows-Hello PIN auf dem PC nach dem Azure AD Registrierungsvorgang dieser Fehler auf:
Es ist ein Problem aufgetreten
wir konnten sie nicht anmelden. Falls dieser Fehler weiterhin besteht, wenden Sie sich an den Systemadministrator, und geben Sie den Fehlercode an: CAA2000B.
Das liegt daran, das der Administrator die „App“ die die Zugangs-PIN ändern will erst zu „seinem“ Azure AD hinzufügen und bestötigen muss.
Lösung
1. Die PIN-Reset Web-App „Service“ aufrufen und als Globaler Administrator anmelden. Am einfachten mit GENAU diesem Link:
Azure Active Directory > Anwendungen > Unternehmensanwendungen > Alle Anwendungen > „PIN“ suchen
Es sollten dort nun zwei Apps auftauchen:
Und schon (nach dem nächsten Neustart mit Internet) funktioniert das PIN-Ändern wieder wie vorher.
Wenn der Vorgang trotzdem noch fehlschlägt, hilft oft ein Blick in das Cloud App Security Dashboard für Anwendungen; möglicherweise hat hier anderer Admin das OAUTH dieser Apps vielleicht blockiert …
