Markus Bäker

On thing I was always missing in System Center Operations Manager (SCOM) was the notification with other instant messaging (IM) protocols than the build in Microsoft Communicator.

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.

Read more…

Find the newest version on top of: http://www.mbaeker.de/tag/scom2nagios/

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)

In the part 3 of the Fedora Core 4 discovery pack I will explain the creation of the discovery management pack in detail.

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.

Read more…

DFS ermöglicht nicht nur eine einheitliche Sicht bzw. Einstiegspunkt auf die Dateien im Unternehmen, sondern ermöglicht auch ein transparentes Umziehen der Dateien von einem Server auf einen anderen.

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).

The creation of the troja management pack is easy. You only have to add to discovery tasks which create the RHEL4 computer object and the operating system object and fills them with some basic informations.

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>

Read more…

Fedora bases upon Red Hat Enterprise linux which is supported by SCOM. Fedora Core 3 was the base of  RHEL 4 and Fedora Core 6 RHEL 5. In this blog posts I will try to convince SCOM that the Fedora 4 based Asterisk telecom system is a RHEL 4.

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:

Read more…

If you want to know if it is supported to run the SQL Server in a virtualized environment than this is the right article for you:

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

Normaly you can only import a Virtual Machine (VM) into Hyper-V if you have exported it. If you lose your Hyper-V settings or have to import it into a new Hyper-V Server in case of a desaster recovery than you can use the steps descripted in this (and other) blog post: http://blogs.msdn.com/b/robertvi/archive/2008/12/19/howto-manually-add-a-vm-configuration-to-hyper-v.aspx

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 ——

Read more…

Sometimes the acs forwarder doesn’t connects successfully to the acs server and states in the operations manager event log, that you have to activate debugging to see more details.

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

Sometimes you have to debug group policy preferences (gpp) and don’t want to activate the debugging with another group policy.

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