Standardmässig wird dieses nicht mehr eingeblendet und ich möchte die Einblendung wieder aktivieren.

Gruß Moritz

du delegierst doch “Subdomain Recipient Management” bereits auf den genannten Server scope via:
Get-ManagementRoleAssignment -RoleAssignee “Subdomain Recipient Management” | Set-ManagementRoleAssignment -CustomConfigWriteScope “Sub Scope”

zu b) bzw. c):

Der ServerRestrictionFilter soll in diesem Fall nur für die Server der Subdomäne Anwendung finden. Alle Änderungen die ein Administrator der Subdomäne macht, sollen sich nur auf die Server der Subdomäne auswirken.
Eine Einschränkung auf Recipients in der Subdomäne kommt in Teil2.

Viele Grüße aus Karlsruhe
Moritz Baer

die commands enthalten Fehler:
a) es muss $RoleGroup.Roles sein mit “RoleGroup.Roles” wäre es ein TextString
b) Der ServerRestrictionFilter {FQDN -like “*.sub.test.local*”} ist für Recipients nicht anwendbar
hier braucht man einen weiteren scope:
New-ManagementScope -Name “Sub Recipients” -RecipientRoot “sub.test.local” -RecipientRestrictionfilter {DistinguishedName -ne $null}
c) Ein Scope für Recipient Objekte muss dann als CustomRecipientWriteScope und nicht als CustomConfigWriteScope vergeben werden.
Get-ManagementRoleAssignment -RoleAssignee “Subdomain Recipient Management” | Set-ManagementRoleAssignment -CustomRecipientWriteScope “Sub Recipients”

Gruß
Thorsten

Ich hab zusätzlich noch auf der Tabelle tbUpdate einen Trigger gesetzt, der das Feld IsLocallyPublished von 1 auf 0 setzt.

USE SUSDB
GO

if (@IsLocallyPublished = 0)
begin
UPDATE [tbUpdate] SET [IsLocallyPublished]=0 WHERE [LocalUpdateID]=@LocalUpdateID
end
GO

Viele Grüße
Moritz Baer

danke für deine Antwort. Zu der Frage nach den Verteilungsgruppen: Leider bietet der WSUS diese Funktionalität nicht, solange die Gruppenstruktur aber nicht zu komplex ist lässt sich dies aber meiner Meinung nach gut über WSUS-Gruppen regeln. Für größere und komplexere Umgebungen bietet sich dann der Einsatz des System Center Configuration Manager (SCOM) oder ähnlicher Softwareverteilungssysteme an. Diese sind jedoch teilweise mit recht hohen Lizenzkosten verbunden, bieten aber eine deutlich erweiterte Funktionalität. Des WSUS ist hier eher als Lösung für kleine Umgebungen zu sehen, für welche sich der Einsatz eines zusätzlichen Systems zur Softwareverteilung nicht lohnt. Gezielte Deinstallation lässt sich nur über die Erstellung eines “Deinstallations-Pakets”, sprich einem Pakete welches das Setupprogramm mit den entsprechenden Parametern zur Deinstallation aufruft, möglich. Dieses Problem ist auch bei der Installation über Startupskripte vorhanden. Auch hier können spezielle Softwareverteilungssysteme wie beispielsweise der SCOM eine deutlich erweiterte Funktionalität bieten.
Größtes Problem beim Einsatz von Startup-/Logonskripten ist meiner Erfahrung nach die Unübersichtlichkeit und damit sehr schwierige Fehlersuche. Auch sind im Falle von Änderungen an der Umgebung teilweise sehr komplexe Anpassungen der Skripte notwendig. Inzwischen lassen sich fast alle Aufgaben, welche früher mit Startup-/Logonskripten lösen ließen per Gruppenrichtlinien deutlich komfortabler und sicherer erledigen (z.B. Druckerverteilung, Zuweisung von Netzwerklaufwerken, Setzen von Registry-Keys etc.).

Viele Grüße aus Kalrsruhe
Florian Raichle

danke für den Beitrag!
Der Tip mit den Sicherheitseinstellungen über den Registry-Editor der ntuser.dat war mir neu. Ist dies eine Empfehlung von Microsoft? (Link-Angabe?)
Ist die beschriebene Vorgehensweise eine Alternative zur Umbenennung von ntuser.dat in ntuser.man?

Gruß