RemoteApps per GPO verteilen (unter Vista/Win 7)?
Aus der MMC des "RemoteApp-Manager" lassen sich wunderbar MSI-Files
für die Installation der freigegebenen Anwendungen erzeugen.
Nun liegt es nahe, diese per GPO über das AD verteilen zu wollen
(zumindest dann, wenn kein Softwaredistributionswerkzeug im Einsatz ist).
Eine Zuweisung auf Computerebene funktioniert fehlerfrei.
Auf Benutzerebene kann allerdings folgender Fehler auftreten:
Eventlog 107:
"... Die SQL-Abfragesyntax ist ungültig oder wird nicht unterstützt."
Dieser Fehler tritt nur dann auf, wenn UAC (User Account Control) aktiviert ist.
Wie evtl. einigen bekannt ist, lässt sich das Installationsverhalten des Windows-Installers ebenfalls per GPO beeinflussen.
Per Einstellung "Immer mit erhöhten Rechten installieren" lässt sich definieren,
dass alle Installationen (des Windows-Installers) die unter dem Benutzerkontext ausgeführt werden, mit erhöhten Rechten installiert werden.
Diese Einstellung lässt sich allerdings nicht an eine GPO binden und gilt für
alle Installationen.
In diesem speziellen Fall ändert es allerdings nichts an dem eigentlichen Fehler. Auch hier bricht die Installation mit Event-ID 107 ab.
Ob man eine Installation auf Benutzerebene zuweisen sollte,
ist eine umstrittene Frage.
Sollte es dennoch erforderlich sein die RemoteApp auf Benutzerebene zu verteilen, gibt es aktuell nur eine Möglichkeit - UAC ausschalten.
Donnerstag, 8. September 2011
Freitag, 8. Juli 2011
DHCP Bereich abstimmen - Was passiert hier eigentlich?
Jeder kennt es wahrscheinlich, die Funktion "Abstimmen..." im Kontextmenü des DHCP Bereiches.
Aber was passiert hier eigentlich?
Für was brauche ich das?
Was ist nun, wenn hier inkonsistente Datensätze angezeigt werden?
Der DHCP Server speichert unterschiedliche Informationen zu den vorhandenen Leases. Diese unterteilen sich in:
In einigen Artikeln wird fälschlicherweise behauptet,
die zusammenfassenden Informationen werden in der Registry gespeichert.
Dies ist nicht der Fall.
Stimmen die Informationen nicht überein, kann dies durch eine Bereichsabstimmung korrigiert werden.
Wann tritt das auf?
Werden falsche oder fehlende Informationen des Clients in die Datenbank eingetragen, so kann es zu Inkonsistenzen kommen.
Eine Bereichsabstimmung vergleicht diese Informationen und korrigiert (meistens) die fehlerhaften Einträge.
Aber was passiert hier eigentlich?
Für was brauche ich das?
Was ist nun, wenn hier inkonsistente Datensätze angezeigt werden?
Der DHCP Server speichert unterschiedliche Informationen zu den vorhandenen Leases. Diese unterteilen sich in:
- detaillierte Informationen (gespeichert in der DHCP Datenbank)
- zusammenfassende Informationen (gespeichert in der DHCP Datenbank)
In einigen Artikeln wird fälschlicherweise behauptet,
die zusammenfassenden Informationen werden in der Registry gespeichert.
Dies ist nicht der Fall.
Stimmen die Informationen nicht überein, kann dies durch eine Bereichsabstimmung korrigiert werden.
Wann tritt das auf?
Werden falsche oder fehlende Informationen des Clients in die Datenbank eingetragen, so kann es zu Inkonsistenzen kommen.
Eine Bereichsabstimmung vergleicht diese Informationen und korrigiert (meistens) die fehlerhaften Einträge.
Donnerstag, 30. Juni 2011
DHCP Server lässt sich nicht autorisieren
Wieder einmal ein seltsames Problem.
Der DHCP Server läuft wunderbar.
Plötzlich behauptet der DHCP-Server er wäre nicht mehr autorisiert.
Gut, das sollte normalerweise kein Problem sein. Hier hinzufügen und gut is. Denkste.
Server steht bereits in der Liste.
Auch beim Rechtsklick im den DHCP-Server im Snap-In => Hier ist nur "Unauthorize" auswählbar.
Ok, ändert allerdings auch nichts am Verhalten.
Lösung:
adsiedit:
Vermeintlich registrierten Server löschen.
CN=Configuration, CN=Services, CN=NetServices.
DHCPServer Dienst neu starten => Nun lässt sich der Server wieder erfolgreich registrieren.
Der DHCP Server läuft wunderbar.
Plötzlich behauptet der DHCP-Server er wäre nicht mehr autorisiert.
Server steht bereits in der Liste.
Auch beim Rechtsklick im den DHCP-Server im Snap-In => Hier ist nur "Unauthorize" auswählbar.
Ok, ändert allerdings auch nichts am Verhalten.
Lösung:
adsiedit:
Vermeintlich registrierten Server löschen.
CN=Configuration, CN=Services, CN=NetServices.
DHCPServer Dienst neu starten => Nun lässt sich der Server wieder erfolgreich registrieren.
[AD / GPO] Replication Access Was Denied - oder Ungeduld wird bestraft!
Soweit zum Hintergrund:
Server 2003 SP2 DC, eine Domain keine Subdomains, Windows 2000 mixed mode, Eventlogs sauber, dcdiag sauber, netdiag i.O.
Und nun zum eigentlichen Phänomen:
Auf den Clients werden keinerlei Group Policies abgearbeitet.
Es scheint so, als wäre keine Policy auf den User- bzw. Computeraccount verlinkt.
Die Default Domain Policy wird jedoch angewandt.
Keine Fehler im Eventlog, keine Fehler bei gpresult, jedoch keine Policies!
Wird der Domaincontroller heruntergefahren, werden die Policies auf einmal
auf den Clients übernommen (da diese einen anderen DC benutzen).
Abhilfe: dcpromo, herabstufen, hochstufen, das übliche Prozedere.
Da es natürlich schnell gehen soll, sofort nach dem Booten im Anschluss
an das Herabstufen, wieder dcpromo ausführen.
Dcpromo meckert es würde noch ein Objekt für diesen DC geben, allerdings wäre es kein Problem da dieses überschrieben wird => Ok
Nach dem nächsten Reboot dann das Problem:
"Replication Access Was Denied".
KCC beschwert sich ebenfalls, dass keine Connection Objects angelegt werden können.
Ein Blick auf das Computerkonto des DCs verrät einiges:
Als Rolle wird angegeben: "Workstation or Server"
Hier sollte eigentlich "Domaincontroller" stehen.
Abhilfe:
Das Attribut "userAccountControl" des Computeraccounts muss geändert werden. Dieses steht bei DCs auf "532480".
Bei Workstations bzw. Memberservern auf "4096".
Beschrieben hier:
http://support.microsoft.com/kb/329860/en-us
Attribut geändert, Rolle wird wieder korrekt angezeigt, Reboot, Replikation läuft!
Was lernen wir daraus?
Das man manchmal auch wirklich warten sollte!
Wartet man nach dem Herabstufen nicht lange genug,
kann es sein, dass während des Promotionvorgangs das Computerkonto nicht aktualisiert werden kann bzw. dessen Änderung durch ungünstige Replikationsvorgänge wieder überschrieben wird.
Server 2003 SP2 DC, eine Domain keine Subdomains, Windows 2000 mixed mode, Eventlogs sauber, dcdiag sauber, netdiag i.O.
Und nun zum eigentlichen Phänomen:
Auf den Clients werden keinerlei Group Policies abgearbeitet.
Es scheint so, als wäre keine Policy auf den User- bzw. Computeraccount verlinkt.
Die Default Domain Policy wird jedoch angewandt.
Keine Fehler im Eventlog, keine Fehler bei gpresult, jedoch keine Policies!
Wird der Domaincontroller heruntergefahren, werden die Policies auf einmal
auf den Clients übernommen (da diese einen anderen DC benutzen).
Abhilfe: dcpromo, herabstufen, hochstufen, das übliche Prozedere.
Da es natürlich schnell gehen soll, sofort nach dem Booten im Anschluss
an das Herabstufen, wieder dcpromo ausführen.
Dcpromo meckert es würde noch ein Objekt für diesen DC geben, allerdings wäre es kein Problem da dieses überschrieben wird => Ok
Nach dem nächsten Reboot dann das Problem:
"Replication Access Was Denied".
KCC beschwert sich ebenfalls, dass keine Connection Objects angelegt werden können.
Ein Blick auf das Computerkonto des DCs verrät einiges:
Als Rolle wird angegeben: "Workstation or Server"
Hier sollte eigentlich "Domaincontroller" stehen.
Abhilfe:
Das Attribut "userAccountControl" des Computeraccounts muss geändert werden. Dieses steht bei DCs auf "532480".
Bei Workstations bzw. Memberservern auf "4096".
Beschrieben hier:
http://support.microsoft.com/kb/329860/en-us
Attribut geändert, Rolle wird wieder korrekt angezeigt, Reboot, Replikation läuft!
Was lernen wir daraus?
Das man manchmal auch wirklich warten sollte!
Wartet man nach dem Herabstufen nicht lange genug,
kann es sein, dass während des Promotionvorgangs das Computerkonto nicht aktualisiert werden kann bzw. dessen Änderung durch ungünstige Replikationsvorgänge wieder überschrieben wird.
Abonnieren
Posts (Atom)