On friday I had some time to test a solution which I will describe here.

On warnung at the beginning: This current solution is experimental. It will run a Miranda client in the system context and can be a large security hole for your SCOM server!

The first thing I had to to is finding a client which can be controlled by command line or by a SDK. I stumbled upon the command line plugin for Miranda IM. Miranda IM is an open source mutli-protocol instant messaging client. With it you can integrate multiple protocols with plugins.

I created a test ICQ account and a surrounding batch file for miranda:

setlocal

set log="c:\logging.log"
echo. >> %log%
echo starting %date% %time% >> %log%

rem läuft miranda schon?
tasklist | findstr /i miranda32.exe
if %errorlevel%.==0. goto laeuft
echo Starte Miranda im System Kontext >> %log%
start "" "%~dp0miranda32.exe"
echo 10 sec warten...
ping -w 1000 -n 10 128.0.0.1
goto weiter

:laeuft
echo Miranda laeuft schon  >> %log%

:weiter
echo mimcmd message %~1 "%~2" >> %log%
mimcmd message %~1 "%~2">> %log%
endlocal

First it checks if miranda is already running. The command Tasklist is only available in Windows 2008 and later. If it isn’t running it will be startet (has to be in the same directory as the batch file) and the batch waits for 10 seconds. After that it will use the mimcmd command the send the message.

The batch file takes two parameter: 1. the target of the im (can be more than one) 2. The message to send.

To use this batch file you have to create a Command Notification Channel in SCOM:

And here the interesting command line call:

I have used only one target. You can define more then one target by surounding the second parameter (everything between 5 and 49) with qoutes like this: “ICQNumber1 ICQNumber2” or if you want to specify the protocol: “ICQNumber1:ICQ MSNAlias:MSN”. For details look into the readme of the command line plugin.

For sending something to this channel you have to create a subscriber:

And after that you create a normal subscription with the channel and the subscriber.

If everything worded correctly you will see after the first alert in the process list (task manager):

a miranda process in the system context. And in you IM client:

To increase the security you should deactivate and delete all plugins that aren’t necessary. Here is my plugin list:

Outlook:

I will try to start the miranda process with lower privileges but still in the system context.

Released a new Version of the SCOM2Nagios Connector. Changes:

1.5
* NEW: NagiosHost2 and NagiosPort2 in config (fast change upon request)
* BUG: Processings equals instruction hasnt’t worked correctly

This is currently a fast release without much testing. Please add a comment if anything is broken!

Download: SCOM2Nagios (Version 1.5) (167)

Creating the new MP for Discovery:

• Open the Authoring Console (please use the newest on. I have used 6.1.7221.49)
• File –> New and enter the required values
• File –> Management Pack Properties
• Select the tab References –> Add Reference
• Add Reference to Microsoft.Linux.RHEL.4, change the alias to RHEL4 (it’s shorter and easier to use) and a reference to the Microsoft.Unix.Library with the alias Unix. Your reference tab should look like the picture 1 (the picture has another reference to linux but this will be added automaticly with the discovery)
• Switch to Health Model, select Discovery
• new Custom Discovery, name Technidata.Fedora.4.Computer.Discovery
  • Target: Microsoft.Linux.RedHat.Computer
  • Discovered Classes: Add class Microsoft.Linux.RHEL.4.Computer
  • Configuration: Browse… and select: Microsoft.Unix.WSMan.TimedEnumerate.Filtered.MatchesRegularExpression.DiscoveryData and add a module id like discovery
  • Press Edit and enter the xml from part 2 into the editor: replace the text between Configuration> and </Configuration> with the XML text <TargetSystem>[…]</InstanceSettings>
  • Close the editor
  • your discovery tab should look like picture 2
• Do the same with the second xml from part 2
• Your discovery pack is ready to be imported into your test SCOM environment.

Picture 1: Reference Tab

Picture 2: Discovery

Dabei wird zuerst eine Replikation zwischen alten und neuem Fileserver mittels DFSR eingerichtet. DFSR ist trotz des Namens unabhängig von DFS, d.h. hierfür müssen die Fileserver nicht als Ziel eines DFS Zweiges eingerichtet sein.

Sobald die Initiale Replikation abgeschlossen ist, kann der neue Fileserver als weiteres Ziel in den DFS eingehängt werden. Das alte Ziel kann dann entfernt werden (eventuell vorher ein vollständiges Backup auf dem neuen Fileserver abwarten?). Offene Dateien von Benutzern liegen immer noch auf dem alten Share und können erst repliziert werden, wenn sie die Dateien geschlossen oder sich abgemeldet haben. Daher sollte die Replikation erst gestoppt werden, wenn alle offenen Dateien geschlossen sind.

Eine mögliche Ergänzung ist es, den neuen Fileserver zuerst als Read-Only Replikat (erst ab Windows 2008 R2) laufen zu lassen, so wird sicher gestellt, dass nicht versehentlich auf dem neuen Fileserver Dateien gelöscht oder geändert werden und diese somit wieder zurück repliziert werden. Eine Änderung dieses Status bedeutet leider eine neue Initiale Replikation, d.h. DFSR kontrolliert erneut alle Dateien, ob sie sich in der Quelle oder im Ziel geändert haben. Dies bedeutet eine entsprechende Last und Verzögerung. Aus Erfahrung würde ich daher auf dieses Feature bei einer Migration verzichten.

Um die Initiale Replikation zu beschleunigen, kann man auch die Dateien zuerst auf einem anderen Weg übertragen. Hier bietet sich ein Backup oder Robocopy an. Dies hat den Vorteil, dass man das kopieren z.B. in der Nacht oder am Wochenende anstoßen und die volle Bandbreite nutzen kann. DFSR verwendet immer nur den gerade freien Anteil.

Eine Beschreibung wie die Initiale Replikation funktioniert ist hier zu finden:

http://blogs.technet.com/b/askds/archive/2008/02/12/get-out-and-push-getting-the-most-out-of-dfsr-pre-staging.aspx

Die passenden Kommandozeilen für Robocopy sind in diesem Artikel beschrieben:

http://blogs.technet.com/b/askds/archive/2010/09/07/replacing-dfsr-member-hardware-or-os-part-2-pre-seeding.aspx

ACHTUNG: Auf jeden Fall die aktuellste Robocopy Version (z.B. http://support.microsoft.com/kb/979808/en-us)  verwenden und möglichst auf einem Windows 2008 R2  Server kopieren. Auch die aktuellsten Hotfixe für DFSR können nicht schaden (eine Liste mit aktuellen Hofixen unter http://support.microsoft.com/kb/968429/en-us).

In the authoring console you have the add a reference to the Microsoft.Linux.RHEL.4 MP because we will use the RHEL4 Computer object.

This is the XML code of the first discovery task:

<Discovery ID=”Technidata.Fedora.4.Computer.Discovery” Enabled=”true” Target=”RedHat!Microsoft.Linux.RedHat.Computer” ConfirmDelivery=”false” Remotable=”true” Priority=”Normal”>
<Category>Discovery</Category>
<DiscoveryTypes>
<DiscoveryClass TypeID=”RHEL4!Microsoft.Linux.RHEL.4.Computer” />
</DiscoveryTypes>
<DataSource ID=”DS” TypeID=”Unix!Microsoft.Unix.WSMan.TimedEnumerate.Filtered.MatchesRegularExpression.DiscoveryData”>
<TargetSystem>$Target/Property[Type="Unix!Microsoft.Unix.Computer"]/NetworkName$</TargetSystem>
<Uri>http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem?__cimnamespace=root/scx</Uri>
<Filter />
<SplitItems>false</SplitItems>
<Interval>300</Interval>
<SyncTime />
<FilterProperty>//*[local-name()="Caption"]</FilterProperty>
<FilterValue>.*Fedora Core release 4.*</FilterValue>
<ClassId>$MPElement[Name="RHEL4!Microsoft.Linux.RHEL.4.Computer"]$</ClassId>
<InstanceSettings>
<Settings>
<Setting>
<Name>$MPElement[Name="Unix!Microsoft.Unix.Computer"]/PrincipalName$</Name>
<Value>$Target/Property[Type="Unix!Microsoft.Unix.Computer"]/PrincipalName$</Value>
</Setting>
<Setting>
<Name>$MPElement[Name="Unix!Microsoft.Unix.Computer"]/TimeZoneOffset$</Name>
<Value>$Data///*[local-name()="CurrentTimeZone"]$</Value>
</Setting>
</Settings>
</InstanceSettings>
</DataSource>
</Discovery>

As you can see it is mainly copied from the RHEL4 MP. Only the filer value has changed.
The second discovery does more or less the same but creates an OS object:

<Discovery ID=”Technidata.Fedora.4.OperatingSystem.Discovery” Enabled=”true” Target=”RHEL4!Microsoft.Linux.RHEL.4.Computer” ConfirmDelivery=”false” Remotable=”true” Priority=”Normal”>
<Category>Discovery</Category>
<DiscoveryTypes>
<DiscoveryClass TypeID=”RHEL4!Microsoft.Linux.RHEL.4.OperatingSystem” />
</DiscoveryTypes>
<DataSource ID=”DS” TypeID=”Unix!Microsoft.Unix.WSMan.TimedEnumerate.Filtered.MatchesRegularExpression.DiscoveryData”>
<TargetSystem>$Target/Property[Type="Unix!Microsoft.Unix.Computer"]/NetworkName$</TargetSystem>
<Uri>http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem?__cimnamespace=root/scx</Uri>
<Filter />
<SplitItems>false</SplitItems>
<Interval>300</Interval>
<SyncTime />
<FilterProperty>//*[local-name()="Caption"]</FilterProperty>
<FilterValue>.*Fedora Core release 4.*</FilterValue>
<ClassId>$MPElement[Name="RHEL4!Microsoft.Linux.RHEL.4.OperatingSystem"]$</ClassId>
<InstanceSettings>
<Settings>
<Setting>
<Name>$MPElement[Name="Unix!Microsoft.Unix.Computer"]/PrincipalName$</Name>
<Value>$Target/Property[Type="Unix!Microsoft.Unix.Computer"]/PrincipalName$</Value>
</Setting>
<Setting>
<Name>$MPElement[Name="Unix!Microsoft.Unix.OperatingSystem"]/OSVersion$</Name>
<Value>$Data///*[local-name()="Version"]$</Value>
</Setting>
<Setting>
<Name>$MPElement[Name="Unix!Microsoft.Unix.OperatingSystem"]/OSVersionDisplayName$</Name>
<Value>$Data///*[local-name()="Caption"]$</Value>
</Setting>
<Setting>
<Name>$MPElement[Name="System!System.Entity"]/DisplayName$</Name>
<Value>$Data///*[local-name()="Caption"]$</Value>
</Setting>
</Settings>
</InstanceSettings>
</DataSource>
</Discovery>
</Discoveries>

If you save and imports this management pack into SCOM the Fedora system will be discovered as a RHEL4 system and the normal RHEL4 MP will do the monitoring for you.

First we have to install the RHEL4 scom agent manual onto the systems. In this case we had to install the OpenSSL library, too. Additional we add the scom user account to the system.

After that we sign the local created certificate by the scom server and replace it on the Fedora system.

Now we can test the connection from the SCOM server with this winrm command:

winrm enumerate http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_OperatingSystem?__cimnamespace=root/scx -username:scomuser -password:yourpassword -r:https://your.fedora.system:1270/wsman -auth:basic -encoding:UTF-8

The output shows detail information about the OS:

SCX_OperatingSystem

CSCreationClassName = SCX_ComputerSystem

CSName = your.fedora.system

Caption = Fedora Core release 4 (Stentz)

CreationClassName = SCX_OperatingSystem

CurrentTimeZone = 120

Description = Fedora Core release 4 (Stentz)

Distributed = null

ElementName = null

EnabledDefault = 2

EnabledState = 5

FreePhysicalMemory = 1399808

FreeSpaceInPagingFiles = 2039808

FreeVirtualMemory = 3439616

HealthState = null

InstallDate = null

MaxNumberOfProcesses = 32216

MaxProcessMemorySize = 0

MaxProcessesPerUser = 999

Name = Red Hat Distribution

[…]

Interesting for the monitoring are three settings: the caption, the description and the name.

If you want to know how the Red Hat Management pack discovers his systems you have to look into the signed management pack (MP). The authoring console only shows some information of a signed MP. If you want so see all information or want to copy some discovery routines you have to unsign it.

This is a very simple task with the SCOM powershell:

get-managementpack -Name “Microsoft.Linux.RedHat.Library” | export-managementpack -path “c:\export”

This one-liner retrieves the Microsoft.Linux.RedHat.Library MP and saves it unsigned to c:\export. You have to do it with the Microsoft.Linux.RedHat.Library and the Microsoft.Linux.RHEL.4 management pack.

If you look into the discovery routines with the authoring console you see that the discovery takes place in three steps. The Red Hat Library discovers all Red Hat systems by the operating system name. In this case the name of the Fedora OS is equal to the search name of the Red hat library: “Red Hat Distribution”. For the discovered systems an object of the type “Microsoft.Linux.RedHat.Computer” is created.

The  Microsoft.Linux.RHEL.4 MP checks all this objects for a  RHEL 4 distinguished caption value to create a “Microsoft.Linux.RHEL.4.Computer” object. So if you want to convince SCOM that a Fedora 4 is a RHEL 4 you have to create a MP that  creates a RHEL4 object based on the Fedora Stentz caption.

http://support.microsoft.com/kb/956893/en-us

Summaries:

1. SQL 2005 or higher is supported on Hyper-V or a hypervisor validated in the SVVP program
2. Snapshots of the VM are NOT supported.
3. Hyper-V Dynamic Memory is supported but only useful with SQL Server version Enterprise and Datacenter

The problem is that you have to handle many long pathes and cryptical GUIDs. I had to do that for a bunch of different VMs and being chronical lacy I created three batch files for it:

1. importVM.cmd “GUID” “Path to Virtual Machine” creates the link and corrects the permissions on the link and the vm folder
2. importSnapshot.cmd “SnapshotGuid” “VMGuid” “Path to Snapshot” creates the snapshot link and the right permission.

Not very impressiv? Well, the third batch files combines this two scripts:

1. addMachine.cmd: Takes the basis path (the path where the sub-folder Virtual Machine, Snapshots exists) and extracts the VM-GUID, all Snapshots-GUIDs and the other pathes to automaticly create the links and permissions.

So with one simple command (addMachine.cmd C:\ClusterStorage\Volume4\VM1) you can import the complete VM.

— addMachine.cmd ——

setlocal ENABLEDELAYEDEXPANSION

set vmBasisPath=%~1

for /f %%a in ('dir "%vmBasisPath%\Virtual Machines\" /b /ad') do (
  set guid=%%a
)

echo %guid%
call "%~dp0importVM.cmd" %guid% "%vmBasisPath%"

for /f %%a in ('dir "%vmBasisPath%\Snapshots\" /b /ad') do (
  call "%~dp0importSnapshot.cmd" %%a %guid% "%vmBasisPath%\Snapshots"
)

endlocal

——————————–

— importVM.cmd ———-

setlocal

set guid=%~1
set vmPath=%~2
set xmlPath=%vmpath%\Virtual Machines\%guid%.xml

mklink "c:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\%guid%.xml" "%xmlpath%"

Icacls "c:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\%guid%.xml" /grant "NT VIRTUAL MACHINE\%GUID%":(F) /L
Icacls "%vmpath%" /grant "NT VIRTUAL MACHINE\%GUID%":(F) /T

Endlocal

——————————–

— importSnapshot.cmd –

setlocal

set guid=%~1
set vmguid=%~2

rem C:\ClusterStorage\Volume4\mcFly2\Snapshots
set snapPath=%~3

if not EXIST "%snapPath%\%guid%.xml" goto ende

Mklink "C:\ProgramData\Microsoft\Windows\Hyper-V\Snapshots\%guid%.xml" "%snapPath%\%guid%.xml"
Icacls C:\ProgramData\Microsoft\Windows\Hyper-V\Snapshots\%guid%.xml /grant "NT VIRTUAL MACHINE\%vmguid%":(F) /L

:ende
Endlocal

———————————

You can activate it by following this instruction:

1. Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AdtAgent\Parameters
2. Create DWORD value = TraceFlags
3. Edit the TraceFlags entry and enter decimal value 524420
4. Restart the AdtAgent service

(Source: http://helpmemanage.blogspot.com/2007/05/enable-detailed-logging-for-acs.html)

You can find the log under c:\windows\temp

One cause can be that the acs cannot operate over forest borders or from a workgroup (kerberos authentication – some reason for the scom agent).

The workaround is a little bit mor complicated that a simple certificate exchange.

A good and working explanation can be found here:

http://www.directtechnology.com/BlogEngine/post/2010/08/17/Problems-with-non-trusted-computers-reporting-to-ACS-%28Audit-Collection-Services%29.aspx

You can simpe activate the debugging with two registry entries:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{728EE579-943C-4519-9EF7-AB56765798ED}]
"LogLevel"=dword:00000003
"TraceLevel"=dword:00000002