We received a question from someone whose mail settings did not allow a reply (see http://ops-mgr.spaces.live.com/default.aspx?_c01_BlogPart=blogentry&_c=BlogPart&handle=cns!3D3B8489FCAA9B51!541). The question was:

I have a small question about "Adding Network Devices with PowerShell" that you write about in your book.
In your example you connect NetworkDevice to $agent add-remotelymanageddevice -proxyagent $agent -device $discovery_results.custommonitoringobjects
But how I can connect NetworkDevice to Management Server (it's not in get-agent output)?

The answer:

Adding a network device to management with PowerShell does not require that you furnish the name of a management server. If we understand your question correctly, you asked about 'connecting NetworkDevice to Management Server.'

Let's explain the PowerShell cmdlet used in the eighth and final cmdlet in a series of cmdlets in our Powershell script that together assemble an array of inputs, and feed those inputs to the last cmdlet.

The add-remotelymanageddevice cmdlet is fed only the inputs -proxyagent and -device.

The involved management server will be the primary management server associated with the proxy agent--but that is not part of the action of adding the network device to management. We only need the name of the proxy agent.

The Discover-and-Add-Network-Devices.ps1 is a PowerShell script for discovering and adding network devices. It was developed in conjunction with Chapter 17, "Monitoring Network Devices," of System Center Operations Manager 2007 Unleashed.

SUMMARY

Most organizations run anti-virus (AV) software on their servers and workstations to detect and fix computer viruses. However, running antivirus software on server software systems such as Operations Manager can cause data corruption and have a detrimental effect on performance.

MORE INFORMATION

There are particular folders and files that should be excluded from anti-virus scanning.

• These include the SQL Server database files used by Operations Manager components as well as system database files for the master database and tempdb.
• You will also want to exclude queue and log files used by Operations Manager from anti-virus scanning.
• These include but are not limited to files under %ProgramFiles%\System Center Operations Manager\Health Service State\ and its subdirectories.
• Other areas to exclude from scanning is the OpsMgr install and wbem directories.
• You will want to exclude the page file from anti-virus scanning and the Windows temp directory (%windirtemp%) as well.

If you use a firewall, you will need to open up the ports for installing the agent (135), client communication (5723), email communication (25), and potentially others. The ports used by Operations Manager 2007 are listed in Table 1.

Table 1. Communication Paths and Ports

UPDATE 7/21/08: Rod Trent recently posted an article on recommended antivirus exclusions, see http://myitforum.com/cs2/blogs/rtrent/archive/2008/07/18/recommended-antivirus-exclusions-for-opsmgr.aspx.

In May 2008, Microsoft released public previews (Release Candidate 0, known as RC0) for new two server products:

• Essential Business Server (EBS) 2008
• Small Business Server (SBS) 2008

Our blog article earlier in July (http://ops-mgr.spaces.live.com/Blog/cns!3D3B8489FCAA9B51!576.entry) focused on EBS; this article looks at the management features and scenarios for SBS 2008 (RC0). Many people have been waiting for SBS 2008, as this product will replace the broadly deployed SBS 2003—Microsoft's customer-premise server solution for the very small organization.

The low price point of the SBS 2003 package made it a good seller, but integration features between the various server products in SBS 2003 was not as illustrious. Few customers used or appreciated the admin wizards, the pre-created SBS security groups, and similar features. In contrast, the integration in SBS 2008 is excellent and eliminates the otherwise complex setup and administration of Windows Server 2008 X64, Exchange 2007, SharePoint 3.0, Fax services, Certificate services, WSUS, and so on. For those Microsoft network owners with less than 2 servers and 75 clients, whether or not they already use SBS 2003, SBS 2008 is a compelling migration option to consider—particularly at the very small customer end, such as those installations that have less than 25 clients. SBS 2008's capability to accelerate and error-proof the installation and secure operation of these super-complex server technologies takes huge burdens take off the small network owner’s plate.

SBS 2008 Setup

Having just run through the EBS 2008 RC0 setup, we could contrast that 3-server install with lots of previous experience of independent setup of each server component, i.e. Windows Server 2008, Active Directory, Exchange 2007, Forefront, etc., which would be easily a 400% savings in time. Now we compare both those processes to the SBS 2008 RC0 setup, which approaches a ten-fold savings! The error-free setup of SBS 2008 on an HP ProLiant ML350 was just amazing. Immediately after setup, we were receiving Internet email. "Out of the box," every component, AD user account and Exchange mailbox, OWA with CA, secure SMTP Receive connectors, a very effective anti-spam and Exchange anti-virus, and lots more were correctly configured.

These were massive timesavings, and it was a relief to know that the Windows 2008/AD/Exchange/SharePoint lash-ups on that server were setup securely and according to Microsoft best practice. For more current news and tidbits about SBS (and EBS) 2008, a great starting place is the blog of Microsoft's Nicholas King at http://blogs.technet.com/nking/default.aspx.

SBS 2008 Native Management

Unlike its big sister EBS, SBS 2008 does not include a copy of the System Center Essentials 2007 management application. Microsoft decided to make SBS extremely simple in setup and operation, and with a very light resource footprint. Essentials 2007 has more features than necessary for the SBS target environment, and higher resource demands than the SBS architects wanted to support. Instead of Essentials, SBS 2008 includes a brand new mini-management environment known as the Windows SBS 2008 Monitoring Data Collection Service. The Data Collection Service does not appear to be a modified OpsMgr 2007 Health Service, but instead is a brand new mini-management stack developed just for SBS 2008. The installation has a local instance (named “SBSMONITORING”) of SQL 2005 Express on the SBS 2008 server that hosts the management database for the service. Outputs of the service include alerts that appear in the SBS Console, optionally emailed to an administrator. Here is a screenshot of the SBS Console, Network-> Computers view:

Our SBS 2008 network includes two client computers running Windows Vista. The clients were connected to the SBS domain by visiting an intranet web site on the SBS server and running an ActiveX control. This joined them to the domain and downloaded additional software such as the SBS Vista Gadget (see the "The SBS 2008 Vista Gadget" section later in this article). Clicking through on the Critical alert for the SBS server, it’s easy to read what the problem is, shown in the screenshot below (If you elect to receive email alert notifications, you’ll get exactly the text you see here.).

Similar to System Center Essentials 2007, SBS 2008 includes a daily report that can be emailed to the SBS administrators email distribution list. (SBS 2008 has an additional weekly report that is more detailed.)

One difference between the Essentials Daily Health Report and the SBS 2008 Summary Network Report is the SBS report does not include a software installed listing, but the SBS report does include server uptime, backup, and email usage and mailbox size sections not included with Essentials. The SBS report is also much more attractive. Here is an actual SBS Summary Network Report, open in Outlook 2007:

Remote Management Options for SBS 2008

Many SBS 2008 owners may want to outsource some aspect of server monitoring or management. A network service provider could leverage the native Windows SBS 2008 Monitoring Data Collection Service, and have the SBS server email the service provider with the alerts for follow-up investigation. That could work for a very low-capacity management service with relaxed timeframes for problem resolution. SBS 2008 includes Remote Web Workplace (RWW), as does EBS, and RWW is a secure way for the service provider to remotely access customer computers for support and service.

The SBS 2008 owner (or IT service provider that supports the SBS owner) may consider employing some additional technology (or partner with a service provider) for deeper monitoring and/or remote management than that provided by the native Windows SBS 2008 Monitoring Data Collection Service. Potential candidates in the Microsoft management portfolio to provide richer monitoring and management of EBS 2008 include:

• Essentials 2007
• Operations Manager 2007
• Remote Operations Manager 2007

Here are all the supportable topologies we can see for this scenario:

1. Essentials 2007 SP1 installed on a second server in the SBS 2008 domain, monitoring the SBS server with an agent component. Enable Service Provider mode using the wizard in the Start menu.
2. OpsMgr 2007 SP1 gateway server component installed on the SBS 2008 server or a second server in SBS 2008 domain. Connect to Remote OpsMgr gateway using the gateway and MOMCertImport.exe.
3. OpsMgr 2007 SP1 agent components installed on the SBS 2008 server and any other computers in SBS 2008 domain. Connect to Remote OpsMgr gateway with agent and MOMCertImport.exe.

Notice our list does not include installing Essentials 2007 on the SBS 2008 server. Although this might be technically possible (we have not tried this), we see too many chances for conflict with the SBS native components, particularly WSUS. The SBS 2008 server needs to be left in its basic configuration as much as possible and administered using the SBS 2008 console to keep everything ‘in synch’ on the SBS network.

We piloted scenario #3, which is to connect the SBS 2008 server to a Remote OpsMgr instance agent-to-gateway over the Internet using certificates. We are happy to report that this works, meaning the OpsMgr 2007 SP1 agent component can run on the SBS 2008 server in harmony with the native Windows SBS 2008 Monitoring Data Collection Service.

Here is a screenshot of the Windows Task Manager Processes tab. This screenshot shows:

• The native SBS management workload (the blue highlight), which includes the SQL service dedicated to DataCollectorSvc.exe
• The processes added by the OM 07 Agent (highlighted in red):

Different from EBS 2008 (where attaching to a Remote OpsMgr instance augments the native Essentials 2007 -> Exchange 2007 monitoring), when you attach a SBS 2008 server to Remote OpsMgr, Exchange 2007 monitoring begins for the first time. For example, you must run the PowerShell script new-TestCasConnectivityUser.ps1 on the SBS 2008 server to configure Exchange 2007 client monitoring features.

The SBS 2008 Vista Gadget

When you attach your Vista client computer to the SBS network, SBS installs a Vista Sidebar gadget. This gadget is like a mini-company memo board with both standard and custom links and labels. We changed the “Administrator Link” label to say “Admin-only links” and added a custom shared link “Remote OpsMgr Web Console,” which links to the service provider’s OM 07 instance supporting that customer. Here’s what that gadget looks like with the Admin-only links fly-out open on the left:

The Remote OpsMgr Web Console

We created an AD user and corresponding OpsMgr 2007 User Role in the Remote OpsMgr service provider domain and scoped this to a group containing the Windows Computer object for the SBS 2008 server. Tailored views are assigned to offer an uncluttered space that is focused on key SBS 2008 server technologies. The next screenshot shows a high-level Computers view of the SBS 2008 server in the web console:

This web console view below clearly points out the problem with Exchange 2007 is that a Hub Transport service is stopped on the SBS 2008 server:

Finally, here’s an example where SBS 2008 server’s web sites can be individually stopped and started using the Remote OpsMgr web console (see tasks circled in red):

Closing note: Microsoft has announced that updated release candidates (RC1) for EBS 2008 and SBS 2008 will be released very soon (possibly by the end of July 2008?). We’ll post here on any management-related changes in the new releases.

We continue our "OpsMgr Answer This" series with a discussion on the new class-based architecture in Operations Manager 2007.

To focus the topic on specific questions, we looked at the following areas:

• When I select to override a rule or monitor, I can select to target all objects of a class, or all objects in a group. If I have a choice of either (because the objects I am interested in are included in both one or more classes and one or more groups), which should I select?

You would select class. By default, discoveries are targeted at a class; therefore as new objects are added, they will inherit the override. This can be accomplished with groups but discovery will take longer as group membership needs to be calculated also.

• When I am authoring a management pack, and I want to pre-define how overrides are targeted, is there a performance or feature difference in selecting either classes or groups?

Again, you will want to select class. Targeting groups will prevent you from using DAs (distributed applications) properly. Say you have a monitor targeted at a class, you can add this class to a DA and have its health state roll up.

So when should I use groups over classes?

A situation where targeting groups is easier to administer is when you want to leverage the ability to quickly add and exclude objects from a group using the Authoring space of the Operations console. It's not so easy to change the membership of a class.

Microsoft provides a video to clarify how targeting a monitor and a group works. The video is available at http://www.microsoft.com/winme/0712/31678/ClarifyTargetingAtGroups_300kbps.asx and is just over a minute long. They have also developed a "poster" of best practices for Rule and Monitor targeting which you can view at http://download.microsoft.com/download/f/a/7/fa73e146-ab8a-4002-9311-bfe69a570d28/BestPractices_Rule_Monitor_REV_110607.pdf. The poster is about 5MB in size.

Key points of the poster:

• Always target classes unless the objects of interest are only defined by a group
• Always target the most specific class possible - for example, the Windows 2003 Operating System if all targets are Windows Server 2003, rather than targeting Windows Computer or Windows Server Operating System
• When you target groups, create a disabled monitor and then enable the monitor for the group.

UPDATE

Here are some other interesting links and additional tidbits (courtesy of Jason Sandys who is helping with the System Center Configuration Manager 2007 Unleashed book):

• Computer groups cannot per used to target monitors and rules (http://blogs.technet.com/momteam/archive/2007/11/14/targeting-series-part-2-why-targeting-a-computer-group-fails.aspx ), but they can be used to target overrides (http://systemcenterforum.org/wp-content/uploads/OpsMgr_overrides.pdf ). 
• Normal groups can be used for either targeting scenario depending on the actual objects that are members of the group.  This leads to the conclusion that targeting rules and monitors is completely different from targeting overrides - and it would have been nice if different terms were used for these two types of targeting, maybe filtering for overrides instead of targeting. 
• Targeting rules and monitors applies them to the actual object and when using the computer group, it actually targets the group object instead of the members of the group but not when using a regular group.  Targeting (filtering) an override always filters based on the members of the group if one is used. 

Do you have burning questions about OpsMgr 2007 you'd like us to answer as part of this series? Please submit those as comments to this article!

Chapter 12 of System Center Operations Manager 2007 Unleashed discusses ManagementServerConfigTool.exe as a tool to move the RMS component. Because of the unique role the RMS has in an OpsMgr 2007 management group, you always want to have a disaster recovery plan in place, in the event the server hosting the RMS becomes inoperable.

As part of that plan, be sure to backup the RMS encryption key (use SecureStorageBackup.exe, which runs automatically during OpsMgr installation in Service Pack 1), and have a current backup of your Operations database. If you need to transfer the RMS role, the tool that accomplishes this is ManagementServerConfigTool.exe.

In Chapter 12, we discuss the steps using the version of the tool available when the book was being written, which was prior to the current version. Let's talk a bit about how the tool works and some caveats.

The syntax on page 573, step 8, specifies

ManagementServerConfigTool.exe PromoteRMS /DeleteExistingRMS:true

If you have a clustered RMS, which many large installations have implemented, the /DeleteExistingRMS:true switch deletes the existence of the clustered virtual server from the Operations database. With SP1, it is not possible to create a clustered RMS after your initial management group installation, and this would prevent you from getting back to a clustered RMS later!

As an alternative, run the command without the /DeleteExistingRMS:true switch, so the syntax would be

ManagementServerConfigTool.exe PromoteRMS

This “demotes” the previous RMS to the role of a secondary MS. (If the switch is not specified, the tool by default uses /DeleteExistingRMS:false.)

With a clustered RMS, the RMS cannot be used in a secondary MS role - this is by design. In this scenario, running the Promote option puts the node in a temporary non-operational role, allowing\ it to remain in the database and be available for re-promotion when you are ready to put the clustered RMS back in its original role. In essence, you are demoting rather than deleting!

The tool generates the following warning:

Running this tool can cause irreversible damage to your Operations Manager DB. Please backup your DB before continuing.  Continue the PromoteRMS action? (Y/N)

Hint: PLEASE be sure to have a backup!

If by accident you specified the /DeleteExistingRMS:true switch, stop the SDK service on the recently promoted RMS, restore the DB, then run the UpdateDemotedRMS action on the recently promoted RMS to set it back to a secondary MS role. This makes the clustered RMS the only machine in the RMS role in the Management Group. 

Additional documentation is available at http://technet.microsoft.com/en-us/library/cc540401(TechNet.10).aspx.

The corrected syntax for the command is being published in the errata for System Center Operations Manager 2007 Unleashed, at http://www.informit.com/store/product.aspx?isbn=0672329557. Many thanks to Starr Parker of Microsoft for his help and insight!

We (and Microsoft) told you to expect Essentials everywhere! In May 2008, Microsoft made available for public preview two significant new server products:

• Small Business Server (SBS 2008)
• Essential Business Server (EBS 2008)

SBS 2008 and EBS 2008, previously known by their respective codenames of Cougar and Centro, are important because they are based on the all new server technologies that include Windows Server 2008 and Exchange Server 2007. Additionally, both products can use System Center Essentials as a primary management platform and require 64-bit CPUs. SBS 2008 is a single-server solution for up to 75 desktops, with an optional second SQL server, which can run a 32-bit OS. Essentials is not bundled with SBS 2008 as it is with EBS 2008.

A later article in this series will look at management technologies in SBS 2008. This article focuses on the System Center components in EBS RC0 (Release Candidate 0). Windows EBS 2008 is a superset of SBS 2008, and is the new three-server suite combining database, messaging, directory, file and print, and security/firewall services (with an optional fourth server running SQL Server, which can be 32-bit or 64-bit). Years in development, this product is for the mid-market space of up to 300 desktops. The messaging, security, and management server components are split across three servers that are installed in one multi-phased setup procedure and managed as a group.

You may confuse the EBS product with the System Center Essentials product since both include the word “essential.” To tell them apart, remember that System Center Essentials uses a plural noun, while Essential Business Server takes the singular adjective. EBS in fact installs Essentials, and uses it as the management and updating engine for the network.

While the installation process is mostly automated, building out an EBS suite takes several days and a significant amount of install time. There are several dozen post-installation tasks that you are walked through using wizards. Each EBS server features a unique desktop wallpaper—here is a composite screen shot of each server desktop with icons for the server technologies (roles) deployed to each EBS server:

Essentials in EBS

System Center Essentials 2007 SP1 is installed automatically on the first server that is built, the Management Server. The Essentials EBS instance is modified from a default Essentials by adding management packs for Exchange 2007, Forefront Server Security (for Exchange 2007), and Forefront TMG (former codename ISA Server Nitrogen). There is also an EBS management pack that we’ll take a closer look at in a moment. Essentials agents are automatically deployed to the Security and Messaging servers, and the Essentials product features are pre-configured during the EBS install.

The only portion of the Essentials setup not fully automated during the initial EBS install is configuring the Updating features of Essentials. Launching a task from the menu of EBS post-installation tasks will configure the Essentials updating features. After you complete EBS setup and the post-configuration tasks, all three EBS servers are now fully monitored by Essentials. For a quick high-level software inventory of what's installed by EBS setup, consult the Essentials Daily Health Report—here is the Installed Software portion of that report:

A goal of the EBS product is to shield the administrator from having to choose among the various server administration consoles (such as Essentials) and MMCs (Microsoft Management Consoles), and offer up single top-level administrative interface for all routine network admin activities. You can see some screenshots of the EBS Administration Console at the EBS feature overview page: http://www.microsoft.com/windowsserver/essential/ebs/overview.mspx. We’re not going to cover that part of EBS here, but we can clear up an issue of some speculation during EBS development—specifically, that while EBS includes and uses Essentials, the primary UI (the EBS Administration Console) is “not Essentials” but rather “part of EBS.”

The EBS Management Pack

We asked “what does the EBS management pack do?” Remember EBS is not designed to use the Essentials console for local monitoring, but uses the EBS Administration Console. Perhaps this is why the EBS management pack does not expose any new views in the Essentials console. Creating a custom view of all alerts generated by the EBS management pack, you can see that it is mainly doing configuration checks to make sure that the many EBS servers and applications remain properly installed and licensed:

Managing the TMG firewall component of EBS is error-proofed by pre-creating applicable custom protocols and access rules needed for Essentials agent -> Management Server (or gateway) communication and for publishing Remote Web Workplace (a key component in Service Provider mode that can be difficult for some customers to get right without some help). Here’s a shot of some of the firewall access rules from the TMG firewall:

EBS on Hyper-V

The current pre-release EBS version is not supported with virtualization and requires three physical servers. However, Microsoft plans to provide virtualization options for the released version of EBS. We tried for several weeks to install all three EBS servers as guests on the same dual-core Hyper-V host with 8GB RAM, but this was not successful—possibly  because of resource limitations while installing the third server. Once we gave up trying to get all three servers running as Hyper-V guests, we successfully installed the EBS Management Server on the physical host, an HP ML 115 (dual-core AMD X64) with 8-GB RAM, using these steps:

1. Install Hyper-V role on the Management Server
2. Upgraded Hyper-V to RTM.
3. Create two VMs, one for the Security server (2-GB and 1 CPU) and one for the Messaging server (3-GB and 2 CPU).
4. Install Security server into first VM. Use Legacy NIC for the External adapter. After OS install but before proceeding with EBS portion, insert Integration disk and install the Hyper-V RTM client support.
5. Install Messaging server into second VM. After OS install but before proceeding with EBS portion, insert Integration disk and install the Hyper-V RTM client support.

EBS with Remote OpsMgr (ROM)

Now we’ll have some fun. We have EBS deployed on one physical host and two virtual guests, and we will enable Service Provider mode on the EBS Essentials server. This will pilot an EBS customer contracting with a service provider for enhanced remote monitoring and/or managed services, enabling the customer to outsource monitoring support.

Once the local Essentials instance is connected to the back-end NOC by running the Enable Service Provider Mode applet from the Start menu of the EBS Management Server, the management packs running in the service provider instance of OpsMgr (Remote OpsMgr) are downloaded to the customer Essentials server. The EBS server is approved in the Remote OpsMgr Operations console after running the gateway approval tool just like bringing any other customer Essentials server into management. Once the Essentials server is green in the Remote OpsMgr console, we can push Remote OpsMgr agents to the other two EBS servers, and have remote eyes-on all three customer EBS servers.

Our Remote OpsMgr instance already had management packs for Exchange 2007 and Forefront Server Security for Exchange loaded. We imported the TMG (Nitrogen) and EBS management packs distributed with the EBS product into the Remote OpsMgr management group, thereby enabling the Remote OpsMgr management group to monitor all the server technologies in EBS (see note 1). Hardware vendor and advanced application management packs from the Remote OpsMgr instance (such as Virtual Server) are applied to customer servers without need to modify the EBS instance of Essentials.

Importing the EBS management pack creates a new group type, “Windows Essential Business Server core servers computer group,” against which you can target custom views and monitors. The screenshot below shows a diagram view for a customer EBS group—filtering for Critical/Warning object will quickly show what is wrong across the three-server group:

To simulate a customer administrator accessing their Remote OpsMgr Web Console, we scoped an Operator role to the Essentials customer group. Only relevant view folders were exposed in the user role’s tailored console view. We then created a custom EBS dashboard view that rolls up the EBS diagram, Exchange 2007 health, IIS Web site health, and logical disk health—see that customer’s Web Console below:

Comment:

There is going to be a great market for EBS for the mid-size organizations that need to migrate their infrastructure from Windows 2003 and Exchange 2003 together. Since this move always means new hardware (the configuration requires all 64-bit servers with a good bit of memory), there is a lot of work involved in planning and getting the migration done right. EBS greatly reduces the risk and the cost of migration to these new technologies, as the EBS installation wizard is built to guide an organization though the migration step by step, automatically employing best practices and good security.

Notes:

1. After importing the EBS management pack into the Remote OpsMgr management group, go to the Authoring space -> Management Pack objects -> Rules, search for the Microsoft.Windows.EssentialBusinessServer.RunUpdateServicesScheduledTask rule. Create an override to disable this rule for all objects of Management Server class. Then create an override to enable the rule for a specific object of the Management Server type, selecting the EBS server. (Otherwise this rule will create noise by running on non-EBS management servers.)
2. The Remote OpsMgr instance included pre-release Windows Server 2008 and IIS 2008 management packs not yet included with EBS.
3. The hotfixes needed to get Exchange 2007 SP1 monitored correctly by OpsMgr 2007 SP1 were installed on all EBS servers as well as the Remote OpsMgr instance. (KB950853, KB951979)