Patrick Schneider ' s Blog

Fixing the IE 8 warning – ‘Do you want to view only the webpage content that was delivered securely?’

2010-11-02T14:33:00.000-07:00

In IE 7 and ealier, this dialog would cause annoyance to users but generally didn’t cause any other significant problems. This was because it was worded in such a way that most users would click on the Yes button and allow non-secure content to be downloaded.

However, the wording in the IE 8 version of this dialog has changed:

To download the content a user would now have to click on the No button. As we know, most people using the web only scan text and avoid reading it if at all possible! They will usually go for the Yes button if there is not an OK button.

Some sites are going to find that their secure pages in IE 8 have the following problems:

Any non-secure HTTP image beacons used for analytics data gathering will often be ignored
The page may not display or even work correctly if it relies on non-secure images, CSS or Javascript

Therefore, avoiding mixed content on HTTPS pages is even more important now that IE 8 has been released. It often becomes an issue when using third party services such as analytics or Content Delivery Networks (CDN). For example, we avoided the use of Google hosted Ajax libraries on our site until Google added HTTPS support.

As mention in the previous blog post, an IE user you can disable this warning by:

Going to Tools->Internet Options->Security
Select the ‘Security’ tab
Click the ‘Custom Level’ button
In the ‘Miscellaneous’ section change “Display mixed content” to Enable

Workaround Management Pack for Microsoft Print Management Pack

2010-11-01T02:46:00.000-07:00

This management pack is intended to fix the discovery issue for Windows 2008 R2 Print Services. Currently the Microsoft printer management pack does not discover the 2008 printer services role on R2 servers, this is because the name of the role has been changed from 'Print Services' to 'Print and Document services'.

This pack depends on the Microsoft print management pack and the base 2008 server management pack.

This pack discovers the printer role only on servers which are 2008 R2 and then populate the role group inside the Microsoft print management pack.

If anyone can see a better way then feel free to modify, all I ask is you comment your ideas or changes so myself and others can learn and build upon.

*Disclaimer*

This is NOT a supported method; this pack has been created as a personal temporary fix so use at your own discretion.

Use at 'your own risk' and AS-IS with no warranties. As always use a test environment.

------------------------------------------------------------------

DOWNLOAD
------------------------------------------------------------------

OpsMgr 2007: Agents stuck in Pending Management with Event ID 21016

2010-10-30T07:27:00.000-07:00

When you deploy a System Center Operations Manager 2007 agent using the Discovery Wizard, the installation completes successfully but the computer remains in the Pending Management view under "Type: Installation in Progress." When you right-click the computer in Pending Management, the only command available is Reject. The Approve and Install Agent commands are unavailable. If you reject the computer in Pending Management, it reappears in the same state the next time you start the OpsMgr Health Service on the agent.

Additionally, each time OpsMgr Health Service starts on the agent, it logs an event in the Operations Manager log that is similar to the following:

Event Type: Error
Event Source: OpsMgr Connector
Event Category: None
Event ID: 21016
Date:
Time:
User: N/A
Computer: AGENT
Description: OpsMgr was unable to set up a communications channel to OPSMGRMS.momv3.local and there are no failover hosts. Communication will resume when OPSMGRMS.momv3.local is both available and allows communication from this computer.

In this scenario, if you install an agent manually, the manually installed agent logs the OpsMgr Connector 21016 event, but never appears in the Operations Console. This occurs even when you have enabled the option to review or automatically approve manually installed agents.

Cause:

The "Installation in Progress" pending management type indicates that the agent was installed, but has never successfully connected to the management server. In this state, the Approve command is unavailable by design (because it's a push install) and the only options are to reject the agent or fix the communication problem. General connectivity problems can cause this, however the most likely cause is a Kerberos error.

These symptoms can occur when the ServicePrincipalName (SPN) for the management server's HealthService is not registered or is not registered correctly (e.g. there's a duplicate SPN). In this scenario, the agent may log the following two events immediately prior to the OpsMgr Connector 21016 event:

Event Type: Error
Event Source: OpsMgr Connector
Event Category: None
Event ID: 20057
Date:
Time:
User: N/A
Computer: AGENT
Description: Failed to initialize security context for target MSOMHSvc/OPSMGRMS.momv3.local The error returned is 0x80090303(The specified target is unknown or unreachable). This error can apply to either the Kerberos or the SChannel package.

Event Type: Error
Event Source: OpsMgr Connector
Event Category: None
Event ID: 21001
Date:
Time:
User: N/A
Computer: AGENT
Description: The OpsMgr Connector could not connect to MSOMHSvc/OPSMGRMS.momv3.local because mutual authentication failed. Verify the SPN is properly registered on the server and that, if the server is in a separate domain, there is a full-trust relationship between the two domains.

If you enable Kerberos event logging on the agent by using the steps in KB 262177, the agent logs events similar to the following in the System log:

Event Type: Error
Event Source: Kerberos
Event Category: None
Event ID: 3
Date:
Time:
User: N/A
Computer: AGENT
Description:
A Kerberos Error Message was received:
on logon session
Client Time:
Server Time:
Error Code: 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN
Extended Error:
Client Realm:
Client Name:
Server Realm: MOMV3.LOCAL
Server Name: MSOMHSvc/opsmgrms.momv3.local
Target Name: MSOMHSvc/opsmgrms.momv3.local@MOMV3.LOCAL
Error Text:
File: 9
Line: ae0
Error Data is in record data.

A network trace shows the same 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN response received by the agent computer from the KDC.

These symptoms indicate SPN registration issues for the management server's HealthService. To check SPN registration, use setspn.exe from the Windows Server 2003 Support Tools. A copy of this tool is also available for download at the following URL:
http://www.microsoft.com/downloads/details.aspx?FamilyID=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&DisplayLang=en

To list SPNs for a computer or user account, use the following syntax:

setspn -L computername
-or-
setspn -L username

If the management server's OpsMgr Health Service logon account is Local System, its HealthService SPNs should be registered with the computer account in AD. If the management server's OpsMgr Health Service logon account is a user (not common), its HealthService SPNs should be registered with the user account. Be aware that the OpsMgr Health Service logon account may be different from the management server's Action Account. To see the logon account, open the Services MMC snap-in, double-click OpsMgr Health Service and click the Log On tab.

The HealthService SPNs should be as follow:

MSOMHSvc/FQDN
MSOMHSvc/COMPUTERNAME

Example setspn -L output
=======================================================================

Using Local System for the OpsMgr Health Service logon account:

Registered ServicePrincipalNames for CN=OPSMGRMS,CN=Computers,DC=momv3,DC=local:

MSOMHSvc/OPSMGRMS
MSOMHSvc/OPSMGRMS.momv3.local
HOST/OPSMGRMS
HOST/OPSMGRMS.momv3.localset

Using a domain user as the OpsMgr Health Service logon account for three different management servers:

Registered ServicePrincipalNames for CN=hservice_acct,CN=Users,DC=momv3,DC=local:
MSOMHSvc/OPSMGRMS1
MSOMHSvc/OPSMGRMS1.momv3.local
MSOMHSvc/OPSMGRMS2
MSOMHSvc/OPSMGRMS2.momv3.local
MSOMHSvc/OPSMGRMS3
MSOMHSvc/OPSMGRMS3.momv3.local

=======================================================================

Be aware that the OpsMgr Health Service will attempt to register its SPN every time it starts. If automatic SPN registration is failing, it indicates that the service's logon account doesn't have permission in Active Directory to register its SPN. In that case, you can run setspn -A to add the SPNs manually. You must run this command using a Domain Admin account. For example, to register the HealthService SPNs for a management server named opsmgrms.momv3.local that uses Local System as its OpsMgr Health Service logon account, run the following commands:

setspn -A MSOMHSvc/OPSMGRMS opsmgrms
setspn -A MSOMHSvc/OPSMGRMS.momv3.local opsmgrms

OpsMgr 2007 RTM and SP1 RC command line parameters (Complete List)

2010-10-28T03:47:00.000-07:00

Below is the complete list of all the command line parameters for OpsMgr 2007 server roles including Audit Collection. And the command line parameters for upgrading to Service Pack 1 (SP1) Release Candidate (RC)

Agent – (MOMAgent.msi)

msiexec.exe /i \\path\Directory\MOMAgent.msi /qn /l*v \logs\MOMAgent_install.log USE_SETTINGS_FROM_AD=0 MANAGEMENT_GROUP= MANAGEMENT_SERVER_DNS= ACTIONS_USE_COMPUTER_ACCOUNT=0 ACTIONSUSER= ACTIONSDOMAIN= ACTIONSPASSWORD=

Typical – (MOM.msi)

msiexec.exe /i \\path\Directory\MOM.msi /qn /l*v \logs\MOMTypical_install.log ADDLOCAL=ALL USE_SETTINGS_FROM_AD=0 MANAGEMENT_GROUP= MANAGEMENT_SERVER_DNS=

SQLSVR_INSTANCE= ADMIN_ROLE_GROUP=“DomainName/Account” ACTIONS_USE_COMPUTER_ACCOUNT=0 ACTIONSUSER= ACTIONSDOMAIN= ACTIONSPASSWORD= SDK_USE_COMPUTER_ACCOUNT=0 SDK_ACCOUNT= SDK_DOMAIN= SDK_PASSWORD=

Database --(MOM.msi)

msiexec.exe /i \\path\Directory\MOM.msi /qn /l*v \logs\MOMDB_install.log ADDLOCAL=MOMDB USE_SETTINGS_FROM_AD=0 MANAGEMENT_GROUP= SQLSVR_INSTANCE= DB_SIZE=500 ADMIN_ROLE_GROUP= DATA_DIR= LOG_DIR=

Server --(MOM.msi)

msiexec.exe /i \\path\Directory\MOM.msi /qn /l*v \logs\MOMServer_install.log ADDLOCAL=MOMServer USE_SETTINGS_FROM_AD=0 MANAGEMENT_GROUP= MOM_DB_SERVER= ACTIONS_USE_COMPUTER_ACCOUNT=0 ACTIONSUSER= ACTIONSDOMAIN= ACTIONSPASSWORD= SDK_USE_COMPUTER_ACCOUNT=0 SDK_ACCOUNT= SDK_DOMAIN= SDK_PASSWORD=

UI --(MOM.msi)

msiexec.exe /i \\path\Directory\MOM.msi /qn /l*v \logs\MOMUI_install.log ADDLOCAL=MOMUI,MOMMonadShell USE_SETTINGS_FROM_AD=0 MANAGEMENT_GROUP= ROOT_MANAGEMENT_SERVER_DNS=

WebConsole (MOM.msi)

msiexec.exe /i \\path\Directory\MOM.msi /qn /l*v \logs\MOMUI_install.log ADDLOCAL=MOMWebConsole WEB_CONSOLE_AUTH_TYPE=0 ROOT_MANAGEMENT_SERVER_DNS=

( ‘1’ is windows auth and ‘0’ is Forms auth)

Data Warehouse- (Reporting2007.msi)

msiexec.exe /i \\path\Directory\Reporting2007.msi /qn /l*v "D:\LOGS\REPORTING_INSTALL.LOG" ADDLOCAL=”MOMREPORTINGDB” SQLSVR_INSTANCE=”" MOMREPORTINGDBNAME=”SCOMDW” DB_SIZE=”1000”

Reporting Server (Reporting2007.msi)

msiexec.exe /i \\path\Directory\Reporting2007.msi /qn /l*v "D:\LOGS\REPORTING_INSTALL.LOG" ADDLOCAL=”MOMREPORTING” SQLSVR_INSTANCE="" MOMREPORTINGDBNAME=”SCOMDW” MGSERVER= PREREQ_COMPLETED="1" REPORT_SERVER_FULL_HTTP_PATH="http://%COMPUTERNAME%:80/ReportServer$INSTANCE1" DATAREADER_USER= DATAREADER_PASSWORD= DATAREADER_DOMAIN= DBWRITEACTIONSUSER= DBWRITEACTIONSPASSWORD= DBWRITEACTIONSDOMAIN=

Gateway Server (MOMGateway.msi)

msiexec /i \\path\Directory\MOMGateway.msi /qn /l*v D:\GATEWAY_SERVER_INSTALL_1.LOG ADDLOCAL=MOMGateway,MOMNonRootServer SECURE_PORT=5723 MANAGEMENT_GROUP=MyConfigGroup MANAGEMENT_SERVER_DNS= IS_ROOT_HEALTH_SERVER=0 ROOT_MANAGEMENT_SERVER_AD= ROOT_MANAGEMENT_SERVER_DNS= ROOT_MANAGEMENT_SERVER_PORT=5723 ACTIONS_USE_COMPUTER_ACCOUNT=0 ACTIONSUSER= ACTIONSDOMAIN= ACTIONSPASSWORD=

Audit Collection Server (AdtSetup.exe)

The cmd line you will use would look like this:\\PATH\Directory\AdtSetup.exe /i /s /p:ACSInstallParameters.xml

You will need to specify ACSInstallParameters.xml while passing the command line you will configure all your setting in the XML file before passing it. The XML file is attached.

For ‘/i' is for ‘install’, ‘/s’ is for ‘silent’, and ‘/p’ is for parameter (file)…

These are the command line parameter to upgrade from OpsMgr 2007 RTM to SP1 RC. Users must upgrade the RMS first which will remotely upgrade the DB. When you upgrade the Reporting Server setup will remotely upgrade the Data Warehouse as well. In order to upgrade the RMS, MS or UI you will need to run step 1 and then step 2 of the command line.

SP1RC Upgrade of RMS, MS and UI: Step 1

msiexec /p MOM2007QFEPreSP1.msp REINSTALLMODE=omus REINSTALL=ALL /qn /l*v D:\logs\QFERollup.log

SP1 RC Upgrade of RMS, MS and UI: Step 2 (DB gets upgraded automatically)

msiexec /p MOM2007SP1.msp SP1UPGRADE=1 REINSTALLMODE=omus REINSTALL=ALL /qn /l*v D:\logs\SP1Update.log

SP1 RC Upgrade of Gateway Server

msiexec /i MOMGateway.msi SP1UPGRADE=1 SET_ACTIONS_ACCOUNT=0 REINSTALLMODE=vomus REINSTALL=ALL /qn /l*v D:\logs\GatewayUpdate.log

SP1 RC Upgrade of Reporting (DW gets upgraded automatically)

msiexec /i Reporting2007.msi SP1UPGRADE=1 SET_ACTIONS_ACCOUNT=0 REINSTALLMODE=vomus REINSTALL=ALL /qn /l*v D:\logs\ReportingUpdate.log

SP1 RC Upgrade of Agent

msiexec /i MOMAgent.msi SP1UPGRADE=1 SET_ACTIONS_ACCOUNT=0 REINSTALLMODE=vomus REINSTALL=ALL /qn /l*v D:\logs\AgentUpdate.log

SP1 RC Upgrade of Audit Collection

msiexec /i AdtServer.msi ADDLOCAL=ALL REINSTALLMODE=vamus REINSTALL=ALL /qn /l*v D:\logs\ACSUpdate.log

Profile Changes in Windows Vista and Windows Server 2008

2010-10-25T06:02:00.000-07:00

Windows Vista and Windows Server 2008 introduce a number of new user profile paths and environment variables that differ from earlier versions of Windows and these changes may have an impact on scripts such as logon scripts and application install scripts. Most scripts should work correctly – VBScript scripts that use system functions to find folder paths should work as expected, however batch scripts that use environment variables or hard codes scripts will require modifications. Here’s a short run down of the changes.

The following table lists the old profile path and the corresponding new path under Windows Vista/Windows Server 2008:

Old Path	New Path
Documents and Settings	Users
Documents and Settings\Default User	Users\Default
Documents and Settings\All Users\Application Data	ProgramData
Documents and Settings\All Users\Start Menu	ProgramData\Microsoft\Windows\Start Menu
Documents and Settings\All Users\Templates	ProgramData\Microsoft\Windows\Templates
Documents and Settings\{username}\Local Settings\Application Data	Users\{username}\AppData\Local
N/A	Users\{username}\AppData\LocalLow
Documents and Settings\{username}\Application Data	Users\{username}\AppData\Roaming
Documents and Settings\{username}\Cookies	Users\{username}\AppData\Roaming\Microsoft\Windows\Cookies
Documents and Settings\{username}\NetHood	Users\{username}\AppData\Roaming\Microsoft\Windows\Network Shortcuts
Documents and Settings\{username}\PrintHood	Users\{username}\AppData\Roaming\Microsoft\Windows\Printer Shortcuts
Documents and Settings\{username}\Recent	Users\{username}\AppData\Roaming\Microsoft\Windows\Recent
Documents and Settings\{username}\SendTo	Users\{username}\AppData\Roaming\Microsoft\Windows\SendTo
Documents and Settings\{username}\Start Menu	Users\{username}\AppData\Roaming\Microsoft\Windows\Start Menu
Documents and Settings\{username}\Templates	Users\{username}\AppData\Roaming\Microsoft\Windows\Templates
N/A	Users\{username}\Contacts
Documents and Settings\{username}\Desktop	Users\{username}\Desktop
Documents and Settings\{username}\My Documents	Users\{username}\Documents
N/A	Users\{username}\Downloads
Documents and Settings\{username}\Favorites	Users\{username}\Favorites
N/A	Users\{username}\Links
Documents and Settings\{username}\My Documents\My Music	Users\{username}\Music
Documents and Settings\{username}\My Documents\My Pictures	Users\{username}\Pictures
N/A	Users\{username}\Saved Games
N/A	Users\{username}\Searches
Documents and Settings\{username}\My Documents\My Videos	Users\{username}\Videos
Documents and Settings\All Users	Users\Public
Documents and Settings\All Users\Desktop	Users\Public\Desktop
Documents and Settings\All Users\Documents	Users\Public\Documents
Documents and Settings\All Users\Favorites	Users\Public\Favorites
Documents and Settings\All Users\Documents\My Music	Users\Public\Music
Documents and Settings\All Users\Documents\My Pictures	Users\Public\Pictures
Documents and Settings\All Users\Documents\My Videos	Users\Public\Videos

Folders to take note of here are the folders in the All Users path. Many older applications that use out of date methods to resolve system folders, will resolve paths under \ProgramData when looking for common locations. For example the common desktop may be resolved as \ProgramData\Desktop, however this is actually a junction point for \Users\Public\Desktop. A DIR /A:H listing in \ProgramData folder reveals the following junction points:

H listing in \ProgramData folder reveals the following junction points:

Path	Points To
ProgramData\Application Data	ProgramData
ProgramData\Desktop	Users\Public\Desktop
ProgramData\Documents	Users\Public\Documents
ProgramData\Favorites	Users\Public\Favorites
ProgramData\Start Menu	ProgramData\Microsoft\Windows\Start Menu
ProgramData\Templates	ProgramData\Microsoft\Windows\Templates

These junction points should offer backward compatibility for older applications, however I have found that some of my installation scripts are not cleaning up shortcuts from the public desktop as expected.

There are also differences in environment variables between the new version of Windows and the older versions. Windows Server 2003 and below define the following variables relating to profiles:

ALLUSERSPROFILE=C:\Documents and Settings\All Users APPDATA=C:\Documents and Settings\aaron\Application Data HOMEPATH=\Documents and Settings\aaron TEMP=C:\DOCUME~1\aaron\LOCALS~1\Temp TMP=C:\DOCUME~1\aaron\LOCALS~1\Temp USERPROFILE=C:\Documents and Settings\aaron

Windows Vista and Windows Server 2008 define the same variables while adding a couple more.

ALLUSERSPROFILE=C:\ProgramData APPDATA=C:\Users\aaronp\AppData\Roaming HOMEPATH=\Users\aaronp LOCALAPPDATA=C:\Users\aaronp\AppData\Local ProgramData=C:\ProgramData PUBLIC=C:\Users\Public TEMP=C:\Users\aaronp\AppData\Local\Temp TMP=C:\Users\aaronp\AppData\Local\Temp USERPROFILE=C:\Users\aaronp

In practice, I’ve found that scripts that reference locations such as %ALLUSERSPROFILE%\Desktop, are not performing actions as intended and will have to be updated to use %PUBLIC% instead. Certainly something that requires more investigation.

UPDATE: Microsoft have an excellent reference document that details the profile changes in Windows Vista and how roaming profiles should managed in a Windows Vista environment. Check it out for more information that what I’ve listed here:

How to use the Powershell to get access to the SDK

2010-10-20T02:58:00.001-07:00

Preface

At our company we are in the need of creating Management Packs including a Group using discovered Properties. Therefore we have a class Windows.Computer.Extended and an attribute called ServerRole, of course the Base Class is Windows Computer.

So, the first thing we had to figure out was how to get the environment of the Operations Manager Console as well as the assemblies into a standalone Script.

Loading the OpsMgr Snapin

As you can see in the code below, we check at first if the Snapin is already loaded, if it's not, we load it.

# Check if the OpsMgr.Client PSSnapin is already loaded, if not, load it.
if ((Get-PSSnapin | Where-Object {$_.Name -eq 'Microsoft.EnterpriseManagement.OperationsManager.Client'}) -eq $null)
{
Write-Host("Loading Operations Manager Client PS Snapin")
Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client # <- that's the magical line
}
else
{
Write-Host("Operations Manager Client PS Snapin is already loaded")
}

Loading the Assemblies

Additionally we need to load the Assemblies using the PartialName. However, make sure first that these assemblies are available on the client by checking the folder: %windir%\assembly

You should have these Assemblies in there: Microsoft.EnterpriseManagement.OperationsManager and Microsoft.EnterpriseManagement.OperationsManager.Common

Once verified, all you need are the lines below:

# Load the Assemblies
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.OperationsManager")
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.OperationsManager.Common")

Setting the Location and loading the ManagementGroup

# Set Location to the RMS. Afterwards you can use any Powershell Console like the Operations Manager Console. And of course, you can use this in Powershell Modules
$rms = "localhost" # Insert the FQDN of your RMS here
Write-Host("Setting Location $rms.")
Set-Location "OperationsManagerMonitoring::" -ErrorVariable errSnapin;
$MG = New-ManagementGroupConnection -ConnectionString:$rms -ErrorVariable errSnapin;
Set-Location $rms -ErrorVariable errSnapin;

PowerShell Default Security

2010-10-20T02:52:00.000-07:00

Just getting to the PowerShell interface can be a task for some. Not that this is security related, just that you must be in the PowerShell interface before you can do much of anything. This in itself is security. There are however, some default security measures that are there by design to help ensure that anyone with malicious intent is denied their efforts.

What is in a path?

The first default security measure that you will encounter is that fact that PowerShell won’t run scripts that are in the current folder. This is so that malicious scripts attempting to intercept cmdlets and command names will fail.

For example, if you wanted to run a script named Example.ps1 from the C:\scripts folder, you would need to include the full path to the script, even if you were in the C:\scripts folder within PowerShell. Figure 1 illustrates what happens when you just try to run Example.ps1 without a path.

Figure 1: Scripts must include the path to the script to run successfully

Now, look at what happens when you run the script including the path to the script, as shown in Figure 2.

Figure 2: When the path is included with the script, the script runs without a hitch

Why am I Restricted?

Another default setting that is directly related to security is the fact that all scripts must be run interactively. This is a security measure that ensures that PowerShell scripts cannot be executed from a script based virus. This means that you must be at the PowerShell interface and run the script in real time for it to function.

This default setting is associated with the ExecutionPolicy setting within PowerShell. The ExecutionPolicy by default is set to Restricted, as shown in Figure 3.

Figure 3: The ExecutionPolicy by default is set to Restricted to secure the execution of remote PowerShell scripts

Going Beyond the Defaults

The default ExecutionPolicy in PowerShell is very secure. It does not allow for any scripts to be run, from anywhere. So, scripts that you create and put on a system won’t run. Scripts that you download from the Internet won’t run. Scripts that you even sign and secure to the nth degree won’t run. Therefore, you will need to reset the level of ExecutionPolicy before you can run your scripts.

Setting the ExecutionPolicy Level

There are four levels of the ExecutionPolicy. These four levels provide you with great security over what scripts can run and what requirements need to be associated with the script to run. The four levels and the requirements include:

Restricted
This is the default configuration in PowerShell. This setting means that no script can run, regardless of its signature. The only thing that can be run in PowerShell with this setting are individual commands.

AllSigned
This setting does allow scripts to run in PowerShell. The script must have an associated digital signature from a trusted publisher. There will be a prompt before you run the scripts from trusted publishers. This exposes you to running signed, but malicious, scripts.

RemoteSigned
This setting allows scripts to be run, but requires that the script and configuration files that are downloaded from the Internet have an associated digital signature from a trusted publisher. Scripts run from local computer don’t need to be signed. There are no prompts before running the script. Still exposes you to scripts that are signed, yet malicious.

Unrestricted
This is not a suggested setting! This allows unsigned scripts to run, including all scripts and configuration files downloaded from the Internet. This will include files from Outlook and Messenger. The risk here is running scripts without any signature or security.

To set anyone of these levels, just type set-executionpolicy , as shown in Figure 4.

Figure 4: Setting the ExecutionPolicy is as easy as running the set-executionpolicy command.

Using Group Policy

PowerShell is great, but if scripts can’t run on computers in your environment, it does have limitations. First, you must get PowerShell on each computer. Since PowerShell is installed via an EXE, it is very easy to install the application. You can either use a ZAP file and push it out using Group Policy, or you can use your current centralized method of installing applications. Keep in mind that PowerShell is considered a hotfix, so Windows Update can also push out the installation of PowerShell.

After you get PowerShell installed, we just investigated that you need to enable scripts to run. With the ExecutionPolicy set at Restricted as a default, you need to configure every computer to run scripts, that will run scripts. This could take days if you are trying to do this manually.

However, you can also use Group Policy to get this done for you. Of course, you could create your own Administrative Template (ADM file) to make this change, or download the ADM template that Microsoft provides for you. I suggest you do the latter by downloading the ADM template.

After downloading, you will need to install the MSI. I will admit, it is not the cleanest or most efficient install. After installation, the ADM file is shoved under the C:\program files\Microsoft Group Policy folder. If nothing else, this is great security! The file you need to import into the Group Policy Object Editor is PowerShellExtensionPolicy.ADM. After importing, you will have two new nodes in your Group Policy Object. One will be at Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell and the other at User Configuration\Administrative Templates\Windows Components\Windows PowerShell, as shown in Figure 5.

Figure 5: PowerShell ADM template adds settings to Computer Configuration and User Configuration for script execution

When you go to configure this policy, you will see that you have three options for a setting, as shown in Figure 6.

Figure 6: The ExecutionPolicy settings for PowerShell in a GPO

Balancing Number of SCOM Agent Per Management Server using PowerShell

2010-10-15T02:44:00.001-07:00

I came across a situation yesterday in one of the clients SCOM environment:

They currently have a single SCOM management group setup as the following:

all SCOM management servers (including the root management server) are located on the same segment of the network.
internal agents (from the same forest) are reporting to management server #1 and #2.
External agents (from different forests) are reporting to management server #3 and #4 through firewall.
SCOM is not integrated to AD – Therefore primary and failover management servers are not automatically assigned to agents.

I needed to achieve:

agents are evenly distributed to the Internal and external management servers.
all other management servers in the same group are assigned as failover management servers.
For Example, there are 513 agent managed computers in internal network. They need to be evenly spread between management server #1 and #2 (so one management server will have 256 agents and the other will have 257 agents). All agents hanging off management server #1 will have #2 assigned as failover management server and vice versa.

I wrote this PowerShell script for this task. if you create a Windows scheduled task and run it on a regular basis, you’ll ensure all your SCOM agents are evenly assigned to a group of management servers and have correct settings for failover management servers.

The script does so by doing the following:

Work out total number of agents that are currently hanging off the management servers specified in the script (line 33-37):
Work out which management servers are over average and which ones are below average
Go through each one that’s over the average, move agents to another random management server until it reaches the average number.
after each agent move, check the destination management server, make sure it is still under the average number, otherwise, remove it from the pool of under average management servers.
Go through the remaining agents on each management server and make sure they are set to use all the other management servers as failover management servers.

Note: PowerShell Version 2 is required to run this script! This script can only run on the root management server. if you want to run it somewhere else, please modify line 15 of the script to have the correct FQDN of your RMS server.

User state migration fails on a SCCM 2007 SP1 client or on a SCCM 2007 SP2 client after you install security update 974571

2010-09-15T08:33:00.000-07:00

http://support.microsoft.com/?scid=kb%3Ben-us%3B977203&x=12&y=6

Important To resolve this issue, install this hotfix on all System Center Configuration Manager 2007 Service Pack 1 (SP1) site servers and on all System Center Configuration Manager 2007 Service Pack 2 (SP2) site servers. Then, deploy this hotfix to all clients.

This hotfix resolves this issue for any new client certificates that are generated. To correct the current certificates, run the CCMCertFix utility that is in this package on all the Configuration Manager SP1 clients and all the Configuration Manager SP2 clients.

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing this specific problem.

If the hotfix is available for download, there is a "Hotfix download available" section at the top of this Knowledge Base article. If this section does not appear, submit a request to Microsoft Customer Service and Support to obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site:

http://support.microsoft.com/contactus/?ws=support (http://support.microsoft.com/contactus/?ws=support)

Note The "Hotfix download available" form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.

Prerequisites

To apply this hotfix, System Center Configuration Manager 2007 Service Pack 1 (SP1) or System Center Configuration Manager 2007 Service Pack 2 (SP2) must be installed.

Lots Of Operations Manager Updates

2010-09-07T06:54:00.000-07:00

Microsoft released lots of updates for Operations Manager over the last couple of weeks. There are lots of updates to management packs, too many for me to go posting them at this time of night. Have a look on the catalogue and you’ll see them. Or check your console if you’re using OpsMgr 2007 R2.

Most importantly is KB971541, Update Rollup for Operations Manager 2007 Service Pack 1.

“The Update Rollup for Operations Manager 2007 Service Pack 1 (SP1) combines previous hotfix releases for SP1 with additional fixes and support of SP1 roles on Windows 7 and Windows Server 2008 R2. This update also provides database role and SQL Server Reporting Services upgrade support from SQL Server 2005 to SQL Server 2008.

The Update Rollup includes updates for the following Operations Manager Roles:

Root Management Server, Management Server, Gateway Server
Operations Console
Operations Management Web Console Server
Agent
Audit Collection Server (ACS Server)
Reporting Server

The following tools and updates are provided within this update which may be specific to a scenario:

Support Tools folder – Contains SRSUpgradeTool.exe and SRSUpgradeHelper.msi (Enables upgrade of a SQL Server 2005 Reporting Server used by Operations Manager Reporting to SQL Server 2008 Reporting Server)
Gateway folder – Contains a MSI transform and script to update MOMGateway.MSI for successful installation on Windows Server 2008 R2
ManagementPacks folder – Contains an updated Microsoft.SystemCenter.DataWarehouse.mp which requires manual import

For a list of fixes and tools addressed by this update rollup, see KB971541.

This update is supported for application on System Center Operations Manager 2007 Service Pack 1 only.

Feature Summary

The System Center Operations Manager 2007 SP1 Rollup 1 contains:

All binary hotfixes released since Service Pack 1 release
Support for Windows 7 and Windows Server 2008 R2
Operational and DataWarehouse database support on Windows Server 2008 R2
Additional stability hotfixes”

Requirements

Supported Operating Systems: Windows 7; Windows Server 2003; Windows Server 2008; Windows Server 2008 R2; Windows Vista; Windows XP
System Center Operations Manager 2007 Service Pack 1

Instructions

This update must be applied to each computer that meets the following criteria:

Hosts a Microsoft Operations Manager Root Management Server
Hosts a Microsoft Operations Manager Management Server
Hosts a Microsoft Operations Manager Operations Console
Hosts a Microsoft Operations Manager Web Console Server
Hosts a Microsoft Operations Manager Reporting Server
Hosts a Microsoft Operations Manager Manually installed Agent
Hosts a Microsoft Operations Manager ACS Server

Before applying this update it is strongly recommended that Operations Manager databases, Management Server, Report Server and Web Console roles be backed up.

To extract the files contained in this update and installation of the update on the Operations Manager roles above:

Copy the file – SystemCenterOperationsManager2007-SP1-KB971541-X86-X64-IA64-locale.MSI – To either a local folder or accessible network shared folder.
Run the file – SystemCenterOperationsManager2007-SP1-KB971541-X86-X64-IA64-locale.MSI – locally on each applicable computer that meets the predefined criteria.
You can run SystemCenterOperationsManager2007-SP1-KB971541-X86-X64-IA64-locale.MSI from either Windows Explorer or from a command prompt.
Select the appropriate role to update from the Operations Manager 2007 Software Update dialog.

NOTE: To run this file on Windows Server 2008 you must run this file from a command prompt which was executed with the Run as Administrator option. Failure to execute this Windows installer file under an elevated command prompt will not allow display of the System Center Operations Manager 2007 Software Update dialog to allow installation of the hotfix”.

How to Manually Publish the Default Management Point to DNS

2010-09-06T06:40:00.001-07:00

If your DNS servers do not support automatic updates but do support service location records, and you want to publish the Configuration Manager 2007 default management point to DNS, you can manually publish the default management point. To accomplish this, you must manually specify the service location resource record (SRV RR) in DNS.

Configuration Manager 2007 supports RFC 2782 for service location records, which have the following format:

_Service._Proto.Name TTL Class SRV Priority Weight Port Target

For guidance on entering this DNS record for a site's default management point, follow this procedure.

To manually publish the default management point to DNS

In the Configuration Manager console, specify the intranet FQDNs of site systems.
In DNS, configure the DNS zone for the site's default management point, and enter host (A) records for the intranet FQDNs of the site systems.
Enter an SRV record with the following fields:
- _Service: Enter _mssms_mp_, where is the management point's site code.
- ._Proto: Specify ._tcp.
- .Name: Enter the DNS suffix of the management point, for example contoso.com.
- TTL: Enter 14400, which is four hours.
- Class: Specify IN (in accordance with RFC 1035).
- Priority: This field is not used because there is only one management point published for each site.
- Weight: This field is not used because there is only one management point published for each site.
- Port: Enter the port configured for Configuration Manager 2007 client requests, for example 80 for a mixed mode site and 443 for a native mode site.
- Target: Enter the intranet fully qualified domain name specified for the site system configured with the default management point site role.

How to configure SCCM in Multiple Active Directory Forests

2010-09-06T06:39:00.000-07:00

How to configure SCCM in Multiple Active Directory Forests

How to configure SCCM in Multiple Active Directory Forests

1. Introduction:

Configuration Manager 2007 clients on the intranet use Active Directory Domain Services as their primary method of service location and configuration. If you have clients that reside in a separate forest, they will not be able to retrieve information that is published to Active Directory Domain Services by their assigned site server.

For these clients to be managed, you must ensure that alternative methods are available for the following:

• Site compatibility check to complete site assignment.
• Service location for management points, and the server locator point if this is not directly assigned.
• Native mode configuration (Optional).

We have two domains in diffrient forest, first domain call primary.local domain and this domain will contain SCCM Server, 2nd domain is Domain.com which contain clients that should be managed by SCCM in Primary domain.

To successfully deploy CCM client and allow SCCM server to manage multiple AD forests, we should do the following configuration:

1- Configure Boundaries correctly to allow SCCM client agent distribution to clients which are located in 2nd trusted domain.
2- Configure Push Installation method switches in the client installation properties to allow clients in 2nd domain to find SLP.
3- Configure Discovery method to allow SCCM Server to discover 2nd trusted domain.
4- Add Server Locator Point “SLP” to SCCM site system role.
5- CCM Admin account should be local admin for client computers in 2nd domain.
6- Publish SLP Manually in WINS for 2nd trusted domain.
7- Enable WINS on the client PC's in 2nd domain.

2.Configure Boundaries

In Normal scenario it’s recommended to Active directory Site as boundaries to install CCM Client, but in this case all computers which is located in another forest will not be able to receive CCM client agent from SCCM Server.

In this case we have to configure “IP Subnet” or “IP Address Range”, to allow Clients in 2nd domain to receive client agent.

3.Discovery method:

In normal scenario, it’s recommended to enable “Active Directory Site System” and select Local domain, but this settings will discover only MOWASALAT.LOCAL domain.

To discover 2nd domain name we have to make sure that sure Active Directory System discovery is configured with LDAP://DC=domain,DC=COM LADP path. Then run discovery and check adsysdis.log to confirm if it is able to search the domain in other forest.

LDAP Query:

LDAP://DC=domain,DC=com

4.Add Server Locator Point:

Server locator points are used in a Configuration Manager 2007 hierarchy to complete client site assignment on the intranet and help clients find management points when they cannot find that information through Active Directory Domain Services.

So we need to add Server Locator Point to Site System role.

5.Configure Push Installation method switches:

It would also help if you add the following switches in the client installation properties, especially SMSSLP switch as clients in the other forest won’t be able to find SLP in their forest.

DNS and NetBIOS Name resolution should work between forests for this to work.

Switches:

SMSITECODE=S01 SMSMP=SRV-SCCM01.Primary.com
SMSSLP=SRV-SCCM01 FSP=SRV-SCCM01

6.Publish SLP Manually in WINS:

To resolve this issue, manually add an SMS_SLP record and an SMS_MP record to the Windows Internet Name Service (WINS) database. To do this, use one of the following methods, depending on the operating system that you are running:
To manually add the SMS_SLP and SMS_MP records to WINS in Microsoft Windows Server 2003 for 2nd domain, follow these steps:

1. Click Start, click Run, type cmd, and then click OK.
2. Type the following commands at the command prompt, and then press ENTER after each command:
o netsh
o wins
o server
3. Add the SMS_SLP record. To do this, type the following command, and then press ENTER:
add name name=SMS_SLP endchar=1A rectype=0 ip={ip addresses}
Note Make sure that you enclose the IP address in braces ("{ }").
4. Add the MP_SMSSiteCode record. To do this, type the following command, and then press ENTER:
add name name=MP_SMSSiteCode endchar=1A rectype=0 ip={ip addresses}

Note: Make sure that you enclose the IP address in braces ("{ }"). The SMSSiteCode variable represents the three-character string (letters, integers, or a combination of both) that is the code for the SMS site to which the Management Point belongs. It is displayed in the SMS Administrator Console.

7.Publish MP in DNS:

We should publish MP on DNS and make sure MP FQDN is resolvable from the clients in another domain.

To publish the default MP in DNS, Site Management -> S01-Primary -> Properties -> Advanced Tab -> publishes the default Management Point in DNS.

Unable to see Advertisements in SCCM 2007

2010-08-05T07:43:00.000-07:00

I had installed an Admin Console version ConfigMgr07 SP1, and since introducing ConfigMgr07 SP2 into the environment, those Admin Consoles no longer list Advertisements". That is a 100% known technical issue, with a technical solution.

For ANY AdminConsole Installations, you need to upgrade those console installations to be Admin Console ConfigMgr07 SP2.

powershell comand to renew self signed certificate

2010-07-28T00:31:00.000-07:00

1. - Get-ExchangeCertificate | fl
2. - (copy the thumbprint of the expired SSL)
3. - Get-ExchangeCertificate -Thumbprint | New-ExchangeCertificate
4. - Get-ExchangeCertificate | fl
5. - (copy the thumbprint of the "new" SSL)
6. - Enable-ExchangeCertificate -Services:"IIS,smtp,imap,pop"
/!\ select only the services you need to renew selfsigned certificate /!\

DB Maintenance: Rebuild Index Task always fails on OperationsManagerDW [SCOM database]

2010-07-05T02:33:00.001-07:00

Problem Description

=======================================

We encountered a situation where we were trying to execute a maintenance plan to rebuild the index of OperationsManagerDW database. However, the maintenance plan fails to complete.

In the Maintenance Plan log, the following paragraph was found:

Rebuild Index Task ()

Rebuild index on Local server connection

Databases that have a compatibility level of XX (SQL Server version XX.0) will be skipped.

Databases: All databases

Object: Tables and views

Original amount of free space

Task start: 2010-03-01T03:05:29.

Task end: 2010-03-01T03:08:48.

Failed:(-1073548784) Executing the query "ALTER INDEX [PK__EventSta__XXXXXXXXXXXXXXX] ON [E..." failed with the following error: "Cannot find index 'PK__EventSta__ XXXXXXXXXXXXXXX '.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

Additionally, the same error is encountered when you try to run a Rebuild Index script via SSMS

What’s happening here? Let’s see

What is causing this:

=======================================

§ To begin with, this was little strange as we verified that all indexes existed before started the maintenance plan

§ On further, probing we verified that, SCOM drops and recreates table “Event Stage” every minute

§ To verify, we generated T-SQL Script and copied the index alter script for problematic table

§ Also ran the script via SSMS and got same error

§ SELECT * from sys.objects where name like 'Event Stage%' gave us object id and creation date

§ Ran above SELECT again after a minute and now got a new name and creation date…..?

So here’s what is happening.

o When we run a rebuild index script, it first collect index names and then tries to rebuild them.

o In this specific case, it is getting an indexes name say PK__EventSta__XXXXXXXXXXXXXXX, however the table/index is getting dropped and recreated now with a different name.

o This is causing the above error.

§ To confirm if the table has been modified, we also verified same using SQL Standard Report “Schema Change History”

Then how can I Re-index OperationsManagerDW database to ensure good performance

===================================================================

§ With a little more re-search; we verified that it is NOT required to Re-index OperationsManagerDW database as Reindexing is already taking place against the OperationsManagerDW database for some of the key tables. The functionality is built into the product. For more details, on OperationsManagerDW Self-maintenance refer this post

§ What we need to ensure - is that any default DBA maintenance tasks are neither redundant nor conflicting with SCOM OperationsManagerDW built-in maintenance.

Steps to reproduce the issue:

=======================================

1. On OperationsManagerDW SQL database

2. Create a simple maintenance with re-indexing task

3. “Select Report Options” choose a log location

4. Save and execute the maintenance plan and allow this to fail.

5. Verify the error in logs

Hope this will help!

Manually configure Option 60 for PXE boot on a DHCP Server hosting an SCCM PXE Point

2010-07-02T06:12:00.001-07:00

While setting up a new PXE point server for SCCM (System Center Configuration Manager), I discovered an interesting problem. Since the servers we have are all Windows 2003 SP 2, I no longer have to walk through from RIS to WDS (Windows Deployment Services) to installing the PXE point. However, this was the first server I’ve done that didn’t start life as a normal WDS server. Normally, since the PXE point would be on a server that is also DHCP, you have to choose the option to set Option 60 on DHCP. Since SCCM handles all the WDS, this is no longer an options. What to do? Well, all you need to do is use the NETSH command. Here’s how:

At a command prompt:

NETSH

NETHSH>DHCP server \\nameofserver

add optiondef 60 PXEClient String 0 comment=”Option added for PXE Support”

set optionvalue 60 STRING PXEClient

show optionvalue all

exit

Remember, replace nameofserver with the name of the DHCP server being modified. The final command lists the value so you can verify your settings.

Script for deleting drivers on mass on sccm Console

2010-07-01T02:11:00.000-07:00

Code Snippet

' Connect to the SMS namespace

siteNamespace = GetSiteNamespace()

SET objWMIService = GetObject( "winmgmts:{impersonationLevel=impersonate}!"_

&siteNamespace)

SET drivers = objWMIService.ExecQuery("SELECT * From SMS_Driver")

numDriversDeleted = 0

' Process the results

FOR EACH driver in drivers

driver.Delete_

numDriversDeleted = numDriversDeleted + 1

NEXT

WScript.Echo "Successfully deleted "&numDriversDeleted&" drivers."

' Utility function to search for the site namespace

FUNCTION GetSiteNamespace()

' Find SMS Provider

SET objSMSNamespace = GetObject("winmgmts:{impersonationLevel="&_

"impersonate}!\\.\root\sms")

SET results = objSMSNamespace.ExecQuery("SELECT * From "&_

"SMS_ProviderLocation WHERE ProviderForLocalSite = true")

' Process the results

FOR EACH r in results

namespacePath = r.NamespacePath

NEXT

' Fail if we did not find the site

IF namespacePath = "" THEN

WScript.Echo "Failed to locate SMS provider."

WScript.Quit 1

END IF

' Return

GetSiteNamespace = namespacePath

END FUNCTION

You must copy this code on a .vbs file...

Multiple Connections to a server or shared resource by the same user, using more than one user name, are not allowed with MDT 2010

2010-06-21T05:40:00.000-07:00

The error encountered in the ZTIUserState.log and BDD.log, “Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again..”

A change has been made in MDT 2010 to deal with mappings to lower-level directories, which has caused some issues when the lowest level part of the path doesn’t exist. MDT attempts to map it, but that fails because the folder doesn’t exist, and is not able to create the folder because were not mapped. While this doesn’t cause the deployment to fail, it leaves you with some nasty errors in the logs and you might see this in the Summary Screen:

To fix the problem the ZTIUtility.vbs file needs to be edited in the scripts folder. Open the file and replace the following code in the MapNetworkDriveEX function:

Case Else

‘ Case &h800704C3 ‘ Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed.

‘ Case &h8007052E ‘ Logon failure: unknown user name or bad password.

‘ There was a some kind of fatal error.

If ErrDesc <> “” then

MapNetworkDriveEx = ErrDesc

Else

MapNetworkDriveEx = “Unable to map UNC Path ” & sShare & ” :” & “( 0x” & hex(HasError) & ” ) “

End if

oLogging.CreateEntry MapNetworkDriveEx & “”, iLogType

Exit function

End select

With this code:

Case Else

Err.Clear

On Error Resume Next

oNetwork.MapNetworkDrive chr(sDrive)&”:”, sShare, False

HasError = err.number

ErrDesc = err.Description

On Error Goto 0

If Err.Number <> 0 Then

‘ There was a some kind of fatal error.

If ErrDesc <> “” then

MapNetworkDriveEx = ErrDesc

Else

MapNetworkDriveEx = “Unable to map UNC Path ” & sShare & ” :” & “( 0x” & hex(HasError) & ” ) “

End if

oLogging.CreateEntry MapNetworkDriveEx & “”, iLogType

Exit function

Else

Exit Function

End If

End select

“Health Service Script” and “Health Service Modules” events are generated indicating SQL Server 2008-related scripts are failing

2010-06-07T22:43:00.000-07:00

Problem: On agent-managedjavascript:void(0) systems that have SQL Server 2008 installed, but where SQL-DMO has not been installed from the Microsoft SQL Server 2005 Backward Compatibility Components package, scripts will fail to execute, resulting in the loss of monitoring-related data and events such as those shown below:

Log Name: Operations Manager

Source: Health Service Modules

Event ID: 4000

Level: Error

Description: GetSQL2008DBSpace.js : 0

Resolution: Follow the steps to install SQL-DMO in the Other Requirements section of this guide.

message: Drivers[The ConfigMgr provider reported an error*]

2010-06-07T14:20:00.000-07:00

SCCM 2007 and SQL Server 2008

For fix it:

1) Set compability mode to SMS_sitecode database (Managment Studio --> right click SMS_sitecode database --> Options --> Set Compability level to SQL Server 2005 (90)
2) Restart SCCM server (hardware)

DNS 2008 External name resolution monitor is always in “critical” state in SCOM 2007 R2

2010-06-07T13:31:00.000-07:00

My external name resolution monitor for my DNS 2008 MP was always coming up critical. See below:

The server health status would roll up to critical and consequently would cause AD alerts to come up:

The issue here is in the way that the actual monitor is performing the test because I can resolve external names. I tested this in my DNS server and clients both by using my DNS server with forwarders or with Root Hints.

Here is what the test is actually doing:

Now, from a Health Explorer perspective, here is the actual test:

So the DNS 2008 external name resolution monitor is performing an ns query on www.microsoft.com using my DNS server.

This will actually fail. Well, sort of… See below:

There was an output. So what’s the issue?

Kevin Holman (OpsMgr MVP) blogged about this issue some time ago. See here:

http://blogs.technet.com/kevinholman/archive/2009/02/24/dns-mp-external-resolution-monitor-always-in-a-critical-state.aspx

Kevin was correct in his post that the actual issue with this specific monitor test is that we are attempting to perform an ns query against a host (www.microsoft.com and not a zone: microsoft.com).

If we modify the test as follows, the output returns the list of name servers:

That’s great. We get the list of name servers. What’s interesting here, is this is the expected output.

How would we have known that from the test? Here is a more important question: Why are we even using an ns query when the monitor is performing test lookups against external addresses?

More on that, for now let’s just correct the monitor test so that our environment reports correctly.

OK, so now we know how to modify the monitor to work correctly with an ns test. We should override this monitor for all objects of class: DNS server since the test itself is flawed and not the monitor per se on any particular DNS Server. Make sure to save your override in a relevant unsealed management pack if you need to get at it easily later.

It may take up to 5 minutes for your alert to clear once you have made the override.

OK, so the alert closed itself since the default monitor behavior was configured to do so.

The Computer health status is also Healthy now.

We can also see that the name resolution test is fixed as well. All is good.

Now, why did the ns query not liking the output… We did get an output from the original test remember?

Well, I found that out by digging. This post below confirms it:

http://www.gasmi.net/nslman.html

OK so we sort of have the answer for what was wrong with the test. That still does not really answer what was wrong with the output that we received…

When a monitor is configured, a health status is equated to something and it is still unclear what constitutes “unhealthy” for this test.

I will expand on that in a separate post as I actually discover the answer.

Now for the other question:

Why are we even using an ns query when the monitor is performing test lookups against external addresses?

I think that the type of test being performed is not what we are looking for.

A name resolution given a host name (ex. www.microsoft.com) would resolve to an IP address by checking a host (A) record on some DNS server. See below:

So given the name of the monitor “External Address Resolution” we should be performing a query against “A” or host records. Let’s try that.

OK, the query seems to work as expected.

To make the change quickly, I’ll override the monitor properties for all objects of class: DNS Server using the Closed Alerts view that I created in my environment.

What I did was to put the Host parameter back as www.microsoft.com but to change the Query Type parameter from ns to A.

My Health status is Healthy and I have no new Active Alerts!

Thanks to http://myitforum.com/cs2/blogs/bbird/archive/2010/03/17/dns-2008-external-name-resolution-monitor-is-always-in-critical-state-in-scom-2007-r2.aspx

How to Configure Windows Server 2008 for Site System Roles

2010-06-04T01:05:00.000-07:00

Here is a blurb I actually found on the Microsoft TechNet forums as I was searching for answers to my Windows 2008/SCCM SP1 RC Lab issues and I thought it was worth repeating again here for those in the same boat.

Here is the blurb from the help information that will be in the RTM release of SP1.

Topics referencing Configuration Manager 2007 SP1 and Configuration Manager 2007 R2 are pre-release documentation and are subject to change in future releases. Blank topics are included as placeholders.

Topic last updated—March 2008

Microsoft System Center Configuration Manager 2007 requires the WebDAV component to be installed and enabled on the management points and BITS-enabled distribution points. The WebDAV component is not included in Windows Server 2008 operating system.

Note

The information in this topic applies only to Configuration Manager 2007 SP1.

You must download, install, and configure WebDAV manually on management points and BITS-enabled distribution points running Windows Server 2008. On BITS-enabled distribution points, you might also have to edit the requestFiltering section of the applicationHost.config file if your packages contain extensions that are blocked.

Important

Enabling WebDAV and modifying the requestFiltering section for the Web site increases the attack surface of the computer. Enable WebDAV only when required for management points and BITS-enabled distribution points. If you enable WebDAV on the default Web site, it is enabled for all applications using the default Web site. If you modify the requestFiltering section, it is modified for all Web sites on that server. The security best practice is to run Configuration Manager 2007 on a dedicated Web server. If you must run other applications on the Web server, use a custom Web site for Configuration Manager 2007.

Site servers and branch distribution points require Remote Differential Compression (RDC) to generate package signatures and perform signature comparison. RDC is not installed by default on computers running Windows Server 2008.

Reporting points running Windows Server 2008 require ASP.NET with Windows Authentication to be enabled.

To install and configure WebDAV for BITS-enabled distribution points and management points

1. In Server Manager, on the Features node, start the Add Features Wizard.
* On the Select Features page, select BITS Server Extensions.
* When prompted, click Add Required Role Services to add the dependent components, including the Web Server (IIS) role.
* On the Select Features page, select Remote Differential Compression, and then click Next.
* On the Web Server (IIS) page, click Next.
* On the Select Role Services page, under IIS 6 Management Compatibility, select IIS 6 WMI Compatibility.
* Under Application Development, select ASP.NET and, when prompted, click Add Required Role Services to add the dependent components.
* Under Security, select Windows Authentication, and then click Next.
* On the Confirmation page, click Install, and then complete the rest of the wizard.
2. Download the x86 or x64 version of WebDAV at http://go.microsoft.com/fwlink/?LinkId=108052.
3. Run either webdav_x86_golive.msi or webdav_x64_golive.msi, depending on your processor.
4. Enable WebDAV and create an Authoring Rule, as follows:
* Open Internet Information Services (IIS) Manager.
* In the Connections pane, expand the Sites node in the tree, and then click SMSWEB if you are using a custom Web site or click Default Web Site if you are using the default Web site for the site system.
* In the Features View, double-click WebDAV Authoring Rules.
* When the WebDAV Authoring Rules page is displayed, in the Actions pane, click Enable WebDAV.
* After WebDAV has been enabled, in the Actions pane, click Add Authoring Rule.
* In the Add Authoring Rule dialog box, under Allow access to, click All content.
* Under Allow access to this content to, click All users.
* Under Permissions, click Read, and then click OK.
5. Change the property behavior as follows:
* In the WebDAV Authoring Rules page, in the Actions pane, click WebDAV Settings.
* In the WebDAV Settings page, under Property Behavior, set Allow anonymous property queries to True.
* Set Allow Custom Properties to False.
* Set Allow property queries with infinite depth to True.
* If this is a BITS-enabled distribution point, under WebDAV Behavior, set Allow access to hidden files to True.

Important

Allow access to hidden files is not required for management points and should not be configured.

* In the Action pane, click Apply.
1. Close Internet Information Services (IIS) Manager.
2. Verify that there are no error messages for the distribution point or management point role, as follows:
* In the Configuration Manager console, navigate to System Center Configuration Manager / System Status / Site Status / - / Site System Status.
* Check the status of the management point and distribution point roles.
* If you see any errors, right-click the role, click Show Messages, and then click All to see more detail.

To modify the requestFiltering section on BITS-enabled distribution points

1. On the BITS-enabled distribution points, open %windir%\System32\inetsrv\config\applicationHost.config.
2. Search for the section.
3. Determine the file extensions that you will have in the packages on that distribution point. For each file extension that you require, change allowed to true.
4. For example, if your package will contain a file with an .mdb extension, change the line to .

Important

Allow only the file extensions required for your packages.

1. Save and close applicationHost.config.

To add Remote Differential Compression to site servers and branch distribution points

1. In Server Manager, on the Features node, start the Add Features Wizard.
2. On the Select Features page, select Remote Differential Compression, and then click Next.
3. Complete the rest of the wizard.

To enable ASP.NET and Windows Authentication on the reporting point

1. In Server Manager, on the Roles node, start the Add Roles Wizard.
2. On the Select Server Roles page, select Web Server (IIS).
3. When prompted, click Add Required Role Services to add the dependent components.
4. On the Select Server Roles page, click Next.
5. Under Application Development, select ASP.NET and, when prompted, click Add Required Role Services to add the dependent components.
6. Under Security, select Windows Authentication, and then click Next.
7. On the Confirmation page, click Install, and then complete the rest of the wizard.

Install KMS server

2010-05-21T06:51:00.000-07:00

Key Management Server (KMS) Fast Activation Walkthrough

This article deals with procedures that are needed for deploying Volume Activation v2.0.

Volume Activation v2.0 activates Windows Vista and Windows Server 2008 operating systems for volume licensing customers. You can choose to implement volume activations using two methods:

Key Management Service (KMS) - can be activated in any environment including secured isolated networks.

Multiple Activation Key (MAK) - online activation - must have an Internet connection.
Licensing Keys:

it's important to understand the differences between the licensing keys, usually these keys can be found under https://licensing.microsoft.com (MVLS) using your account under volume license keys section.

For the KMS server, you'll need one of the followings products keys according to the version installed:

Windows Server 2008 Std/Ent - KMS
Windows Srv 2008 Data Ctr/Itan- KMS
Windows Web Srv 2008-KMS

For KMS clients (actually, all of the other computers) including windows 2008 server and windows vista you'll need one of the corresponding keys as follows:

Windows Vista Business - YFKBB-PQJJV-G996G-VWGXY-2V3X8
Windows Vista Business N - HMBQG-8H2RH-C77VX-27R82-VMQBT
Windows Vista Enterprise - VKK3X-68KWM-X2YGT-QR4M6-4BWMV
Windows Vista Enterprise N - VTC42-BM838-43QHV-84HX6-XJXKV
Windows Server 2008 Datacenter - 7M67G-PC374-GR742-YH8V4-TCBY3
Windows Server 2008 Datacenter without Hyper-V - 22XQ2-VRXRG-P8D42-K34TD-G3QQC
Windows Server 2008 for Itanium-Based Systems - 4DWFP-JF3DJ-B7DTH-78FJB-PDRHK
Windows Server 2008 Enterprise - YQGMW-MPWTJ-34KDK-48M3W-X4Q6V
Windows Server 2008 Enterprise without Hyper-V - 39BXF-X8Q23-P2WWT-38T2F-G3FPG
Windows Server 2008 Standard - TM24T-X9RMF-VWXK6-X8JC9-BFGM2
Windows Server 2008 Standard without Hyper-V - W7VD6-7JFBR-RX26B-YKQ3Y-6FFFJ
Windows Web Server 2008 - WYR28-R7TFJ-3X2YQ-YCY4H-M249D

These keys are static and should be used for any new computer you install, if you download the product from the MVLS site, you do not need to type the key since one of these keys will automatically be used and the machine will be activated if a KMS server exists.

For any computer that is not connected to the network or will not be able to reconnect to the network within 180 days a MAK key is required for activation against the Internet.

The KMS server can run on either windows 2008, windows vista or windows 2003 with SP1 and later, however installing it on windows 2003 requires you to download the appropriate installation files for KMS v1.1 and described in the next section.

Installing the KMS server on a Windows Vista or Windows 2008 Server:

Important note, whenever a command prompt is needed make sure to run it using the run as administrator option.

To install the KMS server, type the following at the command prompt:
cscript C:\windows\system32\slmgr.vbs /ipk (One of the keys from section one).

Before you activate the KMS host, consider the following:

To activate Windows Vista, you must have at least 25 computers running Windows Vista or Windows Server 2008 that are connected together; for Windows Server 2008, the minimum is 5 computers.

Computers that are activated through KMS must be reactivated every six months by connecting to your organization's network.

Activating the KMS on windows 2008 server or windows vista:

For online activation, type the following at the command prompt and then press Enter:
cscript C:\windows\system32\slmgr.vbs /ato
For offline (telephone) activation, type the following at the command prompt:
slui.exe 4
the next step is to restart the Software Licensing Service using the following command:

net stop slsvc && net start slsvc

Installing the KMS server on a Windows 2003 Server:

Download Key Management Service for Windows Server 2003 from the Microsoft Download Center at http://go.microsoft.com/fwlink/?LinkID=82964 for x86 systems or http://go.microsoft.com/fwlink/?LinkId=83041 for x64 systems

After installing both KMS v1.0 and the patch for v1.1, install the KMS key, type the following at the command prompt, and then press Enter:
cscript C:\windows\system32\slmgr.vbs /ipk One of the keys from section one).

Activating the KMS server on windows 2003 server:

For online activation, type the following at the command prompt and then press Enter:
cscript C:\windows\system32\slmgr.vbs /ato
For offline (telephone) activation, type the following at the command prompt:
slui.exe 4
the next step is to restart the Software Licensing Service using the following command:

net stop slsvc && net start slsvc

Testing the KMS server configuration:

The KMS server should publish its SRV records in your domain DNS, it is a good thing to test that these records exists using the following command:

nslookup -type=srv _vlmcs._tcp

you should see something similar to that:

_vlmcs._tcp.domain.net SRV service location:
priority = 0
weight = 0
port = 1688
svr hostname = kmsserver.domain.net
kmsserver.domain.net internet address = x.x.x.x

Please note that the KMS server listens on port TCP 1688, if you need to activate KMS client over a firewall, make sure to open this port as necessary.

now, just try to activate manually one of your clients or servers using the following command:

cscript C:\windows\system32\slmgr.vbs /ato

If you need to activate a client in an isolated network, you can assign it the KMS server's static IP address instead of using DNS using the following command:

slmgr -skms kms-ip-address

After that, don't forget to run the activation command:

cscript C:\windows\system32\slmgr.vbs /ato

slmgr script fonction

2010-05-20T05:30:00.001-07:00

slmgr -dli (this will display the current activation/licensing info of the pc your on)

slmgr -ipk xxxx-xxxx-xxxx-xxxx (allows you to replace the current product key with the specified)

slmgr -xpr (shows expiration date of current license)

slmgr -upk (uninstalls current product key and i would assume puts license back to trial state)

slmgr -ato (activates current pc’s license)

slmgr -skms activationservername
or
slmgr -skms port
or
slmgr -skms activationservername:port (sets KMS server used for activation and/or port, ie slmgr -skms 192.168.10.1:8090 or slmgr -skms KMSServer:8090)

slmgr -rearm (resets the licensing status of the machine)

slmgr -ckms (clears the name of KMS server used to default and port to default)

Deploy ConfigMgr packages based on Active Directory Group Membership

2010-05-17T07:20:00.000-07:00

When your group contains computer / system objects, use the following query for the collection:
select SMS_R_SYSTEM.Name from SMS_R_System where SMS_R_System.SystemGroupName = "yourdomain\\Microsoft Office 2007"

When your group contains user objects, use the following query for the collection:
“select * from sms_r_user where sms_r_user.usergroupname = "yourdomain\\Microsoft Office 2007"