[Today's post is contributed by Carol Bailey]
We've seen this question come up a few times, and the simple answer is no - as long as the communicating computers have a trust in common, and the correct certificates are used, native mode works just fine. This trust in common can use a single certification authority (CA) hierarchy or multiple CA hierarchies. Because native mode is PKI-agnostic, this all happens at a lower level than Configuration Manager - we just need the PKI connection established before we can proceed with native mode communication.
The phrase "trust in common" sounds very simple, but if you're not familiar with PKI, then trying to explain how this requirement pans out for native mode is actually quite difficult to explain, because there are multiple certificates to take into account and each could be issued by a different CA hierarchy.
One of the best ways to explain this is to work through an example where we'll achieve the common trust by installing root CAs - but this isn't the only way to achieve trust in common (cross-trust subordination is another method). If you need some tips on installing root CA certificates, see http://technet.microsoft.com/en-us/library/bb693643.aspx.
Our example uses the following:
(Note, this choice of CA hierarchy split is arbitrary - for example, there's no requirement that all the server certificates are from the same CA hierarchy, or all workgroup clients must use the same CA hierarchy.)
For native mode communication to be successful in this scenario:
If you see WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA in log files, this usually means that the trust in common failed. Let's say with our example that the workgroup clients didn't have the root CA installed for hierarchy 3. When one of these clients tries to communicate with its native mode management point, it checks the Web server certificate and "walks" the chain to see if it ends in a root CA that it trusts. If it doesn't, it can't trust the server certificate despite the server certificate otherwise having all the right requirements (such as not expired, server authentication capability, FQDN in the Subject or SAN) - and communication will fail. Similarly, if the management point couldn't successfully chain the client certificate to a trusted source, it would reject the client certificate.
It's easy to make the mistake of thinking that the invalid CA in the error message refers to the computer's own certificate rather than the certificate on the other computer. If you get this error message, use the Certificates MMC to check the certificate path on the other computer (double-click the certificate and then click the Certificate Path tab), and ensure that the computer with this error message has the root CA and any intermediate CAs that chain from that certificate. If they are missing, export them by locating the lowest subordinate CA in the Certificates MMC, select Export, and then select the option for PKCS #7 Certificates (.P7B) with the option "Include all certificates in the certification path if possible". You can then easily import the chain onto the computer that reported the error message.
In addition to seeing this error message when you're using multiple CA hierarchies, watch out for it as well if you're deploying certificates outside the forest. This might include a subordinate CA in another forest, or workgroup computers. In these scenarios, these computers will not automatically install enterprise root and subordinate CA certificates through group policy, so you will have to take additional steps to ensure that they have installed the certificates required to successfully achieve trust in common with their communicating native mode computers.
I hope that this post helps to clarify how multiple CA hierarchies can be used with Configuration Manager native mode, and what additional steps might need to be taken to achieve the underlying PKI communication. And, for people who ask about using a public CA for native mode, the example works equally well for both internal CAs and public CAs.
- Carol Bailey
This posting is provided "AS IS" with no warranties, and confers no rights.
For those of you who are attending the Microsoft Management Summit in Las Vegas this April, you'll be happy to know that the session catalog is now available!
The link is: http://www.mms-2009.com/public/sessions.aspx
All the breakout sessions have been added, with hands-on labs coming next week.
Remember that there are always some last minute changes so an individual session may be replaced by another one. However this is the accepted list of sessions at this point in time. PDF files with all the topic details will be added very soon (in the next day or so).
Additional information on MMS 2009 can be found at: http://www.mms-2009.com/
Hope to see you all there!
- Wally Mead
[Today's post comes from Carol Bailey]
Many companies do not currently have their own public key infrastructure (PKI) with an issuing Certification Authority (CA) but still want to benefit from native mode and Internet-based client management - which has a dependency on PKI certificates. So a natural follow-on question is whether native mode can use certificates from a public CA rather than using an internal CA.
The technical answer is yes. Native mode is PKI-agnostic, supporting industry standard certificates (version 3 of the x.509 certificate format) and has no dependencies on the issuing CAs. This is in contrast to the out of band management feature, introduced in Configuration Manager SP1, which has a dependency on a Microsoft enterprise CA and certificate templates for the certificates issued to the AMT-based computers.
If you decide to use a public CA for your native mode certificates, identify the certificates that you need by using the Certificate Requirements topic (http://technet.microsoft.com/en-us/library/bb680733.aspx) and gather the related certificate information - using the columns Certificate Use and Specific Information in the Certificate. This is where the OID numbers come in use, because these uniquely identify the certificate capability in a format that will be understood by all PKI vendors.
The CA hosting company will provide their own instructions for requesting and installing the certificates that you need, and usually this involves connecting to their own Web site and filling out their own forms - so exact instructions will differ between companies. They might also support a standard certificate request file that you can create using Windows certificate tools.
Microsoft Windows computers and some devices are automatically configured with some well-known public root certificates and their intermediate CAs. If you use certificates that chain to one of these CAs, the benefit is that the certificate will be automatically trusted by default and no additional configuration is required. However, if you use certificates that do not chain to one of these CAs, you must install the root CA (and possibly any intermediate CAs) on the computer on which you are installing the certificate and any communicating computer. For example, if you purchase a client computer certificate that chains to the root CA called "ComputerCerts Root CA", you would need to install not just the client certificate, but the chain on the client computer and any native mode servers that the client communicates with - for example, its management point, distribution points, software update point, and state migration point.
Having to install certificate chains on multiple computers is just one reason why using a public CA might prove impractical, even if it's technically possible. The flip side is that using a well-known public CA that is automatically trusted by all the computers decreases the security of your site. That's because the client certificate is used to authenticate the client during registration - you're saying "I trust you to upload data into my Configuration Manager hierarchy". Anybody can buy a certificate with client authentication from a public CA but you probably wouldn't want anybody to have the ability to join their computer to your site. If your Configuration Manager servers automatically trust the public CA, they will trust this computer and site assignment will succeed. If you use a public CA for your client certificates, Configuration Manager has no way of distinguishing between the computers you really want to join the site, and computers that you might not.
(This possibility also exists when you're using native mode certificates with your own CA, because by default, all computers trust certain public CAs. This is why you should configure an IIS CTL that identifies which root CAs should be trusted for native mode communication. For more information about this, see Determine If You Need to Configure a Certificate Trust List (CTL) with IIS (Native Mode).)
The main reason why it might be impractical to use a public CA for native mode, is cost and manageability. Many PKI-dependent solutions use just one or two server certificates, but native mode requires server certificates on a number of site systems and a unique certificate on each client computer. For the majority of our customers who have a high number of servers and hundreds (if not thousands) of client computers, a Microsoft enterprise CA is ideally suited to this requirement. It can automatically deploy and maintain client certificates with group policy, and after the certificate templates are configured for the servers, the overheads of deploying these in-house are also very minimal.
Having said that, I do know of customers who have used a public CA for a handful of computers that never connect directly to the intranet, and then use their internal CA for the remaining certificates. They decided that the administrative costs of deploying and maintaining certificates outside their own network was higher than the costs of buying individual client certificates from a public CA, and they used additional external security controls to protect the site from unauthorized computers that might have a client certificate from the same CA.
Using more than one CA hierarchy to support native mode is the subject of my next blog posting.
Interested in deploying Configuration Manager in your environment? Need to learn how to configure a new installation to manage your clients and servers? Then join Wally Mead, well known in the industry for his deep expertise and long history in the Systems Management business, for an all-day demonstration build-out of the latest release of Configuration Manager. In this packed day of content, learn from Wally as he uses a virtual lab environment to install and configure Configuration Manager, as well as exercise the key features of the product.
Topics include:
The demonstration-based format promises to provide a day-long interactive session of training with one of the industry's top experts in the field. IT professionals working in system management and are responsible for setup, deployment, and administration, will benefit from attending this session.
Note that seats are limited, so book early to avoid disappointment!
TechEd 2009 site: http://www.microsoft.com/events/teched2009/
- Yvette O'Meally
[Today's post is provided by Carol Bailey]
I see a lot of confusion about how and when native mode clients use a server locator point, so let's take a look at this for clarification. The product documentation tells you when and how to configure native mode clients for a server locator point, but this post includes the why element, which might help you to understand it better and therefore remember it.
Before we dive into this, let's recap what the server locator point is: The server locator point is an intranet-based site system and is used to locate site information to complete site assignment, and to find management points on the intranet.
There are 3 scenarios to consider for native mode clients:
Note: Do not specify the CCMSetup properties CCMALWAYSINF=1 and SMSSLP=<servername> for the same client. When CCMALWAYSINF=1 is specified, the client will never contact a server locator point. Although specifying these two together shouldn't break anything, they were not designed to be used together. I often see customers using this combination and because it is not a supported configuration, I always advise them to delete the SMSSLP option.
Server Locator Points to Complete Site Assignment
When a client is configured for an Internet-based management point, it does not need site information to complete site assignment. Internet-based clients must be directly assigned to their site - they cannot use auto-site assignment. Additionally, they skip the site compatibility check that would normally check that they were not trying to assign to an SMS 2003 site and that they are not running Windows 2000 - so you must make these checks yourself to ensure that the client doesn't become unmanaged. This is why both an Internet-only client and a client configured for intranet and Internet management will never contact a server locator point for site assignment.
Conversely, a native mode client that isn't configured with an Internet-based management does need site information to complete site assignment - it always needs this for the site compatibility check (and will also need this if it's using auto-site assignment). When the Active Directory schema has been extended for Configuration Manager 2007, and the client can read site information published to Active Directory Domain Services (the site is successfully published, the client is domain-joined and belongs to the same forest as its site), the client doesn't need a server locator point to complete site assignment. Instead, it gets the site information from Active Directory.
However, if any of these conditions are not true and the client can't get site information from Active Directory Domain Services - then the client must use a server locator point. You might think that this also applies to workgroup clients, but in fact workgroup clients are not supported for intranet and Internet management, and must be configured for Internet-only.
Server Locator Points to Find Management Points
The Internet-based management point is always directly assigned to clients, so clients never have to locate these themselves - only management points on the intranet. It's easy to work out why an Internet-only client will never contact a server locator point to find management points!
Native mode clients that are configured for intranet management do need to find management points on the intranet, and there are several mechanisms for doing this. They try in this order: Active Directory, DNS, server locator point. Only if the preferred methods fail do native mode clients use a server locator point to find management points. You will note that this list doesn't include WINS for native mode.
The funny thing about this requirement, is that you don't really need to worry about it, because the right decision has already been made for site assignment:
Configuring Native Mode Clients to Use a Server Locator Point
By default, native mode clients do not contact server locator points, even if the server locator point is specified on the command line. The reason for this default setting is because the communication uses an HTTP rather than HTTPS connection, which means that information passed to the client is not encrypted. This is not ideal from a security point of view, but bear in mind that this communication is on the intranet only (never on the Internet). That's why a client that is configured with an Internet-based management point does not need site information to complete site assignment - in case it is on the Internet.
If a native mode client needs to communicate with a server locator point, you can enable this behavior in 2 different ways:
As the full site property name implies, this configuration actually does double-duty. It also allows native mode clients to successfully communicate with mixed mode site systems. In most scenarios, you wouldn't want this - and certainly not when the client is on the Internet. However, if your hierarchy has mixed mode sites and your native mode client might roam into them, this setting allows it to communicate with the resident mixed mode management point and resident mixed mode distribution points to download packages locally rather than over a WAN. This means that this setting might be appropriate for native mode clients on the intranet that can read site information from Active Directory Domain Services - for roaming scenarios but not for site assignment.
In addition to configuring the native mode client to communicate over HTTP, you then have to ensure that it can find the server locator point - just as if it were a mixed mode client. You can either specify it as a CCMSetup property (SMSSLP) or publish it in WINS. Although native mode clients cannot use WINS to locate management points, they can use WINS to locate server locator points.
Checking Configuration for Native Mode Clients
If you need to check the native mode settings of a client to see whether it can contact a server locator point (and mixed mode site systems for roaming), see the procedure: How to Identify Client Configuration Details for Native Mode and Internet-Based Client Management.
More Information
Use the site assignment flowchart for a quick cheat-sheet on this behavior for all scenarios. Concentrate on site assignment, and (as explained above) management point location will work itself out.
Additionally, the following links have more information about the server locator point and native mode clients:
Determine If You Need a Server Locator Point for Configuration Manager Clients
Decide If You Need to Configure HTTP Communication for Roaming and Site Assignment (Native Mode)
Client Communication in Mixed Mode and Native Mode
[This post comes to us from Bhaskar Krishnan and gives an overview of the new SQL Reporting Services feature and the benefits it provides over the ASP-based reporting point in Configuration Manager and previous releases.]
Background
Prior to Configuration Manager 2007 R2, the reporting solution provided out of the box was a custom ASP-based solution that included around 384 reports that got installed as part of the site server installation. Running any of the reports required the user to install a role called "Reporting Point" using the site role wizard. The site role wizard would basically create an ASP web site hosted under IIS and would allow users to run any of the reports from the ASP web site. However customers frequently ran into timeout issues with the web page timing out while attempting to render "expensive" reports - by expensive I mean reports returning large amount of rows from the Configuration Manager database.
http://social.technet.microsoft.com/Forums/en-US/configmgrgeneral/thread/4c7d2829-3a8f-44d5-9b37-a4c3a128d126/
In addition, the solution offered little flexibility when it came to supporting standard reporting functionalities like the ability to export the reports to various formats, to add custom branding to the reports (by branding I mean changing the look and feel of the reports) and more importantly scheduling the reports to run at specific times and allowing users to subscribe to those reports.
SQL Reporting Services, with its industry standard reporting solution, provided all of the benefits and proved to be a more cost effective and scalable reporting solution for System Center Configuration Manager.
Benefits of using SQL Reporting Services
SQL Reporting Services provides tremendous flexibility in terms of monitoring report execution performance, tuning report execution parameters and a boat load of value add functionality like:
Integration of SQL Reporting Services with Configuration Manager 2007 R2With Configuration Manager 2007 R2, we introduced a new site role called "Reporting Services Point" that facilitates reporting using SQL Reporting Services 2005/2008. This is accomplished via a conversion wizard that ships with Configuration Manager 2007 R2 and allows the user to convert all the Configuration Manager reports that currently exist on that site server to SQL Reporting Services based reports and deploy them to the SQL Reporting Server.Site Role Installation and Configuration
The following outlines the overall workflow in getting a SQL Reporting Services based reporting point up and running:
For the default SQL Reporting Server instance the URL to access the report and report folders would be: http://[ReportServer]/Reports For named SQL Reporting server instances the URL would be: http://[ReportServer]/Reports_[InstanceName]
For the default SQL Reporting Server instance the URL to access the report and report folders would be:
http://[ReportServer]/Reports
For named SQL Reporting server instances the URL would be:
http://[ReportServer]/Reports_[InstanceName]
Other functionalities provided within the Configuration Manager administration console
The Configuration Manager 2007 R2 release ships two out-of-the-box report models one for Client Health Reporting and the other for Software Updates Management. The model based report wizard facilitates users to create custom reports using these report models.
The SQL based report wizard facilitates SQL savvy users to specify SQL queries and generate reports off of these queries. The wizard presents the users with a list of all available Configuration Manager database views and the corresponding columns to facilitate users to formulate SQL queries more easily and make the process less prone to errors and typos.
FAQs
1. Can the new Reporting Services role co-exist with the old reporting point on the same site server? Answer: Yes 2. What are the minimum permissions required to be able to view and run Configuration Manager reports? Answer: The security model for this feature relies on SQL Reporting Server's role based access model. Basically the user needs Browser privileges to be able to view and run the reports from the reporting server. In addition to having access to the report server the user will also need read access to the Configuration Manager database. o How to grant access to reporting server: http://msdn.microsoft.com/en-us/library/ms156034(SQL.90).aspx o Pre-defined roles: http://msdn.microsoft.com/en-us/library/ms156465(SQL.90).aspx 3. Does Configuration Manager 2007 R2 support SQL Reporting Services 2008? Answer: Yes - Configuration Manager 2007 R2 release supports both SQL Reporting Services 2005 and SQL Reporting Services 2008. If you plan to use SQL Reporting Services 2008, you only need one hotfix to avoid an incorrect status message from being bubbled up to the site server. The hotfix details are available here: http://support.microsoft.com/kb/957576/
1. Can the new Reporting Services role co-exist with the old reporting point on the same site server?
Answer: Yes
2. What are the minimum permissions required to be able to view and run Configuration Manager reports?
Answer: The security model for this feature relies on SQL Reporting Server's role based access model. Basically the user needs Browser privileges to be able to view and run the reports from the reporting server. In addition to having access to the report server the user will also need read access to the Configuration Manager database.
o How to grant access to reporting server: http://msdn.microsoft.com/en-us/library/ms156034(SQL.90).aspx o Pre-defined roles: http://msdn.microsoft.com/en-us/library/ms156465(SQL.90).aspx
o How to grant access to reporting server:
http://msdn.microsoft.com/en-us/library/ms156034(SQL.90).aspx
o Pre-defined roles:
http://msdn.microsoft.com/en-us/library/ms156465(SQL.90).aspx
3. Does Configuration Manager 2007 R2 support SQL Reporting Services 2008?
Answer: Yes - Configuration Manager 2007 R2 release supports both SQL Reporting Services 2005 and SQL Reporting Services 2008. If you plan to use SQL Reporting Services 2008, you only need one hotfix to avoid an incorrect status message from being bubbled up to the site server. The hotfix details are available here: http://support.microsoft.com/kb/957576/
That is pretty much it for my first overview post and I earnestly look forward to your comments, feedback and queries. If anything particularly interests you from the above post, please let me know and I will be more than happy to provide more specific details in my next post.- Bhaskar Krishnan This posting is provided "AS IS" with no warranties, and confers no rights.
[Today's post comes to us courtesy of Carol Bailey]
We've seen a few customer worried by this log entry in MPControl.log and CCMExec.log when the Configuration Manager site is in native mode. It looks bad, but actually it's a "good" error. We're checking whether the certificate is self-signed, and it's not, so throwing this error. Native mode won't work with a self-signed certificate, so this error is a sign that things are good!
We've answered this question a couple of times on the forums, but still see questions on it - so hopefully posting a blog with the actual error in the title will help people find it more easily.
Welcome to the official blog of the System Center Configuration Manager product team!!
This blog site offers our customers a single point of reference for technical information that comes direct from the product team, to make it easier for you to find the information that you need. For example, the UA writers blog began as way to inform customers about new documentation, but over time became a conduit for providing technical information that customers needed faster than we could publish through our traditional publishing processes. Other blogs were vehicles for providing feature-specific information outside normal channels, with great information being provided by team members such as Jason Lewis, Victor Sletten, Gabe Brown and Bill Anderson.Customers obviously benefitted from this additional information, but the multiple blogs meant multiple resources. So we came together to provide this Configuration Manager product blog as a single place to find the same levels of information but without having to subscribe to multiple feeds. The original blogs will continue to exist but new posts will be made on this central location. We would also like to provide a behind-the-scenes view of the team responsible for developing and maintaining the Configuration Manager family of products. Let us know what type of information you would like to see on this blog by e-mailing us on the following address: cmtblog@microsoft.com.To kick off this joint venture, we would like to introduce you to The Man behind the Configuration Manager product group, Ken Pan. Ken is the Product Unit Manager (PUM) for the System Center Configuration Manager product group, and is responsible for all engineering and product development functions associated with the Configuration Manager and SMS products. In this post Ken talks about his background and his role, and his early involvement with the product since 1992. Learn about his vision for the product, and why he thinks customer focus is so important to the product's future success.
Ken Pan is The Man behind the Configuration Manager product group. Ken is the Product Unit Manager (PUM) for the System Center Configuration Manager product group, and is responsible for all engineering and product development functions associated with the Configuration Manager and SMS products. Ken talks about his background and his role, and his early involvement with the product since 1992. Learn about his vision for the product, and why he thinks customer focus is so important to the product's future success.
Question: Tell me a little about your role and what you do.
I'm responsible for the engineering side of Configuration Manager - the product group and sustained engineering. I set direction and priorities for the team, lead the engineering team in executing the product plan, and help to sell and support the product. I attend MMS (Microsoft Management Summit) every year and look forward to spending that time in face-to-face discussions with customers - what they love (and hate!) about the product, and the challenges that they face in their unique business environments.
Question: How did you get where you are you today?
I came to Microsoft as an intern from UW (University of Washington) in the summer of 1992 - in between college and Graduate school. I loved it - both the people that I worked with and the experience of working at Microsoft. That very first job was with SMS just as it was getting going as a new product- with the codename of Hermes. I first worked on the despooler, which is responsible for compressing and decompressing files so that data for source packages and site information can be more efficiently sent over the network. Then I went on to work on many of the server components that do the behind-the-scenes work.
When I was hired as a developer, there was just a handful of people on the team working on the product. From those early days I've gone from developer, to lead developer, to developer manager, to PUM - always working with the same product and always finding new potential in each new version.
Question: What kept you working on the same product for all these years?
It's a mixture of people and technology. The great people that I've worked with over the years, and work with today, have a huge impact on how I feel about continuing to work on this product. Despite the large increase in the number of people that are now needed to code, test, support, and manage the product, somehow it still feels like we're working in a small group with all the benefits that affords. For example, the potential for innovation is limitless. Enterprise networks and business requirements continue to evolve at a rapid race, yet we can adapt and embrace new technologies and find new solutions to help with the challenges that these changes bring. The potential of this product is vast, and the excitement of being involved with its evolution never goes away. Configuration Manager is on a fast trajectory, and it's great being a part of that.
Question: Can you give me an example of a good day, and a bad day at work?
A good day at work is the countdown to a release when we know that the software has had thorough testing from our TAP (technology adapter programs) customers. Despite the myriad of test cases we put our pre-release software through, nothing beats the rigors of testing on a production network with all the unexpected variations that this brings to the environment. We highly value our TAP customers and their ability to put the software through its paces. It's not just the bugs that they find, but also their feedback generally for improvements and DCRs (Design Change Requests). Conversely, a bad day at work is in the countdown to a release when we haven't been able to get as much feedback from our TAP customers as we would like - maybe they ran out of time, or couldn't meet a dependency, or couldn't deploy a sufficiently high number of clients to provide good coverage. It happens, and it's unfortunate because we know from experience that the features that have the best coverage from TAP customers are less likely to have problems after release. For me personally, I am most satisfied when at the end of a day I can say I have made a contribution to building great software.
Question: What do you consider to offer the most compelling business value in Configuration Manager?
Anything that significantly lowers TCO (total cost of ownership) and gives control back to administrators. The ratio of computers to administrators in today's network makes it a continual challenge to simply find out what's out there that they should be managing. So discovering computers and their configuration, what software they are running, and whether they are compliant is the first step. Then, manage them in a controlled way with scheduling and reporting, and without saturating the network.
If you're upgrading to Vista (or planning on upgrading to Windows 7), then OSD (Operating System Deployment) is the way to roll out these new operation systems.
Question: What's your own favorite feature in Configuration Manager?
Actually, it's the behind the scenes stuff that supports highly distributed content across the network - such as binary differential replication that's used to package source files with a minimum of additional network traffic, and the site-to-site replication within the hierarchy. I'm also quite fond of the policy provider, although I might be biased because I worked on that in the past! However, if you're asking me to name a single product feature, I'm most excited about DCM (Desired Configuration Management) - because it's laying the groundwork for the future of self-healing systems.
Question: What areas do you think need most attention in future versions of Configuration Manager?
I would like to see us being better able to support deploying software to users, rather than today's model of administrators deploying software to computers. Gone are the days when most users ran the same software on a single computer, on a fast network. Today's environments need to be more adaptive so that users can easily get the applications they need to do their job, while the administrators retain control over the software and network. Configuration Manager in the future is well placed to deliver user-centric management.
And for DCM to fulfill its potential, it needs to support automatic remediation. Although administrators can today manually remediate computers that report noncompliance, automating this is the natural progression and would be a big win for our customers.
Question: Looking into the future, how do you see Configuration Manager?
The one-stop client management solution for enterprises.
Question: What is your favorite movie and why?
My favorite movie is The Shawshank Redemption because it exemplifies that a strong will can overcome many obstacles.
My favorite movie is