Markus Bäker

In SCCM 2012 ist der Forefront Endpoint Protection (FEP) Client noch stärker im Configuration Manager (SCCM) integriert worden. Daher kümmert sich auch der SCCM Client um das Einspielen der FEP Policy, die als XML File vorliegt.

In einigen Fällen scheitert dies aber und die Clients erhalten in der SCCM Konsole im Bereich FEP den Status fehlerhaft.

Bei der ersten Analyse hilft das Log EndpointProtectionAgent.log auf dem Client (%systemroot%\ccm\logs). In diesem Fall war folgende Fehlermeldung zu lesen:

<![LOG[Create Process Command line: "c:\Program Files\Microsoft Security Client\\ConfigSecurityPolicy.exe" "C:\WINDOWS\CCM\EPAMPolicy.xml".]LOG]!><time=”09:44:00.851-60″ date=”01-28-2013″ component=”EndpointProtectionAgent” context=”" type=”1″ thread=”4452″ file=”epagentutil.cpp:607″>
<![LOG[Failed to apply the policy C:\WINDOWS\CCM\EPAMPolicy.xml with error (0x80004005).]LOG]!><time=”09:44:00.916-60″ date=”01-28-2013″ component=”EndpointProtectionAgent” context=”" type=”3″ thread=”4452″ file=”epagentimpl.cpp:647″>
<![LOG[Save new policy state 2 to registry SOFTWARE\Microsoft\CCM\EPAgent\PolicyApplicationState]LOG]!><time=”09:44:00.966-60″ date=”01-28-2013″ component=”EndpointProtectionAgent” context=”" type=”1″ thread=”4452″ file=”epagentimpl.cpp:267″>

<![LOG[State 2 and ErrorCode -2147467259 and ErrorMsg Failed to open the local machine Group Policy and PolicyName Antimalware Policy and GroupResolveResultHash A3B029F0133B36CFF682D8CD9BB02D6952B1C9E3 is NOT changed.]LOG]!><time=”09:44:00.967-60″ date=”01-28-2013″ component=”EndpointProtectionAgent” context=”" type=”1″ thread=”4452″ file=”epagentimpl.cpp:339″>

Interessant ist die letzte Zeile: “State 2 and ErrorCode -2147467259 and ErrorMsg Failed to open the local machine Group Policy and PolicyName Antimalware Policy and GroupResolveResultHash”. Eine kurze Recherche im Web ergibt, dass dieser Fehler mit einem Berechtigungsproblem auf die lokalen Gruppenrichtliniendateien zusammenhängen kann, d.h. eine eingerichtete Lokale Gruppenrichtlinieneinstellung hat sich verharkt, so dass das lokale System keinen Schreibzugriff mehr hat. Ein einfaches Löschen dieser Datei (c:\windows\system32\GroupPolicy\Machine\registry.pol) behebt das Problem. Der Ordner GroupPolicy ist im Allgemeinen versteckt.

Möchte man dies remote ausführen, so bietet sich folgende kleine Batchdatei an:

@echo off
call %~dp0findip.cmd %~1
if %ip%.==. goto fehler
echo PC %1 ist erreichbar.
del \\%1\c$\windows\System32\GroupPolicy\Machine\registry.pol

rem remote start gpupdate
psexec \\%1 gpupdate /force

rem update fep policy
SendSchedule.exe {00000000-0000-0000-0000-000000000222} %1

rem update sccm wsus policy
SendSchedule.exe {00000000-0000-0000-0000-000000000108} %1
goto ende

:fehler

echo PC %1 ist nicht erreichbar.

goto ende
:ende

Die Datei benötigt die findip.cmd, die ich bereits in einigen vorhergehenden Batchdateien eingesetzt habe, um zu kontrollieren, ob ein Client online ist. Zusätzlich wird psexec.exe zum Remoteausführen von gpupdate und sendschedule.exe aus dem SCCM Client Toolkit benötigt.

Diese Batchdatei führt folgendes aus:

• Kontrollieren, ob der per Parameter übergebene PC erreichbar ist
• Löschen der lokalen GPO Datei
• Ein Gruppenrichtlinienupdate erzwingen, damit Einstellungen von der Domäne ggfl. korrigiert werden
• Dem SCCM Client mitteilen, dass er die FEP Policy neu einspielen soll
• Dem SCCM Client mitteilen, dass er die WindowsUpdate Einstellungen neu eintragen soll

Hintergrund: Die SCCM Komponenten für das Update Management und FEP benötigen beide Schreibzugriff auf lokale Policies. Dabei werden die Einstellungen in die oben erwähnte registry.pol Datei ablegt. Ist dies nicht möglich so kommt es zu dem oben erwähnten Fehler.

Da ich zu hause einen Windows Home Server (WHS) mit mehreren Clients aber ohne zentrale Profile (da keine Windows Domäne vorhanden ist) einsetze, ist User Environment Virtualization (UE-V) die optimale Ergänzung.

Dazu bin ich folgendermaßen vorgegangen:

Über das Dashboard habe ich ein neue Freigabe namens Settings angelegt. Um mir die Berechtigungsvergabe zu vereinfachen habe ich für alle relevanten Benutzer Read/Write Berechtigungen vergeben.

In einem Unterordner namens Agent liegt darin der Agent mit einem Installationsscript. Parallel zu diesem Ordner existiert ein Ordner Templates, in dem ich die selbsterstellten Vorlagen abgelegt habe.

Im Agent Ordner liegt der komplette Inhalt des heruntergeladenen Installationspakets (der Ordner mit AgentSetup.exe). Zusätzlich existiert die Datei install.cmd zur Einfachen Installation:

"%~dp0agentsetup.exe" /quiet /norestart /l*v "%systemroot%\UE-VAgentInstaller.log" SettingsStoragePath="\\whsserver\settings\%%username%%" SettingsTemplateCatalogPath="\\whsserver\settings\Templates"
call "%~dp0settings.cmd"

Diese Datei führt nach der Installation die zusätzliche Datei settings.cmd aus. Diese Batchdatei ist für den Import der Templates zuständig:

rem reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\UEV\Agent\Configuration /v DisableOfflineSupport /t REG_DWORD /d 1 /f
powershell -Command "set-executionpolicy remoteSigned"
copy "%~dp0importall.ps1" "%temp%\importall.ps1"
powershell "%temp%\importall.ps1"
pause

Der Import erfolgt über Powershell. Da Powershell standardmäßig keine Scripts ausführt, wird zuerst die Execution Policy angepasst. Danach wird das Powershell Script lokal kopiert und ausgeführt. Das Powershell Script ist sehr übersichtlich:

Import-module Microsoft.UEV.commands
get-childitem -Recurse \\whsserver\settings\templates\*.xml  | ForEach-Object { $_.fullname | Register-UevTemplate }
get-childitem -Recurse \\whsserver\settings\templates\*.xml  | ForEach-Object { $_.fullname | Update-UevTemplate }

Zuerst registriert es alle Templates die in dem Templates Ordner vorhanden sind. Sollte das Template schon registriert sein, so wird es automatisch ignoriert. Danach werden alle Templates aktualisiert, d.h. ist ein Templates schon registriert worden aber es liegt eine neuere Version vor, so wird es in diesem Schritt auf die neue Version gebracht. Somit ist das settigns.cmd Script auch für spätere Templateaktualisierungen verwendbar.

SCCM 2007 setzt (noch) 32bit Agenten ein. Daher wird auch ein Programm zuerst einmal im 32bit Kontext ausgeführt und bekommt daher über die Redirects primär Zugriff auf das syswow64 Verzeichnis. Startet man ein regedit, so wird die 32bit Variante gestartet. Es gibt Situationen, in denen man auf jeden Fall die OS native Variante starten möchte, d.h. auf einem x64 die 64bittige und analog auf einem x86 die 32bit. Dazu kann man in einer Batchdatei überprüfen ob bestimmte Kriterien erfüllt sind, oder man verwendet direkt einen (auch mir vor kurzem ) eher unbekannten Alias: sysnative.

So kann man einen Aufruf von %windir%\system32\regedit.exe ersetzen durch %windir%\sysnative\regedit.exe. Im WOW64 Kontext wird dieser Alias erkannt und durch den Verweis auf die 64bit Variante ersetzt.

Details dazu sind auch in der MSDN von Microsoft zu finden: http://msdn.microsoft.com/en-us/library/aa384187%28v=vs.85%29.aspx

Im letzten Teil wurde eine Batchdatei zur Erzeugung von CCR Dateien vorgestellt. Möchte man direkt eine komplette Collection installieren lassen, dann läßt sich dies wieder einfach mit der getcomputer.vbs Datei umsetzen:

makeccrall.cmd:

for /F %%i in ('cscript.exe //NOLOGO %~dp0getcomputer.vbs %1 smsserver sitecode') do call %~dp0makeccr.bat %%i

(auch hier wieder smsserver und sitecode durch die korrekten Daten ersetzen)

Alterntiv möchte man eventuell die Installation erzwingen, d.h. egal ob ein Client vorhanden ist oder nicht soll dieser auf jeden Fall installiert und gegebenenfalls repariert werden. Dazu muss in der CCR Datei ein zusätzlicher Parameter angegeben werden. Hierfür ist die Batchdatei forcemakeccr.cmd zuständig:

Read more…

Im vierten Teil wird eine Batchdatei zum Remoterollout des SCCM Clients vorgestellt. Dazu wird ein Client Configuration Request (CCR) erzeugt und in das entsprechende SCCM Verzeichnis abgelegt. Auf dieses reagiert der Server und versucht den Client remote zu installieren (ähnlich des Clientrollouts über die MMC Konsole).

Auch diese Batchdatei benötigt wieder die Datei findip.bat aus dem ersten Teil.

@echo off
set PC=%1
set sitecode=SMS
set siteserver=SMSSERVER

if .%PC%==. set /p PC=Enter Computer Name to install SMS Client:
call %~dp0findip.bat %PC%
if %ip%.==. goto ende

:testdomain
echo Computer:%PC%

:weiter
set output="%temp%\%PC%.ccr"

echo [NT Client Configuration Request]>%output%
echo   Client Type=1>>%output%
echo   Machine Name=%PC%>>%output%

copy %output% \\%siteserver%\sms_%sitecode%\inboxes\ccr.box\
dir  \\%siteserver%\sms_%sitecode%\inboxes\ccr.box

del %output%

:ende
set output=
set ip=
set d=

In der dritten und vierten Zeile muss der jeweilige Siteserver und der SCCM Sitecode angegeben werden. Aufgerufen wird die Batchdatei wie üblich mit dem Ziel-PC Name als Parameter.

Vor über einem Jahr habe ich angefangen meine SCCM Hilfsscripte hier zu veröffentlichen. Da ich noch eine ganze Reihe von diesen Batchdateien habe, kommen jetzt noch einige weitere Posts zu diesem Thema.

Im Teil 2 wurde die Batch und vbs Datei vorgestellt, um auf eine Reihe von Clients die Hardwareinventur anzustossen.

Dies geht genauso mit dem Computer Policy Update:

startmachineupdate.cmd

@echo off
set PC=%1
if .%PC%==. set /p PC=Enter Computer Name to start HINV:
call %~dp0findip.bat %PC%
if %ip%.==. goto fehler
echo Start Machine Policy Update %PC%
cscript.exe //Nologo %~dp0sendsched.vbs {00000000-0000-0000-0000-000000000021}  %PC%
goto ende
:fehler
echo Abbruch, da Rechner %PC% auf ping nicht antwortet.
:ende
set ip=

und die dazugehörige startmachineupdateall.cmd:

for /F %%i in ('cscript.exe //NOLOGO %~dp0getcomputer.vbs %1 smsserver sitename') do call %~dp0startmachineupdate.cmd %%i

Benötigt dazu wird findip.bat und getcomputer.vbs aus Teil 1 bzw. Teil 2.

Kleine Batchfiles sind immer wieder praktisch um schnell kleinere Probleme zu lösen. Diesmal stelle ich ein paar Dateien vor, die zum Erstellen und Kopieren verschiedener Dateien eingesetzt werden können. Dies ist z.B. Hilfreich wenn man die Transfergeschwindigkeit testen möchte. Das eingesetzte Robocopy zeigt am Ende die durchschnittliche Geschwindigkeit an.

Zuerst zwei Batchdateien, um eine Menge kleiner Dateien bzw. eine große Datei zu generieren:

2000 kleine 30 KByte Dateien erzeugen:

Read more…

Dadurch, dass der PDFCrator keinen unsignierten Druckertreiber installiert, ist eine Paketierung auch unter Windows 7 x64 relativ einfach. Trotzdem ist die integrierte Yahoo/PDFForge Toolbar bei der Installation hartnäckig und lässt sich erst nach einigen Versuchen ausklammern. Die hier vorgeschlagene Vorgehensweise wurde mit der PDFCreator Version 1.2.2 erfolgreich getestet.

Zuerst verwende ich wie üblich eine install.cmd für den Aufruf:

rem http://de.pdfforge.org/forum/open-discussion/6236-silent-install-without-toolbar
"%~dp0PDFCreator-1_2_2_setup.exe" /verysilent /norestart /sp /LOADINF="%~dp0pdf.ini" /forceinstall

Sie startet das Setup mit den notwendigen Parametern für eine automatische Installation. Die eigentlichen Einstellungen sind in der pdf.ini Datei hinterlegt:

[Setup]
Lang=german
Dir=C:\Program Files (x86)\PDFCreator
Group=PDFCreator
NoIcons=0
SetupType=custom
Components=program,ghostscript,images2pdf,helpfiles,helpfiles\german,languages,languages\english,languages\german
Tasks=winexplorer
Toolbar=0
DontUseYahooSearch=0

Relevant für das Unterdrücken der Tollbars sind die letzten beiden Punkte: Toolbar=0 und DontUseYahooSearch, um den Versuch der Veränderung der Default Suche im IE zu verhindern.

Wie versprochen geht es weiter mit der Automatisierung von Enteo durch Powershell. In diesem Blog Eintrag nehme ich mir die Funktion für das Aufwecken eines PCs vor. Leider funktioniert hier die WoL Funktion von Enteo nicht immer. Das liegt u.a. daran, dass bei einem neuen PC nicht alle Informationen vorliegen. In den meisten Netzen wird ein normales WoL Paket (ein Broadcast Paket) nicht an alle Subnetze verteilt. Der Enteo Server und der zu weckende Client sind im Allgemeinen in unterschiedlichen Subnetzen beheimatet. Daher muss mit einem directed Broadcast gearbeitet werden. Dazu wird das Broadcast Paket direkt an die Broadcast Adresse des Zielsubnetzes geschickt. Dazu ist aber die IP Adresse und die Subnetzmaske zur Ermittlung der Broadcast Adresse notwendig. Diese Information liegt Enteo nicht immer vor und ich habe noch keinen Weg gefunden, diese Info beim Erstellen des Computerkontos mitzugeben.

Read more…

Bei einigen Automatisierungen ist es notwendig den Profilpfad eines Benutzers auszulesen und einen eventuellen DFS Pfad in einen physikalischen Pfad aufzulösen.

Hierfür habe ich eine kleine Batch-Datei geschrieben:

@echo off
set samaccountname=%~1
for /f "tokens=* usebackq" %%a in (`AdFind.exe -f "samaccountname=%samaccountname%" profilePath /list`) do (
set profilePath=%%a
)

for /f "delims=<> usebackq tokens=1,2,3,4,5" %%a in (`dfsutil diag viewdfspath %profilepath%`) do (
     if NOT %%e.==. set profilePath=%%e
)

echo %profilePath%

Der Profilpfad wird in Zeile 3 mit Hilfe von adfind anhand des Benutzernamens ermittelt, per for ausgewertet und an eine Umgebungsvariable übergeben.
Diese wird in Zeile 7 an dfsutil übergeben, dass mit dem Befehl diag den physikalischen Pfad anzeigt (ermittelt mit dem aktuellen Standort). Die Ausgabe wird erneut mittels for ausgewertet, wobei die Zeilen an den Größer- und Kleinerzeichen getrennt werden. An fünfter Stelle steht dabei der physikalische Pfad. Handelt es sich bei dem Profilpfad um keinen DFS basierten, dann ist die fünfte Stelle leer und wird daher nicht an die Variable übergeben.

Innerhalb einer anderen Batch-Datei kann diese einfach per call getprofilepath.cmd SAMACCOUNTNAME aufgerufen und die Variable profilePath später weiterverwendet werden.