Veröffentlicht in Windows Server 2008

SBS 2008 – SharePoint-Datenbank-Protokolldatei wird groß

Die Protokolldatei von Windows SharePoint Services 3.0 (WSS) kann auf einer Standardinstallation von Windows Small Business Server 2008 (Windows SBS) auf eine große Größe anwachsen.

Dies wird, wenn die Datenbank so konfiguriert ist, dass die Standardeinstellung der vollständigen Wiederherstellungsmodus verwenden und in der Datenbank zahlreiche Transaktionen protokolliert wurden haben.

Microsoft Fix it 50682

Manuelle Lösung:

1. Öffnen Sie Notepad und kopieren und fügen Sie den folgenden Text in den Editor. Speichern Sie die Datei als c:\logshrink.sql

2. Kopieren Sie und fügen Sie den folgenden Text in Editor. Speichern Sie die Datei als c:\logshrink.sql
DECLARE @ ConfigDBLog vom Datentyp varchar(255).
DECLARE @ ConfigDBCmd vom Datentyp varchar(255).
Wählen Sie @ ConfigDB = Name von sys.databases, wobei Name like‘ SharePoint_Config_‘;
Legen Sie @ ConfigDBCmd = ‚ Datenbank sichern [‚ + RTRIM(@ConfigDB) + ‚] auf der Festplatte =“ C:\windows\temp\before.bkf“ ‚;
Execute(@ConfigDBCmd);
Legen Sie @ ConfigDBCmd = ‚ verwenden [‚ + RTRIM(@COnfigDB) + ‚]‘;
Execute(@ConfigDBCmd);
Legen Sie @ ConfigDBCmd = ‚ BACKUP LOG [‚ + RTRIM(@ConfigDB) + ‚] WITH TRUNCATE_ONLY‘;
Execute(@ConfigDBCmd);
Legen Sie @ ConfigDBCmd = ‚ verwenden [‚ + RTRIM(@COnfigDB) + ‚]‘;
Execute(@ConfigDBCmd);
Wählen Sie @ ConfigDBLog = Name von der Katalogsicht sys. database_files, wobei Name wie ‚Sharepoint_config % _log‘;
Legen Sie @ ConfigDBCmd = ‚ verwenden [‚ + RTRIM(@ConfigDB) + ‚] DBCC SHRINKFILE([‚ + RTRIM(@ConfigDB) + ‚_log],1)‘;
Execute(@ConfigDBCmd);
Legen Sie @ ConfigDBCmd = ‚ Datenbank sichern [‚ + RTRIM(@ConfigDB) + ‚] auf der Festplatte =“ C:\windows\temp\after.bkf“ ‚;
Execute(@ConfigDBCmd);
go

2. Öffnen Sie eine Eingabeaufforderung mit erhöhten Rechten, und führen Sie den folgenden Befehl aus:

Sqlcmd-s \\.\pipe\mssql$microsoft##ssee\sql\query-e -i c:\logshrink.sql


Dieses Skript erstellt zwei Sicherungsdateien (before.bkf und after.bkf) in C:\windows\temp.

 

Quelle: http://support2.microsoft.com/kb/2000544/de

 

Veröffentlicht in Betriebssysteme, Windows Server 2003, Windows Server 2008, Windows Server 2012

Filtern von Gruppenrichtlinien anhand von Benutzergruppen, WMI und Zielgruppenadressierung

Gruppenrichtlinien werden nur von einem Benutzer- oder einem Computerobjekt übernommen. Sicherheitsgruppen können als Filter verwendet werden, um unterschiedliche Richtlinien etwas dynamischer gestaltet aufgrund Mitgliedschaft eines Benutzers oder eines Computers dieser Gruppe anzuwenden.

  • Die OU/Domäne/Site, der Einhängepunkt der Richtlinien und von da „nach unten“
  • Sicherheitsfilterung, einer Sicherheitsgruppe oder einem einzelnen Objekt wird das Recht „übernehmen“ zugeteilt.
  • WMI Queries, eine Abfrage meistens die Hardware oder das Betriebsystem betreffend, das eine Konfiguration abfragt
  • ILT – Item Level Targeting, Zielgruppenadressierung auf Elementebene, innerhalb einer Richtlinie eine Filterung einer einzelnen Einstellung.

Die OU als Filter

Diese definiert den Verwaltungsbereich einer Richtlinie, den sogenannten Scope of Management (SOM). Jedes Objekt das die Richtlinie übernehmen soll, muss im Verwaltungsbereich der Richtlinien liegen. Es ist genau wie im Dateisystem. Soll eine Datei dieselben Berchtigungen anwenden, wie die, die auf D:\Daten definiert sind, dann muss die Datei in dem Ordner oder einem Ordner darunter liegen. In D:\Vertrieb können anderen Rechte definiert sein, eine Datei unterhalb von D:\Daten wird nicht von diesen Rechten betroffen sein. Wird eine Datei von D:\Daten nach D:\Vertrieb verlegt, dann sollten die Rechte geändert werden. Wenn man möchte, daß für D:\Daten und D:\Vertrieb dieselben Rechte gelten, dann müssen  die Rechte 2mal,  auf beiden Ordner gesetzt werden. Oder man definiert die Rechte schon auf D:\, einer „Treppenstufe“ darüber.
Die OU ist als Filter eher eine grobe Zuordnung, da ein Objekt nur in einer OU liegen kann. Es gibt für übergreifende Regeln nur bedingt Möglichkeiten, diese Ausnahmen oder Sonderwünsche mit einer OU abzubilden. Diese Ausnahmen sind eher genereller Natur, also fast schon keine Ausnahmen mehr.

Die Sicherheitsgruppe als Filter

Wenn das Objekt im Verwaltungsbereich der Richtlinie liegt, dann muss es das Recht „übernehmen“ haben, um die Richtlinien auch anwenden zu dürfen. „Lesen“ alleine reicht nicht aus. „Übernehmen“ ist ein eigenes Recht, das es im AD genau für diesen Zeck gibt.

Ihr seht die Gruppen, die das Recht haben die Richtlinie zu übernehmen auf dem Reiter „Bereich“ im mittleren Abschnitt „Sicherheitsfilterung“. Ich empfehle euch einen kleinem Umweg über den Reiter „Delegation“ dann unten rechts auf die Schaltfläche „Erweitert“. Da wird es wesentlich deutlicher, was man tut und man kann an dieser Stelle im Gegensatz zum Reiter Bereich sogar mit „Verweigern“ arbeiten, was ich aber sehr sparsam als Recht verwenden würde.


(klick-vergrößern)

Ganz wichtig ist jetzt bei der Filterung, das die Reihenfolge der Richtlinien stimmt, wenn  beide Richtlinien auf derselben Ebene definiert sind. Über die Schaltflächen kann diese Reihenfolge manipuliert werden und die Richtlinien können „von oben nach unten“ sortiert werden. Das Konzept basiert auf LAST WRITER WINS. Der letzte, der den Wert schreibt bestimmt den Wert. Leider ist die GPMC dieser Regel in der Ansicht auf den ersten Blick nicht gefolgt. Der Entwickler hat es wie im Sport definiert: Wer auf Platz 1 (also ganz oben) steht gewinnt und diese Richtlinie bestimmt somit den Wert. Das bedeutet aber leider, das der „Letzte“ in der gedachten Reihenfolge nich „unten“ erscheint, sondern eben „oben“.
Die Liste muss von unten nach oben betrachtet werden um die Ablaufreihenfolge zu sehen. Wie gesagt: Es ist wie im Sport.


(klick-vergrößern)

Beispiel:
In meinem Beispiel geht es wie immer um den Bildschirmschoner. Dieser soll für alle gelten und nach 10 Minuten mit Kennwortschutz aktiviert sein. Es gibt aber in meinem Unternehmen immer wieder Situationen bei denen der Bildschirmschoner nicht angewendet werden darf oder er einfach nur stört: Produktionsmaschinen, Überwachungsmonitore, Leitsysteme, Präsentationsmaschinen, Wegweiser usw. Diese Anwender stecke ich in eine eigene Sicherheitsgruppe „BS_Ausnahme“ und diese kriegen keinen Bildschirmschoner.

Lösung a)
Ich verweigere das „Übernehmen“ für die Gruppe „BS_Ausnahme“ auf der GPO „B_Bildschirmschoner 10 Minuten aktiv“. Geht prima, aber Ich mag verweigern nicht … man sieht es nicht in der Oberfläche und es setzt sich immer durch, was zu beides zu Folgefehlern führen kann.

Lösung b)
Ich arbeite mit 2 Richtlinien. Jeder bekommt einen Bildschirmschoner, aber ich schalte ihn nachträglich über die 2te Regel wieder aus, wenn ich Mitglied der Sicherheitsgruppe „BS_Ausnahme“ bin. Das gefällt mir persönlich besser.

Todo:

  • Erstelle und Verlinke die Richtlinie „B_Bildschirmschoner 10 Minuten aktiv“
  • Erstelle und Verlinke die Richtlinie „AUSN-SEC-B_Bildschirmschoner aus“ an derselben OU
  • Auf der OU -> Reiter „Verknüpfte Gruppenrichtlinienobjekte“ -> Sortiere die „AUSN-SEC-B_Bildschirmschoner aus“  nach „oben“ damit sie gewinnt
  • Auf der GPO „AUSN-SEC-B_Bildschirmschoner aus“ – Reiter „Delegation“ -> Schaltfläche „Erweitert“
  • Benutzergruppe „Authentifizierte Benutzer“ auswählen -> Checkbox „Zulassen“ bei „Übernehmen“ entfernen
  • Benutzergruppe „BS_Ausnahme“ hinzufügen -> Checkbox „Zulassen“ bei „Übernehmen“ setzen

Im Bereich der Sicherheitsfilterung seht ihr jetzt nur noch die „BS_Ausnahme“ und die „Authentifizierten Benutzer“ stehen nicht mehr auf der Liste.


(klick-vergrößern)

WMI als Filter

Wenn das Objekt im Verwaltungsbereich der Richtlinie liegt und es das Recht hat, die Richtlinien zu übernehmen, dann kann die Übernahme noch einmal aufgrund einer Hardwarevorraussetzung, Betriebsystemkondition oder jedes anderen beliebigen Werts, der über WMI zu finden ist gefiltert werden.

  • Der Filter muss immer TRUE ergeben, wenn die Richtlinien übernommen werden soll, wenn es also ein bestimmter Wert explizit nicht sein darf, dann muss ich die Query entsprechend formulieren.
  • Queries können mit „(“ „)“ ineinander verschachtelt werden und mit AND und/oder OR verknüpft sein.
  • Mehrere Queries in demselben WMI Filter in der GPMC sind immer mit AND verknüpft, es gibt leider kein OR

Die größte Schwierigkeit ist nun: Wie ist die Syntax und wo kriege ich die Werte her

Die einfachste Antwort: Verwendet den WMICodeCreator von Microsoft. Uralt, aber gut.

WMI Code Creator v1.0
http://www.microsoft.com/en-us/download/details.aspx?id=8572

Todo:

  • im WMICodeCreator: root\CIMv2 nehmen, Class auswählen, nach Properties suchen, den Value anklicken und die Zeile mit dem SELECT Befehl kopieren
  • GPMC öffnen -> Knoten WMI Filter -> Neu: Neuer WMI mit Namen und Kommentar angeben
  • Abfrage hinzufügen -> die SELECT Zeile einfügen
  • Der WMI Filter steht nun auf jedem Richtlinien Objekt im Dropdown der WMI Filterung zur Verfügung


(klick-vergrößern)

Ein paar klassische WMI Abfragen:

  • Es ist ein Windows XP oder 2003
    SELECT * FROM Win32_OperatingSystem WHERE BuildNumber < ‚4000‘ 
  • Es ist ein Windows Vista oder höher
    SELECT * FROM Win32_OperatingSystem WHERE BuildNumber > ‚5000‘
  • Es ist eine Workstation (ProductType = 1), DomainController (=2) oder MemberServer (=3), OS unabhängig).
    SELECT * FROM Win32_OperatingSystem WHERE ProductType = ‚1‘
  • 32 Bit oder 64 Bit adressieren:
    SELECT * FROM Win32_OperatingSystem WHERE OSArchitecture = ’32-Bit‘
    SELECT * FROM Win32_OperatingSystem WHERE OSArchitecture = ’64-Bit‘
  • Die Kombination: Eine deutsche oder englische Windows 7 Workstation mit 64-Bit
    SELECT * FROM Win32_OperatingSystem WHERE BuildNumber > ‚5000‘ AND ProductType = ‚1‘ AND OSArchitecture = ’64-Bit‘ AND (CountryCode = ’49‘ OR CountryCode = ’01‘)
  • Der Compuername beginnt mit „VPC-*“
    SELECT * FROM Win32_ComputerSystem WHERE Name LIKE ‚vpc-%‘
  • Es ist ein Deutsches Betriebsystem
    SELECT * FROM Win32_OperatingSystem WHERE CountryCode = ’49‘
  • Der Benutzer verwendet ein deutsches Tastaturlayout:
    SELECT * FROM Win32_Keyboard WHERE Layout = ‚00000407‘
  • Es ist mindesten der IE8 installiert, egal ob auf Windows XP oder Windows 7
    SELECT * FROM CIM_DataFile WHERE Filename = ‚iexplore‘ AND version > ‚8.0‘ AND (path = ‚\\programme\\Internet Explorer\\‘ OR path = ‚\\program files\\Internet Explorer\\‘ )
  • Das System hat eine Intel Netzwerkarte:
    SELECT * FROM Win32_NetworkAdapter WHERE MACAddress LIKE ’00:13:E8%‘

ILT – Item Level Targeting – Zielgruppenadressierung auf Elementebene als Filter

Das ist eine neue Funktion, die nur innerhalb der Group Policy Preferences existiert und die Möglichkeit bietet innerhalb einer einzige Richtlinie PRO Eintrag einer Preference Filter über WMI und andere Techniken zu setzen. Die Client Side Extension der GPPs, kennt schon diverse Eckdaten des Systems und kann sie mit eigenen Variablen oder direkten Abfragen adressieren und abfragen.

Todo:

  • Über den Reiter „Geimsam“ -> Checkbox „Zielgruppenadressierung auf Elemetebene“


(klick-vergrößern)

Hier können nicht nur einzelne Abfragen stattfinden, z.B.: nach der Sicherheitsgruppe, sondern es können mehrere Filter mit AND und OR kombiniert werden und mit „IST“ und „IST NICHT“ eingestellt werden, Zusätzlich gibt es noch die Möglichkeit eine Sammlung zu erstellen, Eine Sammlung bietet praktisch eine Klammer „(„“)“ um die definierten Filter, die widerum in Summe auf „IST“ und „IST NICHT“ definiert werden kann. Einzelne Filter und Sammlungen können auch mit „AND“ und „OR“ kombiniert werden. Hier ist praktisch die Ausnahme in der Ausnahme mit einer Ausnahme möglich.

Quelle: http://www.gruppenrichtlinien.de/artikel/filtern-von-gruppenrichtlinien-anhand-von-benutzergruppen-wmi-und-zielgruppenadressierung/
Veröffentlicht in Betriebssysteme, Windows Server 2003, Windows Server 2008, Windows Server 2012

Loopbackverarbeitungsmodus – Loopback Processing Mode

Loopback processing of Group Policy
http://support.microsoft.com/kb/231287/en-us

Die Situation: Man möchte, daß der Benutzer spezielle Einstellungen, abhängig vom Computer an dem er sich anmeldet, übernimmt. Klassische Beispiele sind in dem Fall: Terminal (Remote Desktop) Server und Notebooks.

Bei einem TS möchte man in der Regel, daß der Benutzer wesentlich restriktiver gehandhabt wird, als wenn er sich an seiner Workstation anmeldet und bei Notebooks ist es oftmals genau  das Gegenteil: Der Benutzer darf mehr, als an seiner festen Workstation. Am Ende kommt es auf die gleiche Situation hinaus. Ich benötige Richtlinien abhängig vom Computer.

Das könnte man heute prima mit einem WMI Filter erreichen, der auf einer an der Benutzer OU verlinkten GPO eingesetzt wird und zB den dnsHostName abfragt. Dummerweise gab es diesen Filter unter Windows 2000 nicht. Deswegen gibt es den Loopback.

Die Herausforderung:
Ich muss die Richtlinie irgendwie auf das Computerkonto anwenden? Aber der Computer ignoriert den Anteil der Benutzerkonfiguration einer Richtlinie, da er ja schliesslich ein Computerobjekt ist und kein Benutzer. Ebenfalls, ist dem anmeldenden Benutzer die Benutzerkonfiguration einer Richtlinien auf dem Computerobjekt egal, da der Benutzer die Computerkonfiguration garnicht liest, und damit am Ende die Richtlinie, nicht übernehmen kann. Es kommt noch hinzu, daß der Benutzer meistens nicht in der OU des Computers steht, damit nicht im Verwaltungsbereich der Richtlinie ist und er somit die GPO generell nicht anwenden kann.

Schauen wir uns die normale Verarbeitung von Richtlinien an.

  • OU „Terminal Server“, darin enthalten der Computer
  • verlinktes GPObjekt „TerminalServer Einschränkungen“
    darin enthalten konfigurierte Einstellungen im Bereich Computer~ und Benutzerkonfiguration
  • OU „Meine Benutzer“, darin enthalten alle Benutzerkonten
  • verlinktes GPObjekt „Meine Std. Firmenvorgaben“
    nur Einstellungen im Bereich Benutzerkonfiguration

Ablauf:

  1. Der Computer aus der OU „Terminal Server“ liest den Anteil Computerkonfiguration der Richtlinie „TerminalServer Einschränkungen“ .
  2. Der Computer kann als Objekt keine Benutzereinstellungen übernehmen.
  3. Der Benutzer aus der OU „Meine Firma“ liest den Anteil Benutzerkonfiguration der Richtlinie „Meine Std. Firmenvorgaben“. Fertig

Jetzt aktiviert man den Loopbackverarbeitungsmodus auf einer beliebigen Richtlinie, die auf den Computer wirkt. Sie sollte als eigene Richtlinie integriert werden, mit nur der einen Policy aktivert. Diese Objekt kann man dann überall dort verlinken, wo es einen Loop geben soll. Die Eigenschaft des Loopback gilt ab der nächsten Übernahme und dem anschliessendem Neustart für alle Richtlinien. Nicht nur für eine spezielle.

Wir erweitern das Beispiel um eine weitere Richtlinie: „Loopbackverarbeitungsmodus aktiviert“

Computerkonfiguration \ Administrative Vorlagen \ System \ Gruppenrichtlinien
Loopbackverarbeitungsmodus für Benutzergruppenrichtlinie = aktiviert

  • OU „Terminal Server“, darin enthalten der Computer
  • verlinktes GPObjekt „Loopbackverarbeitungsmodus aktiviert“
  • verlinktes GPObjekt „TerminalServer Einschränkungen“
  • OU „Meine Benutzer“, darin enthalten alle Benutzerkonten
  • verlinktes GPObjekt „Meine Std. Firmenvorgaben“

Neuer Ablauf:

  1. Der Computer aus der OU „Terminal Server“ liest den Anteil Computerkonfiguration der Richtlinie „TerminalServer Einschränkungen“.
  2. Der Computer aus der OU „Terminal Server“ liest den Anteil Computerkonfiguration der Richtlinie „Loopbackverarbeitungsmodus aktiviert“.
  3. Der Benutzer aus der OU „Meine Firma“ liest den Anteil Benutzerkonfiguration der Richtlinie „Meine Std. Firmenvorgaben“
  4. Der Benutzer aus der OU „Meine Firma“ liest den Anteil Benutzerkonfiguration der Richtlinie „TerminalServer Einschränkungen“

Durch den Loop wird eine Schleife (Loopback = Salto rückwärts) bei der Übernahme erzeugt, die den Prozess der Benutzeranmeldung dazu bringt die Liste der Richtlinien des Computerobjekts durchzuschauen. Da nur in diesem speziellen Fall das Benutzerobjekt die Richtlinien des Computers liest und jetzt Benutzerkonfigurationen findet, die es lesen und übernehmen kann, funktioniert der Trick.

In jedem anderen Fall würde kein Benutzer Computerkonfigurationen lesen und kein Computer Benutzerkonfigurationen. Da jedes Mal das „falsche“ Ziel angesprochen wird. Durch diese Manipulation können sich natürlich Probleme ergeben, da jetzt mehr Richtlinien auf das Benutzerobjekt angewendet werden, als vorher. Dadurch kann es wieder zu „Phänomenen“ kommen, daß bestimmte Richtlinieneinstellungen sich nicht durchsetzen etc.
Der Ablauf der Vererbung muss in diesem Fall noch einmal genau kontrolliert werden, um Fehler zu finden, in denen sich 2 Einstellungen zB durch den normalen Überschreibungsvorgang der zuletzt angewendeten Richtlinie überstimmen oder ins Gegenteil gesetzt werden.

Der Loopbackverarbeitungsmodus kennt 2 Konfigurationseinstellungen: Zusammenführen (Merge) und Ersetzen (Replace)

Im ersten Fall werden alle vorhandenen Benutzerrichtlinien des Benutzerobjekts mit denen des Computerobjekts zusammengeführt, wobei die Einstellungen aus der Benutzerkonfiguration der Computerrichtlinie, die Einstellungen des Benutzerobjekts überschreiben können, wenn sie sich widersprechen. LAST WRITER WINS!

Im Replace Modus, werden alle Benutzereinstellungen des Benutzerobjekts ignoriert und verworfen und es kommen nur die Einstellungen der Benutzerkonfiguration des Computerobjekts zum Einsatz.

Ich persönlich habe lange Zeit den „Ersetzen“ Modus favorisiert, da ich im Falle eines Falles nur eine Stelle (die Einstellungen des Computers) kontrollieren muss um a) genau zu wissen, was beim Benutzer ankommt und b) die Fehlersuche zu reduzieren und damit c) den Ablauf insgesamt vereinfache.
Der Nachteil ist, und das ist der Grund, warum ich mittlerweile „Zusammenführen“ mag, daß ich viele  Einstellungen erneut definieren muss, die schon beim Benutzer konfiguriert sind, da sie ja beim „Ersetzen“  verworfen werden und fehlen.

Quelle: http://www.gruppenrichtlinien.de/artikel/loopbackverarbeitungsmodus-loopback-processing-mode/