Расширения Microsoft System Center Configuration Manager 2007

Microsoft, web-сайт: www.microsoft.com

• ACT Connector – коннектор для Application Compatibility Toolkit, помогающий собрать данные о совместимости компьютеров и установленных на них приложениях с новыми версиями программных продуктов Microsoft.

OEM Deployment Pack
Паки обеспечивают дополнительную гибкость при развертывании операционных систем на серверном оборудовании, с учетом специфики конкретного “железа”, позволяют выполнять тонкую настройку “железа”. Полезны для сборщиков и поставщиков серверов, а также для крупных компаний.

• Dell Deployment Pack (DDP)
• Deployment Pack for HP
• IBM Deployment Pack
• Sun Deployment Pack

1E, web-сайт: www.1e.com

• 1E WakeUp – средство управления функцией Wake-on-LAN (удаленное включение компьютеров и серверов) в больших сетях;
• Nomad Enterprise – средство оптимизации трафика при доставке обновлений в удаленные офисы, интегрируемое с SCCM;
• Shopping – средство автоматизации обработки запросов пользователей на установку ПО – что-то подобное SCCM Expert: Self Service, о котором я уже писал.

Acresso, web-сайт: www.acresso.com

• AdminStudio – приложение для подготовки пакетов MSI, а также пакетов для Microsoft App-V, VMware ThinApp, Citrix XenApp и их конвертирования, в том числе MSI-пакетов в виртуальные.

Adaptive, web-сайт: www.adaptiva.com

• Companion – средства управления электропитанием компьютеров и серверов, в том числе функцией Wake-on-LAN, выключением неиспользуемого оборудования для экономии электроэнергии;
• OneSite – расширение для оптимизации управления конфигурациями и связанного с ним трафика в крупных сетях с сотнями сайтов и точек распространения обновлений;
• Client Health – выполняет проверку функционирования компьютеров без использования агентов SCCM, позволяет также проверить корректность установки агентов SCCM.

Blue Coat, web-сайт: www.bluecoat.com

• ProxySG – аппаратное устройство, выполняющее сжатие и оптимизацию трафика, в том числе доставку пакетов приложений, в частности при использовании App-V.

Quest Software, web-сайт: www.quest.com

• MSI Studio – приложение для подготовки пакетов MSI и их переупаковки;
• Xtensions (QMX) – набор расширений, обеспечивающих поддержку платформ, отличных от Windows (Unix, Linux, VMware, MacOS X);
• Xtensions (QMX) for Device Management – набор расширений, обеспечивающих поддержку более 100 устройств различных производителей (маршрутизаторы, принтеры, ИБП и прочее).

Silect Software, web-сайт: www.silect.com

• CP Studio – набор инструментов и база знаний для минимизации времени развертывания, настройки и тестирования SCCM в части контроля соответствия конфигураций (Desired Configuration Manager). Например, CP Studio позволяет быстро в визуальном режиме сконфигурировать и протестировать пакеты эталонных конфигураций.

Provance, web-сайт: www.provance.com

• Provance IT Asset Management – комплексное средство управления конфигурациями в соответствие с ITIL на протяжении всего их жизненного цикла (в том числе поддержка CMDB, управление контрактами, финансами, конфигурациями, запросами и т.д.), использующее SCCM в качестве средства инвентаризации и внесения изменений.

Opalis, web-сайт: www.opalis.com

• Integration Pack for SCCM – позволяет интегрировать решения Opalis с другими системами и SCCM, автоматизируя процессы установки ПО и обновлений (например, автоматически при утверждении запроса на изменение в Service Desk), а также распространения информации о выполненных изменениях в другие системы.

File Services Management Pack for System Center Operations Manager 2007 – Beta now open

The File Services Team is proud to announce the beta release of our File Services Management Pack for System Center Operations Manager 2007. This management pack provides health monitoring for SMB shares, NFS shares, DFS Namespaces, DFS Replication and File Server Resource Manager including the File Classification Infrastructure.



Download Instructions

1. Log on to Microsoft Connect and create a profile if you have not already created a profile
2. Navigate to Connection Directory
3. Search for  File Services and Storage and select Apply Now
4. Fill-out application survey
5. Log on to File Services and Storage connection
6. Click the announcement: Beta release of SCOM Management Pack for File Services in Server 2008 R2
7. Follow instructions to download the Management Pack

How It Works: Automatic Client Approval in Configuration Manager 2007

Purpose:
This post is intended to explain how client approval works when a Mixed Mode Configuration Manager 2007 site is configured to automatically approve clients in trusted domains and to offer insight into how to troubleshoot scenarios where this is not working as expected.  The configuration is shown below:




The short version:

1. The new client performs a CCM_POST to CCM_System_WindowsAuth on the MP.
2. The MP responds with a 401 as the request is anonymous and contains no security data.
3. The client requests a Kerberos ticket for http://MP_FQDN from Active Directory (e.g. http://SCCMMP.Contoso.com).
4. On obtaining the Kerberos ticket, the client performs another CCM_POST including the security data.
5. If the MP accepts the ticket then the client is authenticated and is considered to be trusted.
6. Whether the client is trusted or not, the MP executes the spUpdateClientRegistration stored procedure to update the database. If the client has authenticated properly, both the @ApprovalMethod and @IsIntegratedAuth parameters will be set to 1. If not, they are both set to 0.
   

Technical details:
The following is from data obtained in my lab during a successful test where a client in a child domain (Child.A2003.VM.local) was automatically approved by the MP in Child’s parent domain (A2003.VM.local). Relevant details:

• Client is WK02-020-51W.Child.A2003.VM.local with IP address 192.168.20.102
• The DC for the Child domain is DC03-020-52S with IP address 192.168.20.10
• The MP is SMS4-120-52S.A2003.VM.local with IP address 192.168.120.20
• The DC for the A2003 domain is DC02-110-61E with IP address 192.168.110.10

The IIS log shows:
2009-05-20 19:35:11 W3SVC1 192.168.120.20 CCM_POST /ccm_system_windowsauth/request - 80 - 192.168.20.102 ccmhttp 401 2 2148074254
2009-05-20 19:35:13 W3SVC1 192.168.120.20 CCM_POST /ccm_system_windowsauth/request - 80 CHILD\WK02-020-51W$ 192.168.20.102 ccmhttp 200 0 0
Code 2148074254 or 0x8009030E means SEC_E_NO_CREDENTIALS
MP_RegistrationManager.log shows:
MP Reg: DDR file written to E:\SMS\inboxes\auth\ddm.box\regreq\A8Z82CVO.RDR
Network Monitor shows:
Client issues the CCM_POST with no security information, starting in frame 4:

The MP responds with the HTTP 401 in frame 10:

The client requests a Kerberos ticket for the HTTP SPN of the MP from the Child domain DC in frame 13:

The Child DC refers the client to the A2003 domain DC in frame 14:

The client then makes the same Kerberos request to the A2003 DC in frame 15:

The A2003 DC responds with a Kerberos ticket in frame 16:

The client reissues the CCM_POST, with security information, in frame 17:

The MP responds with an HTTP 200 in frame 25:

SQL Profiler shows the MP executing spUpdateClientRegistration with values of 1 (True) for the relevant parameters so the client is set to Approved in the database (with parameters inlaid):
exec spUpdateClientRegistration (@SiteCode) "2P4", (@SMSID) "GUID:EEAF9390-94EB-43AE-A0DE-F374E3E7E03B", (@CSMSID) NULL, (@Identity) NULL, (@DeviceID) NULL, (@Certificate) 0x308201E03082014DA0030201020210C25D7C383E3CB6AE466BE10C22ACF3AE300906052B0E03021D05003025311530130603550403130C574B30322D3032302D353157310C300A06035504031303534D533020170D3039303531393139333434375A180F32313039303432363139333434375A3025311530130603550403130C574B30322D3032302D353157310C300A06035504031303534D5330819F300D06092A864886F70D010101050003818D0030818902818100BAEB59B8B0ECB451AB82FECF42791740BB3704BD00705126D3DA0FB7618B53955CFF142534B09ACDB97B6B8E42D10663453EA6C35A0BC30A3A83F3381B507A4D051C884E9789DC827223C1C92D0C4712458DAF96A8F15CABE2AB14ED9755A89034657CCB96A7086DFB92E928C35626F08F6A3FA451206850CEC0FC8EC671E09F0203010001A317301530130603551D25040C300A06082B06010401823765300906052B0E03021D050003818100A7A603A7E7AFB19E7518F62F5D4153FA3926AA8348D9EFCB9EC4C03AB991202CB2496B48489C6E6AB48E673ECA6DBED3A4EC7FBE1D3BB70682338FC5E4A86BCEBC4702EDBB41F060AD54117707AFCD0A2FC8AF17DF9E71F1206FBCE9295237322029956D2AA652B41F1258D617BBC4D07410F01CC40042D33BA97511F2B2DDCA, (@Thumbprint) 0xE824658E489FDBB6481ED7788E74877FB9DBCF0B, (@EncKey) 0x308201E13082014EA00302010202106866F6C06283B38644D10B448CFAE966300906052B0E03021D05003025311530130603550403130C574B30322D3032302D353157310C300A06035504031303534D533020170D3039303531393139333434385A180F32313039303432363139333434385A3025311530130603550403130C574B30322D3032302D353157310C300A06035504031303534D5330819F300D06092A864886F70D010101050003818D0030818902818100BC71E0923FBF50300A40C479CBCE5F49D20597C00873C5F6ED16538A41FF5FA54B402905DB424D95B1D67FFFD6245204E4B5FD6A751087BAFD6846FA1272E6F0405EEB647020BB8DFD2E78516C263ECE8831E17CD230C5637AA83AE222B900530977A57F390AD6542C344AB6DD6F8D7ED8CAED76A3F700ED0250ED64481C9D550203010001A318301630140603551D25040D300B06092B0601040182376502300906052B0E03021D0500038181008D63DEC508A14404372B3BEE2AD35D8B44C7C6E2AA8B81A9FA8280D416FFAB67DDDA1F37B981523DA6EEBF66CDE9F7C501412D1438E0FC490C022BC4CA854EFAA975D49182A3300C76577B4BE15B5FCB0014C36E0C418EE98F13AF6264E69C0DCFFFADD1D0800400A15630FA6C023B989D341F33E197885001601CFFC015AA0B,(@EncThumbprint) 0x6B186E7BC2B86B059FAE5E431C6C6CE40A943F3C,(@KeyType) 1, (@PublicKey) 0x06020000002400005253413100040000010001009FE071C68EFCC0CE50682051A43F6A8FF02656C328E992FB6D08A796CB7C653490A85597ED14ABE2AB5CF1A896AF8D4512470C2DC9C1237282DC89974E881C054D7A501B38F3833A0AC30B5AC3A63E456306D1428E6B7BB9CD9AB0342514FF5C95538B61B70FDAD326517000BD0437BB40177942CFFE82AB51B4ECB0B859EBBA, (@ValidFrom) "2009-05-19 19:34:47.000", (@ValidTo) "2109-04-26 19:34:47.000", (@AgentType) 0, (@SMBIOSID) NULL , (@MACAddress) NULL , (@HardwareID1) "2:D4D8AD1963DA464FC3EE60E5212310036AB9EDEC", (@ISVProxyID) NULL , (@AlwaysInternet) 0, (@InternetEnabled) 0, (@Force) 0, (@ApprovalMethod) 1, (@ResolutionMethod) 0, (@IsIntegratedAuth) 1, (@Version) "4.00.6221.1000", (@NetbiosName) "WK02-020-51W", (@FQDName) "WK02-020-51W.Child.A2003.VM.local", (@ManualConflictResolution) 0
Troubleshooting:
Standard troubleshooting of these issues should include:

1. Checking the duplicate GUID report to see if the problem client’s GUID is present. If so, run CCMDelCert on the problem client to force a new GUID to be generated and see if that resolves the issue.
2. If duplicate GUIDs do not apply then step through the following:
   1. Delete the problem client from the central site console and let the delete cascade to child sites, as appropriate.
   2. Set the SMS Agent Host service to manual on the client and reboot it.
   3. Start a network capture on the client (NetCap, NetMon 3.x, Ethereal, etc).
   4. Set the SMS Agent Host service back to Automatic and start it.
   5. Initiate a Discovery Data Collection Cycle via the Control Panel applet.
   6. If the client is re-inserted into the database as not approved then collect the network capture (and all relevant IP details) with the IIS log and MP_RegistrationManager.log from the MP to which the client reports directly for review.
3. If the network capture shows the client does get a Kerberos ticket then the IIS log should contain a Win32 error code indicating why the MP rejected it.
4. If the client does not get a ticket then the response from the DC in the capture should detail why. Kerberos logging on the client, per KB262177, may add some useful information to the System Log in Event Viewer as well. Since Directory Services supports Kerberos, they may be engaged for assistance in determining why no ticket was acquired.

Note: The MP_RegistrationManager.log does not contain much detail by default. Enabling Verbose and Debug CCM logging will add some extra entries which may be helpful.
Known reasons why this will fail:
Duplicate GUIDs:  Duplicate GUIDs can cause a myriad of client data integrity problems including client approval issues. If only a subset of the clients are impacted by the client approval failure then duplicate GUIDs should be investigated.
The HTTP SPN is registered under a user account:  Normally, there is no HTTP SPN for a server so the HOST SPN, which should always be on the computer object, is used in obtaining the Kerberos ticket. If web based services, such as SQL Reporting Services, are running under user context on the MP, and the HTTP SPN is linked to that user account, the Kerberos ticket obtained by the client will be for the same user. When presented to the MP, which runs as Local Service (System), it is rejected because it is linked to the wrong user.
The solution for this is to delete the HTTP SPN from the user object, move the web service running as the user to a different web site using a different port and create a new HTTP SPN to refer to the new port. For example, for a new web site using TCP port 81, the new HTTP SPN, created under the user object in AD, would be similar to:
HTTP://SCCMMP.Contoso.com:81
Reference http://msdn.microsoft.com/en-us/library/aa480609.aspx which states:

SPNs are only created for the HOST service and all built-in services use the HOST SPN. However, this implementation is transparent because built-in names act as an alias to the HOST service unless they have been specifically mapped to a Windows account.

And also:

When you use Windows Integrated Security, both Internet Explorer and IIS use the HTTP SPN to request service tickets and to process a request. As a result, when you use a domain user account in IIS 6.0 as the process identity, you must map the host-based HTTP SPN to the domain account that is used by the service.

Client and MP in different domains only share an external trust:
As is noted above, Kerberos is required for the client to authenticate to the MP. While Kerberos *may* work across an external domain trust, it is not supported. It is only supported across a forest trust between two Windows Server 2003 mode (or higher) forests.
Reference http://technet.microsoft.com/en-us/library/cc773178(WS.10).aspx which states:

When two Windows Server 2003 forests are connected by a forest trust, authentication requests made using the Kerberos V5 or NTLM protocols can be routed between forests to provide access to resources in both forests.

Anything else that causes Kerberos to fail:
Kerberos can fail for many reasons including time skews in the environment; DNS name resolution failures, etc. Generally, network capture data will show why it is failing though Kerberos logging per KB262177 can also be helpful.
More Information:
General information on Client Approval can be found at http://technet.microsoft.com/en-us/library/bb694193.aspx.

OpsMgr Scripting: WYWINNWYG

"What You Write Is Not Necessarily What You Get"
Abstract
OpsMgr 2007 has a fairly substantial library of discovery module types and monitor types that ship with it.  Even with that library, it seems that the single most important extensibility point in OpsMgr today is the ability to use custom scripts to perform discovery and monitoring tasks.  As I've developed scripts for OpsMgr, I have learned a great deal about how OpsMgr processes scripts.  This article describes some important concepts regarding how scripts are processed by OpsMgr. 


Besides the Execution Environment...
There is an important distinction between the execution environment of a script and the production of the script itself.
The execution environment is fairly straight-forward: VBScript or JScript that runs through the script processor.  In fact, if you trace back the various script modules, you will find that they all derive from a handful of native modules, all of which essentially execute cscript.exe.  All of the capabilities of that scripting engine and the facilities it can access are at your disposal (ADSI, WMI, ADO, the remainder of what's in COM, etc.)  We also use a COM object in our OpsMgr scripts that is on every system that has the OpsMgr Agent installed, namely "MOM.ScriptAPI".  This essentially provides functionality to generate well-formed XML DataItems with the appropriate format, attributes, etc.  We'll see that later.  While that's a simplification of what "MOM.ScriptAPI" does, the point is that it is not part of some custom script execution environment that runs in-process with OpsMgr.  It is just another COM object that the usual cscript.exe environment instantiates at our request.
The production of the script is quite a bit more interesting, so I'll spend the majority of this article addressing it.
Sample 1: Expansion of Embedded Selectors
First, let's define a simple script, which we'll put inside a two-state script unit monitor.  This script targets Microsoft.Windows.NTService.  I've also created two service classes from the MP templates in OpsMgr, one for Browser and one for SNMP.  This virtually guarantees that OpsMgr will discover at least one on any given system.  My test system has both.
Figure 1: The script itself.  (FYI - The $...$ selector that is not entirely in view is "$Target/Host/Property[Type="System!System.Entity"]/DisplayName$")

Figures 2a and 2b: The unhealthy and health expressions.  These are somewhat unrelated to the topic of this article, but I thought I'd add this for general purposes.  It is useful to see this and to note that any time you see wizard pages that resemble these, you are using the UI to express the configuration of the System.ExpressionFilter condition detection module.  In this case, I've defined a monitor that always returns healthy, regardless of what the script does.  You can experiment with this further, but keep in mind that you can specify just about anything for either side of each expression (i.e. row on the wizard page), including the entire gamut of $...$ selectors.  ...end aside...


Returning to the main topic, anyone that is a script developer has a particular paradigm in mind.  The script is written and runs as written.  If you've ever seen constructions that use the $...$ selectors inline (e.g. SomeVar = "$MPElement...$"), you might have assumed that there was something special about the script execution environment that somehow resolves those.  The reality is that those resolutions are done before the script is ever executed.  Therefore, we have a very tricky paradigm on our hands: the execution environment is completely standard, but the script body itself is "refined" by OpsMgr before it is embodied in an actual file and run.
Let's investigate this.  Our example script does nothing of interest except return a static property bag.  That will be somewhat useful later, but for now, the really interesting part is not what the script does, but what the script becomes.
To find the actual file that is eventually run, we need to get to the Health Service State directory and find our script.  We will actually find two versions of the script, because it is generated once for each target against which the script will run (in this case, Browser and SNMP).
Figure 3a: Finding the script location.

Figure 3b: What's finally in the first instance.

Figure 3c: What's finally in the second instance.

As you can see from the figures, everything that relates to the execution context of the script is not present in the execution environment per se, but baked into the script itself as it is readied to run.  This includes information about the target, the MPElement on whose behalf the script is being invoked, any MPElement we may need (which I grant you is usually only required for discovery scripts), and information about the target's host (which is also information from the $Target...$ selector family).
It is useful to understand this mechanism for two reasons:

1. You do not need to put everything into the arguments of the script that may seem necessary.  The script will be customized per target.  This opens up a wide array of information that can be used in the script without worrying about the command line formatting.
2. It is contrary to our normal thought process for scripting.  Understanding it provides a better picture of how your script will be invoked and it also reveals how these OpsMgr-specialty-laden scripts can be debugged.

In a practice, I always include a comment line at the beginning of my scripts that includes the first four items in our sample script: the basic identification of the Target and MPElement.  I find that to be extremely useful in tracking down script errors.
Sample 2: More Embedded Selectors: From , Including Overrides
Continuing our example, let's set some overrides that will make the two instances unique with respect to their configuration as well as their target.
Figure 4a: Overrides targeted to the specific service object Browser (on the test system).

Figure 4b: Overrides targeted to the specific service object SNMP (on the test system).

I also did two other things:

1. I added a few additional lines to the script
   

   ' Some Config Values
   '   Arguments: $Config/Arguments$
   '   Interval Seconds: $Config/IntervalSeconds$
   ' A service-specific property:
   '   $Target/Property[Type="MicrosoftSystemCenterNTServiceLibrary!Microsoft.SystemCenter.NTService"]/ServiceProcessName$

   
   
2. I created another monitor that is almost identical to the first one.  The script itself is actually identical, but this second monitor defines the script in a UnitMonitorType and uses that custom UnitMonitorType in the UnitMonitor.  By default, script monitors created by the UI use a built-in UnitMonitorType, which means that the script body itself is defined in the UnitMonitor.  There is a subtle difference that we will discuss shortly.

Once the new configuration becomes active, we follow the same pattern to find our scripts and see what's in them.
Figure 5a: Finding the script location.  There will be four now: the original and the UnitMonitorType variant (UMT) for both instances.

Figure 5b and 5c: The contents of the two updated but UI-defined scripts.


Note that the additional property of the target came through fine, but the $Config$ selectors were unchanged.  This means that using a UI-defined script, the $Config$ selectors are not expanded.  This applies to both the "natural" configuration items and any overrides.
What's going on here?  Let's check out UMT version.
Figure 5d and 5e: The contents of the two updated, UMT-defined scripts.


Now, that's what we're looking for.  I must admit that while I have a reasonable explanation for this, I cannot give you a definitive answer.  I'll leave that for a developer that knows the exact inner workings of OpsMgr, but it appears that the $Config$ selectors are only expanded when module and monitor types are assembled for use in a workflow.  Think of it this way: when something defined in the section of an MP is assembled to be used in the section of an MP, $Config$ selectors are expanded.  The UI-defined monitor defines the script body in the section.  It uses a built-in module that itself defines the script body as whatever is in the of the actual monitor $MPElement$, which is defined in the section.  Therefore, our UI-defined script body is never really subjected to assembly in that way.  The UMT version, with the script defined in the UMT (under ) is assembled for use in the corresponding monitor, so we see the expansion for it.  Both are then assembled for use against the various targets that exist, which is why everything else expands in either case.
Important Notes About Expansion
There are a few additional important notes on this expansion business:

1. You must use a script argument for anything that changes between invocations of the script.  The script is created only when a new configuration becomes active.  That only happens when management packs change.  There's a myriad of things that cause a configuration change, such as group membership rules, new monitors, new subscriptions, overrides, etc., but there are an equally large number of changes to the environment that do not cause a configuration change.  Some of these include group membership updates that are the result of a dynamic rule, target property changes that are the result of discovery runs, etc.  Suffice it to say that a script can run a multitude of times under the same configuration.  This is particularly important for:
   
   1. $Data$ selectors.  There's no way to expand a $Data$ selector when the script instance is created.  These are pulled from the contents of the that is passed into the module executing the script and are therefore only available as script arguments.  If you've never seen these, they're pretty useful.  For any timed script,  my favorite is $Data/@time$.  You can pass that as an argument to have the trigger time of the monitor at your disposal, in the appropriate OpsMgr attribute format.
   2. $Target$ selectors.  We saw that these work wonderfully as embedded selectors, but you must be careful with them.  They are expanded when the script is created, which is when a new configuration becomes active.  Some $Target$ properties might change between the time the script is created from the then-active configuration and something happens that causes a new configuration to become active (and hence the script to be re-created).  If there's a $Target$ property that can afford to be a little stale, you can embed it.  If not, pass it as an argument.
   3. $MPElement$ selectors are all tied to the configuration, so they're safe.  When they change, the configuration is changing, so the script will be re-created anyway.
   
   
2. I have encountered some quirks, so don't think you're losing your mind if you see strange things in your script.  I suspect that some combinations of selectors embedded in scripts are not expanded properly, but I have been thus far unable to reliably reproduce the problem.  It definitely happens, so be on the lookout.
3. The MP alias used in the selectors must be appropriate to the MP in which the monitor is being created.  If you are creating an MP yourself, that's easy to keep straight.  If not, you may not be able to predict the alias.  System.Library, for instance, is sometimes referenced as System! and sometimes as SystemLibrary!, where is whatever version of that MP was installed when the reference was made.  An easy way to determine this is to add something as an argument using the UI.  It will use the correct alias, and you can just copy it from there.

Debugging the Expanded Script
The final item that is relevant is how this can help debugging.  This goes back to the execution environment discussion I started with.  When the MOM.ScriptAPI COM object is used to submit property bags, performance data, discovery data, etc., it does so using STDOUT.  That's it.  Therefore, running your script from the location in which it was created (under Health Service State) works just fine.  It just prints the XML representation of the data item that would be picked up by OpsMgr if the script had been run inside its workflow.
Figure 6: A property bag output to STDOUT after an interactive run of the script.

Conclusion
I hope you find this information useful.  I believe it is very helpful to understand the machinations that a script undergoes well before it even hits its execution environment.  It's also useful to have so many more data from the context of the OpsMgr configuration, target, etc. available to use.  It makes scripting that much more robust, which is a major component of OpsMgr's appeal.

Cumulative Update 1 for System Center Operations Manager 2007 R2

This update contains fixes for Windows roles since the release of System Center Operations Manager 2007 R2.

From KB974144:

* The Product Knowledge tab is displayed as the Company Knowledge tab after you import a Language Pack for System Center Operations Manager 2007 R2

* An agent cannot be removed successfully from a windows cluster server node
* The Heathservice.exe process on a Windows Cluster Server passive node may exhibit excessive CPU utilization
* The Healthservice.exe process may crash when using the OLEDb module
* Workflows using the OLEDb datasource may unload if the underlying provider returns a null or empty string
* A MonitoringHost.exe instance may cause a leak in non-paged pool
* Notification subscriptions will not work when configured to parse a CustomField or an AlertOwner
* The Operations console loses the current object focus when a search filter is applied
* The SRSUpdateTool.exe returns an error that states “Failed while updating registry entry for reporting code MSI component” when attempting to upgrade SQL Reporting
* Services 2005 to SQL Reporting Services 2008
* The Operations Manager UI can crash when the Connector and Forwarding Status columns are added to an Alert view
* Agents may re-process old Windows event log entries generating Alerts for monitored events
* Health state reliability fixes and improvements
* The ADTServer service fails to start on an ACS Collector when the operating system is upgraded to Windows Server 2008 R2
* In an exported performance report, the list of object instances is not displayed


Download: Cumulative Update 1 for System Center Operations Manager 2007 R2

The Next wave of Client Management begins now……

Today we are announcing the opening of the Technology Adoption Program nominations for the next release of System Center Configuration Manager. 
The Technology Adoption Program is designed to provide a consistent experience for Microsoft customers to obtain real-world customer feedback on Microsoft pre-release products. 
There are many benefits for our TAP customers, to name a few:

• Lead the market by adopting critical enabling technologies early
• Influence and shape the final product by providing early and deep feedback
• Connect with expertise to obtain a deep understanding of strategic emerging technologies

Building on over 14 years of systems management industry experience, Configuration Manager (formerly SMS) is the world leader in software distribution, OS deployment, HW/SW inventory and more.  Moving forward, there are both new capabilities as well as enhancements to existing product functionality that form the investments for engineering. 
Over the coming year the next release of Configuration Manager will move into a public beta.  Even at this early stage, we want to ensure that it is the highest quality release possible; the TAP program helps significantly in this effort. 
I would like to highlight for you briefly what the investment pillars for this next release are, and over the coming months we will continue to go deeper on these areas with different product folks through interviews, online chats and other forms of content.
The next release of Configuration Manager will focus on a few main areas:

• Improving client management experiences through enhanced, integrated software distribution models.  The next release of Configuration Manager will provide a framework for the right application format to be delivered to the user based on who they are, the device they are using, and their connection.
• Infrastructure improvements are also a main focus.  Optimizing site hierarchy, replication and content distribution on the backend.  For the managed client, improving client health and remediation capabilities will ensure that when a system is managed, it remains healthy and secure.  Part of this is also improving the Admin experience.  In the past we did this by reducing mouse clicks to get through an activity.  This is only part of the process.  Adding security models to enable role based administration, as well as improving the Admin console experience will ensure that Admins are more efficient everywhere.
• In addition, other areas of focus include expanding device management scenarios, model based configuration management and improving patch management services; just a few of the places we are focused on development.

We hope to see a strong interest in this TAP program, and we want to ensure as many organizations are engaged as possible.  The team is limited in resource, and as a result, not every TAP nomination can be accepted.  Completion/Submission of the TAP nomination form is not a guarantee of acceptance.  All completed nominations are evaluated to ensure the right fit, priorities and alignment of goals are present. 
The TAP is not your only avenue to access the next release of ConfigMgr.  There are other ways you be able to experience the product before release, such as the public beta programs.  Stay tuned to this blog for further announcements.
Link to Nomination Survey is here.
More information about the Microsoft TAP program can be found here.
System Center product information can be found here.
Thanks for your time
Jeff Wettlaufer 
Sr. Technical Product Manager
System Center

Try System Center Operations Manager Management Packs for SharePoint Server 2010 Beta and SharePoint Foundation 2010 beta

Management Packs allow users to monitor SharePoint 2010 with System Center Operations Manager. SharePoint Foundation Management Pack and SharePoint Server 2010 Management Pack enables monitoring of SharePoint Foundation 2010, SharePoint Server 2010, Search Server 2010 (These is separate management pack for FAST search), Project Server 2010 and Office Web Apps. Once management pack is imported to System Center console, based on console configuration it automatically discovers what SharePoint bits or servers are installed in the environment that is being monitored and start monitoring those components.
These 2010 management packs will be released to System Center Operations manager catalog and will also be released to web along with SharePoint 2010 RTM.

Out of box experience
SharePoint Management Packs monitors all prominent services, Shared Services, SharePoint Health Analyzer rules, Web Applications and SharePoint Servers. In SharePoint 2010 you can use it to monitor both physical (servers and services running on those servers) and logical (Shared Services, Web Application etc.) of SharePoint. You can monitor multiple farms, and even fix some issues automatically by running out of box tasks. You can also write your own tasks using System Center Wizard or Windows PowerShell script to enable this self-healing.
Primary takeaway of SharePoint 2010 MP is depth and breadth of monitoring and rapid detection and resolution. Here’re the improvements compared with the previous product.

	Management Packs for Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007	Management Packs for SharePoint 2010	Change
Discoveries	5	16	↑300%
Classes	10	133	↑1293%
Monitors	28	240	↑300%
Rules	235	107	↓45%
Reports	27	9	↓33%
SPHA Rules	NA	100+	↑100%
TechNet KAs	NA	~150	↑100%

These numbers illustrate significant improvements over 2007 management pack. 1200% and 300% change in number of classes and discovery represents improvement in depth and breadth of monitoring. Change in number of monitors indicates improvement in granularity of monitoring that enables quick isolation of issues. Detailed knowledge articles represent rapid diagnosis and resolution. Did you also notice knowledge articles are on TechNet, which means we will be able to improve these articles based on your feedback even after release!
In 2007 you can just monitor, one farm with multiple servers and some services. Diagram view below reflects a typical 2007 monitoring. Anything that is crossed was not available in 2007 management pack and remaining had limited depth of one additional level.


In 2010 you can monitor multiple farms, multiple servers, services, shared services, SharePoint Health Analyzer rules (Which saves you a trip to central admin which also means that System Center Operation Manager console is your one stop shop for all monitoring requirements) and web applications.
Server Monitoring
Service Monitoring


Share Service Monitoring
SharePoint Health Analyzer monitoring (One stop shop for both native and external monitoring)

Web Application Monitoring

Download Management Pack Beta for SharePoint 2010

SharePoint Foundation 2010: http://www.microsoft.com/downloads/details.aspx?FamilyId=43d5ee9a-b9a6-441d-a35e-8a7b9b15e20c
SharePoint Server 2010: http://www.microsoft.com/downloads/details.aspx?FamilyId=c8a9d749-b7a8-412a-b2db-f3e464ed3fcf