Access Violation – Account Locked report: 539, 534, 4740, 6279
Access Violation – Unsuccessful Logon Attempts report: 529, 530, 531, 532, 533, 534, 535, 536, 537, 539, 4625
Account Management – Domain and Built-in Administrators Changes report: 632, 633, 636, 637
Account Management – Passwords Change Attempts by Non-owner report: 627, 628, 4723, 4724
Account Management – User Accounts Created report: 624, 4720
Account Management – User Accounts Deleted report: 630, 4726
Usage – Object Access report: 560, 567, 4656, 4663
Usage – Privileged logon report: 575, 4672
Usage – Sensitive Security Groups Changes report: 631, 632, 633, 634, 635, 636, 637, 638, 639, 641, 658, 659, 660, 661, 662, 4727, 4728, 4729, 4730, 4731, 4732, 4733, 4734, 4735, 4737, 4754, 4755, 4756, 4757, 4758
Usage – User Logon report: 528, 540, 4624
System Integrity – Audit Log Cleared report: 517, 1102
System Integrity – Audit Failure report: 516, 4612
Policy – Privilege Added Or Removed report: 609, 622, 4704, 4705
Policy – Object Permissions Changed report: 4670
Policy – Audit Policy Changed report: 612, 4719
Policy – Account Policy Changed report: 643, 4739
Planning – Logon Counts of Privileged Users report: 576, 4672

This information might be helpful to anyone interested in setting up filter on the ACS Collector side in order to limit the list of events that are stored in the ACS database. By default, all security events from ACS forwarders are stored in the ACS database. In my test environment, approximately 57% events stored in the ACS database are not included in any of above-mentioned ACS reports. This means that a lot of data in the ACS database is irrelevant for reporting purposes and that ACS database size can be reduced significantly by setting up ACS Collector filter.

To set up ACS Collector filter and to limit the list of events that are stored in the ACS database, AdtAdmin.exe /SetQuery command line utility must be used. It uses Windows Management Instrumentation (WMI) Query Language (WQL) to filter events before they hit the ACS database.

For more information on how to use AdtAdmin.exe command line utility, you may refer to the following Microsoft TechNet article:
• AdtAdmin.exe /SetQuery – http://technet.microsoft.com/en-us/library/bb381343.aspx

If you want to go further and decide to collect security events from such computers by leveraging Audit Collection Services feature (assuming that the appropriate infrastructure for ACS is in place), you will soon notice that it does not work without additional configuration of ACS Collector, as well as ACS Forwarder components.

The following event in Operations Manager event log indicates that AdtAgent service running on ACS Forwarder is unable to authenticate against the ACS Collector:

Event Type:       Warning
Event Source:   AdtAgent
Event Category:               None
Event ID:             4369
User:                    NT AUTHORITY\NETWORK SERVICE
Description:      Forwarder unsuccessfully tried to connect to the following collector(s):
<<ACS Collector computer name>>:51909, status: 0×40 (TCP connect), source: registry addresses tried: <<ACS Collector IP address>>:51909

Similar to the System Center Management service (HealthService) which you have probably already configured for the certificate-based authentication by using the MOMCertImport.exe tool, ACS Collector and ACS Forwarder(s) must also be configured for certificate-based authentication.

To configure “Operations Manager Audit Collection Service” (AdtServer) running on the ACS Collector for certificate-based authentication, run AdtServer.exe –c command (by default, it is located in the %SYSTEMROOT%\System32\Security\AdtServer folder.

To configure “Operations Manager Audit Forwarding Service” (AdtAgent) running on the ACS Forwarder for certificate-based authentication, run AdtAgent.exe –c command (by default, it is located in the %SYSTEMROOT%\System32 folder.

Once this is done, AdtAgent will still be unable to authenticate. However, in this case you will see the following error in the Operations Manager event log (note that error number is different).

Event Type:       Warning
Event Source:   AdtAgent
Event Category:               None
Event ID:             4369
User:                    NT AUTHORITY\NETWORK SERVICE
Description:      Forwarder unsuccessfully tried to connect to the following collector(s): <<ACS Collector computer name>>:51909, status: 0×2746 (TCP connect), source: registry addresses tried: <<ACS Collector IP address>>:51909

Last step required to resolve this problem is to create name mapping to the certificate in the Active Directory environment where ACS Collector is located. In order to do that, you must first export computer certificate from the ACS Forwarder into the DER encoded binary X.509 (.CER) file. Then, create an “empty” computer account whose name must match NetBIOS name of ACS Forwarder. Right-click on the newly created computer account and then select Name Mappings option. Under the Security Identity Mapping option, import X.509 certificate. After that, make sure to restart AdtAgent service on the ACS Forwarder. It should now successfully authenticate against the ACS Forwarder, followed by this event in the Operations Manager event log:

Event Type:       Information
Event Source:   AdtAgent
Event Category:               None
Event ID:             4368
User:                    NT AUTHORITY\NETWORK SERVICE
Description:      Forwarder successfully connected to the following collector: <<ACS Collector computer name>>:51909, status: 0×0 (success), source: registry addresses tried: <<ACS Collector IP address>>:51909

For more information, refer to the following Microsoft TechNet articles:

• How to Configure Certificates on the ACS Collector in Operations Manager 2007 – http://technet.microsoft.com/en-us/library/bb735410.aspx
• How to Configure Certificates on the ACS Forwarder in Operations Manager 2007 – http://technet.microsoft.com/en-us/library/bb735420.aspx

This whole process is also explained in the Operations Manager 2007 Security Guide which is available as free download from Microsoft, as well as in the System Center Operations Manager 2007 Unleashed book.

I have prepared test environment for that purpose and evaluation of OpsMgr 2012 Beta started with the installation. In my case, I have decided to use a Windows Server 2008 R2 virtual machine which has SQL Server installed locally and which is also Active Directory Domain Controller. Of course, this is not recommended nor best practices configuration for production environments, but it should work for testing purposes within lab environments.

After promoting server to Active Directory Domain Controller, and after successful installation of the SQL Server 2008 R2 (using the SQL_Latin1_General_CP1_CI_AS collation), I’ve decided to start the installation of OpsMgr 2012 Beta. Let me now share my experience…

In my test environment, all SCOM features are installed on the same server. They are:

• Management server,
• Management console,
• Web console and
• Reporting server.

Note that in OpsMgr 2012 there is no root management server (RMS) – all management servers are now peers and workload is split among all management servers in a management group. This now means that clustering is not required to provide fault tolerant and highly available solution.  Thumbs-up for that!

If you also decide to put all SCOM features on the same server, before running setup make sure that Web Server (IIS) role is installed on it. You can easily do that by using the Add Roles Wizard.

When running Add Roles Wizard to install Web Server (IIS) role, the following role services must also be included:

• IIS6 Metabase Compatibility role service,
• ASP.NET, including required role services for it,
• Windows Authentication role service,
• Static Content role service,
• Default Document role service,
• Directory Browsing role service,
• HTTP Errors role service,
• HTTP Logging role service,
• Request Monitor role service,
• Request Filtering role service,
• Static Content Compression role service and
• IIS Management Console role service.

Then, another software requirement for the Operations Manager 2012 is Microsoft .NET Framework 4 which you can find on Microsoft Download Center at the following location: http://www.microsoft.com/download/en/details.aspx?id=17851

In order to save some time, it is better to install .NET Framework 4 after the Web Server (IIS) role. If you have installed Web Server (IIS) role after installing .NET Framework 4 you will receive the following errors in the prerequisites checker of the OpsMgr 2012 Setup Wizard:

The ISAPI and CGI Restrictions are disabled or missing: Web Console cannot operate properly because the ISAPI and CI Restrictions in Internet Information Services (IIS) are disabled or missing for ASP.NET 4.0.

ASP.NET 4.0 Registration Check: The ASP.NET 4.0 handler is not registered with IIS.

Hopefully, this error is well documented in the Quick Start Guide to Microsoft System Center Operations Manager 2012 Beta, as well as on Microsoft TechNet. To resolve it, there are two steps which must be taken:

You must open a Command prompt as Administrator and run the following command which registers ASP.NET 4.0 with
IIS: %WINDIR%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe –r

You should receive the following output:

Start installing ASP.NET (4.0.30319) and changing IIS configuration to use this version of ASP.NET.

Finished installing ASP.NET (4.0.30319) and changing IIS configuration to use this version of ASP.NET.

Secondly, run Internet Information Services (IIS) Manager, open ISAPI and CGI Restrictions properties of the web site, select ASP.NET v4.0.30319, and then click Allow.

NOTE: ISAPI and CGI Restrictions in IIS for ASP.NET 4 are not enabled by default so this step is also applicabe in case if you have installed IIS before installing .NET Framework 4.

Once this was configured, prerequisite checker of the OpsMgr 2012 Setup Wizard did not report any issues and I was able to proceed with the installation.

There were two more errors on which I bumped into, but they might be specific to my test environment only.

On the Configure the operational database page of the OpsMgr 2012 Setup Wizard, setup wizard was not able to successfully validate SQL Server using NetBIOS computer name with an error saying: “This SQL server could not be found”. I solved this issue by typing LOCALHOST as the server name.

Second problem was related to the fact that OpsMgr 2012 in my test environment is running on a server which is also an Active Directory Domain Controller.
Management Server was in “Not Monitored” state because Run As accounts did not have the “Allow log on locally” right. You can identify this kind of
problem by the occurrence of the following event in Operations Manager event
log:

Log Name: Operations Manager
Source: HealthService
Event ID: 7002
Task Category: Health Service
Level: Error
Description: The Health Service could not log on the RunAs account <service account name> for management group <management group name> because it has not been granted the “Allow log on locally” right.

After granting “Allow log on locally” right, health state of the management
server turned into healthy (green) state.

Operations Manager 2012 is now up and running and I am looking forward in evaluating it.

After investigating this issue, it turned out that DCOM was not enabled on affected computers. In order to enable DCOM, use the following procedure on computers that are experiencing this problem:
1. Open Component Services mmc. Start ->Run -> dcomcnfg.
2. Expand Component Services -> Computers -> My Computer.
3. Right click on My Computer and select Properties. Go to the Default Properties tab. Make sure that “Enable Distributed COM on this computer” option is enabled. Set Default Authentication Level to Connect and Default Impersonation Level to Identify.

In addition, the following events are written to the Operations Manager log on the SCOM Root Management Server:

Event Type: Error
Event Source: OpsMgr SDK Service
Event ID: 26319
Description:
An exception was thrown while processing ImportManagementPack for session id uuid:6e44bef7-2a3a-4304-9443-d7cbf155c41b;id=326.
Exception Message: The creator of this fault did not specify a Reason.
Full Exception: System.ServiceModel.FaultException`1[Microsoft.EnterpriseManagement.Common.ManagementPackException]: The creator of this fault did not specify a Reason. (Fault Detail is equal to : Verification failed with [1] errors:
-------------------------------------------------------
Error 1:
: Could not load ManagementPack [ID=Microsoft.MSMQ.Library, Keytoken=31bf3856ad364e35, Version=6.0.6615.0]. ManagementPack not found in the store.
Version mismatch. For ManagementPack [[Microsoft.MSMQ.Library, 31bf3856ad364e35, 6.0.6587.0]] requested version from the database was [6.0.6615.0], and actual version available is [6.0.6587.0]
-------------------------------------------------------
Could not load ManagementPack [ID=Microsoft.MSMQ.Library, Keytoken=31bf3856ad364e35, Version=6.0.6615.0]. ManagementPack not found in the store.Version mismatch. For ManagementPack [[Microsoft.MSMQ.Library, 31bf3856ad364e35, 6.0.6587.0]] requested version from the database was [6.0.6615.0], and actual version available is [6.0.6587.0]).

Event Type: Error
Event Source: OpsMgr SDK Service
Event Category: None
Event ID: 26319
Description:
An exception was thrown while processing ImportManagementPack for session id uuid:6e44bef7-2a3a-4304-9443-d7cbf155c41b;id=326.
Exception Message: The creator of this fault did not specify a Reason.
Full Exception: System.ServiceModel.FaultException`1[Microsoft.EnterpriseManagement.Common.ManagementPackException]: The creator of this fault did not specify a Reason. (Fault Detail is equal to : ManagementPack Version [6.0.6615.0] is not upgrade compatible with older version [6.0.6587.0]. Compatibility check failed with 1 errors:
-------------------------------------------------------
Error 1:
: SecureReference: [Microsoft.MSMQ.QueueAccessProfile] is not upgrade compatible.
[SecureReference]: [Microsoft.MSMQ.QueueAccessProfile] exists in current version [6.0.6587.0] of ManagementPack but does not exist in the new version [6.0.6615.0].
-------------------------------------------------------

This issue is caused by the fact that any existing MSMQ Management Pack should be removed prior upgrade to the 6.0.6615.0 version. Message Queuing Management Pack Guide does not include this information (at the time when this blog post was created).

hInventoryActionID = "{00000000-0000-0000-0000-000000000001}"
Set oLocator = CreateObject("WbemScripting.SWbemLocator")
Set oServices = oLocator.ConnectServer( , "root\ccm\invagt")
oServices.Delete "InventoryActionStatus.InventoryActionID=""" & hInventoryActionID & """"
wscript.sleep 3000
Set cpApplet = CreateObject("CPAPPLET.CPAppletMgr")
Set actions = cpApplet.GetClientActions
For Each action In actions
If Instr(action.Name,"Hardware Inventory") > 0 Then
action.PerformAction
End if
Next

For more information, refer to the following MSDN article: http://msdn.microsoft.com/en-us/library/cc144592.aspx

In order to force Software Inventory on SCCM Client, run the following VBScript:

sInventoryActionID = "{00000000-0000-0000-0000-000000000002}"
Set oLocator = CreateObject("WbemScripting.SWbemLocator")
Set oServices = oLocator.ConnectServer( , "root\ccm\invagt")
oServices.Delete "InventoryActionStatus.InventoryActionID=""" & sInventoryActionID & """"
wscript.sleep 3000
Set cpApplet = CreateObject("CPAPPLET.CPAppletMgr")
Set actions = cpApplet.GetClientActions
For Each action In actions
If Instr(action.Name,"Software Inventory") > 0 Then
action.PerformAction
End if
Next


For more information, refer to the following MSDN article: http://msdn.microsoft.com/en-us/library/cc145432.aspx

Failed to resolve the source for SMS PKGID=PKGID$, hr=0x80070002

When looking at numerous forum posts on this subject, in almost all cases it turned out to be network-related problem in a way that SCCM Client is not able to reach software distribution package on the distribution point. However, in my case this couldn’t have been the problem because Task Sequence was run from standalone bootable media (DVD-ROM) which contained all referenced software distribution files.

After spending a lot of time troubleshooting, it turned out that the problem was caused by the fact that DVD-ROM drive included in the physical server on which TS was running was not able to read dual-layered DVD-ROM media files. Complete TS had approximately 5 GB in size and couldn’t fit on single-layered media. That’s why dual-layered DVD-ROM media had to be used.

This just proved again that most obvious solution is often the last one taken into consideration.

1. Open Command Prompt.
2. Navigate to folder containing compressed files.
3. Run the following command: COMPACT /U /S /A /I

To see all command line parameters of the COMPACT command line tool, simply run COMPACT /?.

By default, this is not included in Configuration Manager hardware inventory which therefore must be extended by editing sms_def.mof file. The Win32_PhysicalMemory WMI class represents a physical memory device located on a computer system and available to the operating system. To include Win32_PhysicalMemory WMI class in the scope of hardware inventory, the following lines should be added to the sms_def.mof file:

//* Physical memory location inventory.

[ SMS_Report(TRUE),
SMS_Group_Name("Physical Memory Location"),
SMS_Class_ID("Microsoft|PHYSICAL_MEMORY_LOCATION|1.0") ]
Class Win32_PhysicalMemory: SMS_Class_Template
{
[key, SMS_Report(TRUE)]
uint64 Capacity;
[key, SMS_Report(TRUE)]
string Description;
[key, SMS_Report(TRUE)]
string DeviceLocator;
[key, SMS_Report(TRUE)]
string Manufacturer;
[key, SMS_Report(TRUE)]
uint16 MemoryType;
[key, SMS_Report(TRUE)]
string PartNumber;
[key, SMS_Report(TRUE)]
string SerialNumber;
[key, SMS_Report(TRUE)]
uint32 PositionInRow;
[key, SMS_Report(TRUE)]
uint32 Speed;
};


In this example Capacity, Description, DeviceLocator, Manufacturer, MemoryType, PartNumber, SerialNumber, PositionInRow and Speed properties of the Win32_PhysicalMemory WMI class will be queried and included in hardware inventory.
For a list of all available properties, you may refer to MSDN: Win32_PhysicalMemory Class – http://msdn.microsoft.com/en-us/library/aa394347(v=vs.85).aspx

Once this is done and first managed devices run hardware inventory based on extended sms_def.mof file, you can then create custom Configuration Manager report to display collected information. For a custom Configuration Manager report, the following query can be used:

SELECT
v_GS_SYSTEM.Name0 AS 'Computer Name',
Capacity0/1048576 AS 'Capacity (MB)',
Description0 AS 'Description',
DeviceLocator0 AS 'Device Locator',
Manufacturer0 AS 'Manufacturer',
PartNumber0 AS 'Part Number',
SerialNumber0 AS 'Serial Number',
MemoryType0 AS 'Memory Type',
PositionInRow0 AS 'Position In Row',
Speed0 AS 'Speed (ns)'
FROM
v_GS_PHYSICAL_MEMORY_LOCATION
JOIN
v_GS_SYSTEM ON v_GS_SYSTEM.ResourceID = v_GS_PHYSICAL_MEMORY_LOCATION.ResourceID
ORDER BY v_GS_SYSTEM.Name0

Sync failed: WSUS server not configured. Source: CWSyncMgr::DoSync

In my case, affected primary site was child-site of the central primary site which is configured to perform synchronization with the Microsoft Update.
First thing I have stumbled upon was the following TechNet article: Troubleshooting Software Updates Synchronization Failures – http://technet.microsoft.com/en-us/library/bb735874.aspx which also contains possible solutions for the exact problem I was experiencing. However, none of the suggested solutions worked for me.

After spending some time troubleshooting, it turned out that there was a problem with the synchronization between the central (parent) and the affected primary (child) site. In order to fix the problem, I had to make sure that:
1. Standard Sender Address is configured appropriately on both sites and that
2. Public keys between the sites are manually exchanged (How to Manually Exchange Public Keys Between Sites – http://technet.microsoft.com/en-us/library/bb693690.aspx)

Once synchronization between sites was successfully established, error in the wsyncmgr.log file was gone and Software Update Point synchronization works as expected.