http://blogs.technet.com/jasonlewis/archive/2009/05/18/screencast-system-center-updates-publisher-creating-an-update.aspx
His two previous SCUP screencasts can be found here:
Jason plans to add several more screencasts to his SCUP series over the next 3 weeks so check back on his blog often or subscribe.
--Yvette
This posting is provided "AS IS" with no warranties, and confers no rights.
[A quick AMT troubleshooting post from Carol Bailey]
It's recently come to our attention that the out of band management console that is used to connect to AMT-based computers has a problem running on Windows XP SP2. We're in the process of updating our Supported Configurations documentation for this, and the June update will have the following troubleshooting entry added to the topic "Out of Band Management Console Issues":
The Out of Band Management Console Running on Windows XP SP2 Fails to Connect to AMT-Based Computers The out of band management console is not supported on workstations running Windows XP on versions earlier than Service Pack 3. A workstation running Windows XP Service Pack 2 fails to connect to AMT-based computers and logs the following entry in the <ConfigMgrInstallationPath>\AdminUI\AdminUILog\Oobconsole.log file: GetAMTPowerState fail with result:0x80072EE9Solution Upgrade the workstation to Windows XP Service Pack 3 or run the out of band management console on an alternative platform that Configuration Manager supports for the out of band management console. For more information about supported platforms, see Configuration Manager 2007 SP1 Supported Configurations.
--Carol Bailey
[Today's post is provided by Bhaskar Krishnan]
At MMS 2009 we announced that, with the next release of Configuration Manager, SQL Reporting Services integration, introduced in Configuration Manager 2007 R2, will replace the existing ASP-based reporting feature. So I thought this would be a really good time to come up with a FAQ that would make your transition easier and also outline some caveats that you should be aware of.
FAQ
1) Will both the reporting points exist in future releases?
No - The ASP based reporting point will be deprecated in the next release and we are making more investments in integrating with SQL Reporting Services 2008. But as of Configuration Manager 2007 R2 release both the reporting points are supported and can co-exist on the same machine.
2) How do I transition to the new reporting services point?
a) Install Configuration Manager 2007 R2. b) Check out the online documentation on how to configure the role and how to use the Copy Reports Wizard to convert and copy existing reports to SQL Reporting Services server.
a) Install Configuration Manager 2007 R2.
b) Check out the online documentation on how to configure the role and how to use the Copy Reports Wizard to convert and copy existing reports to SQL Reporting Services server.
3) Can the Copy Reports Wizard convert and copy all reports including custom reports authored in SMS 2003 and Configuration Manager 2007?
a) Out-of-box reports All out-of-box reports shipped with Configuration Manager 2007 R2 should get converted successfully into SQL Reporting Services reports. b) Custom reports (two caveats) i) All custom reports that leverage temporary tables (as part of the SQL statement behind the report) will fail to convert since the wizard cannot correctly identify the report fields to be displayed as part of the report. ii) All custom reports that leverage multiple SELECT statements (to incorporate multiple datasets within a report) and the data fields in the final report span across the multiple datasets, may be converted successfully to SQL Reporting Services reports (with a warning) but the runtime display for such reports is not guaranteed to show the correct data fields.
a) Out-of-box reports
All out-of-box reports shipped with Configuration Manager 2007 R2 should get converted successfully into SQL Reporting Services reports.
b) Custom reports (two caveats)
i) All custom reports that leverage temporary tables (as part of the SQL statement behind the report) will fail to convert since the wizard cannot correctly identify the report fields to be displayed as part of the report. ii) All custom reports that leverage multiple SELECT statements (to incorporate multiple datasets within a report) and the data fields in the final report span across the multiple datasets, may be converted successfully to SQL Reporting Services reports (with a warning) but the runtime display for such reports is not guaranteed to show the correct data fields.
i) All custom reports that leverage temporary tables (as part of the SQL statement behind the report) will fail to convert since the wizard cannot correctly identify the report fields to be displayed as part of the report.
ii) All custom reports that leverage multiple SELECT statements (to incorporate multiple datasets within a report) and the data fields in the final report span across the multiple datasets, may be converted successfully to SQL Reporting Services reports (with a warning) but the runtime display for such reports is not guaranteed to show the correct data fields.
Known Issue
Some of the converted reports may not have report links since these are explicitly removed during the report conversion process. The reason these links are removed traces back to a fundamental way in which SQL Reporting Services handles report links.
An example would make this issue clearer. Let us say Report A links to Report B via parameters Param1 and Param2. Also let us say that Param1 and Param2 which are parameters for Report B2 take a valid set of values (basically these parameters offer a list of possible values for the users to select by running a SQL query). Quite often it so happens that Report A has blank values for these parameters in some of the rows and when you drill down from these rows to Report B, SQL Reporting Services throws an exception that the values for these parameters are not valid. This is because it matches the value passed from Report A to the list of plausible values by running the SQL Query behind that report parameter for Report B and finds that a blank value is not in the list of valid values. The legacy ASP-based reporting point handled this gracefully and would allow passing blank/null parameter values to the linked report. But SQL Reporting Services enforces a tighter restriction on what gets passed into the linked report to avoid any possibilities of SQL injection attacks.
A good example where this issue manifests is with reports that deal with status messages. Internally many of the reports define status messages to be a list of valid values (like 0=Information, 1=Warning, 2=Error etc.). If you look at any parent report that provides a high level view of say something like patch deployment status you may see that this report links to a drill-down for a machine specific report for patch deployment. Now it is quite likely that at some point there is no status message available for a particular machine (may be because the patch deployment was delayed for some reason) and that row shows up as blank in the parent report but if you drill down this report SQL Reporting Services will throw an exception that the blank value for status message ID is not acceptable.
Workaround: Run the linked report directly by passing the appropriate set of report parameter values.
4) What about custom reports created under new folders on the old reporting point site?
Yes - all custom reports can be migrated to the SQL Reporting Services server but when you run the Copy Reports Wizard, these custom reports are displayed under their respective report categories and not under their report folders. Basically the Copy Reports wizard classifies all the old reports based on report category and not on report folder.
5) Can I view and run my custom reports authored using SQL Reporting Services tools from the Configuration Manager Administration console?
Yes you can.
a) While configuring the reporting services point role a root folder is configured on the SQL Reporting Server under which all the Configuration Manager reports get deployed. b) As long as all the custom reports authored using various SQL Reporting Services tools are deployed under the report folder configured in a) you will be able to view and run them from the Configuration Manager Administration console.
a) While configuring the reporting services point role a root folder is configured on the SQL Reporting Server under which all the Configuration Manager reports get deployed.
b) As long as all the custom reports authored using various SQL Reporting Services tools are deployed under the report folder configured in a) you will be able to view and run them from the Configuration Manager Administration console.
6) Are named report server instances supported with Configuration Manager 2007 R2 release?
With the R2 release there is no explicit way to specify a named report server instance anywhere. What this means is that we query WMI to retrieve the list of report server instances and pick the first instance returned by WMI.
Implication: If the report server machine has 2 instances of reporting services running on it (let us say the default instance and another named instance) and if WMI returns the default instance as the first instance then that would be the instance used to host all the Configuration Manager reports. So usage of a named instance is non-deterministic and is dependent on what is returned by WMI.
There were some issues that were uncovered after we shipped R2 which introduces a caveat:
a) If the report server machine hosts only a named instance, then we will not be able to detect the named instance since the WMI query we use to enumerate instances requires the presence of the default instance.
Workaround: So in order to detect the named instance, you should have the default instance installed on the same machine.
7) Does Configuration Manager 2007 R2 release support SQL Reporting Services 2008?
Yes - Configuration Manager 2007 R2 release supports both SQL Reporting Services 2005 and SQL Reporting Services 2008. However there are some known issues with leveraging SQL Reporting Services 2008 that are outlined later in this FAQ.
8) What is the support story for SxS (Side-By-Side) scenarios for SQL Reporting Services 2005 and SQL Reporting Services 2008 on the same machine?
As outlined in 6) above, we use WMI to enumerate the list of SQL Reporting Services instances running on a machine. However, there is a preference set internally for this to favor SQL Reporting Services 2008 over SQL Reporting Services 2005. What this means is if you have a SQL Reporting Services 2008 default instance running on the same machine as a SQL Reporting Services 2005 instance, we will first query the WMI namespace for SQL Reporting Services 2008 and use the first instance of SQL Reporting Services 2008 returned by WMI. If no instances of SQL Reporting Services 2008 are detected, we will query the WMI namespace for SQL Reporting Services 2005 and use the first instance returned by WMI.
9) Do we support https enabled report server instances?
There are known issues in the R2 release with https enabled report server instances. There are some methods in the reporting services webservices API that are inherently secure methods and if SSL is configured on a report server instance these methods cannot be invoked via http and require https connections. Internally, since we leverage some of these APIs, we fail to perform some actions.
Workaround: Unfortunately there is no easy workaround for this other than to not use SSL enabled report server instances. However there is a configuration setting that can be tweaked to get around this problem but it is NOT recommended to tweak this setting if the report server instance is hosting other reports (not specific to Configuration Manager).
a) Open the rsreportserver.config file using notepad and search for the property "SecureConnectionLevel". This value should be set to 3 (or some value > 0) for secured report server URLs. Change this value to 0 and save the rsreportserver.config file.
(The default location for the default instance is under [SystemDrive]:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer).
10) What are the various options available to author new SQL Reporting Services reports?
a) Business Development Studio (bundled with SQL Server installation) b) Report Builder (free standalone tool) c) Report creation wizards shipped with Configuration Manager 2007 R2 release.
a) Business Development Studio (bundled with SQL Server installation)
b) Report Builder (free standalone tool)
c) Report creation wizards shipped with Configuration Manager 2007 R2 release.
11) Will all reports run successfully from both the Configuration Manager Administration console and the SQL Reporting Services Web UI?
At the time Configuration Manager 2007 R2 was released, some tools like Report Builder 2.0 weren't released yet and we still weren't supporting SQL Server 2008 at that time. So there are some caveats to authoring and running reports in a SQL Reporting Services 2008 environment.
Full support for authoring and running reports in a SQL Server 2005 environment
- Any out-of-box reports or custom reports written in SMS 2003/Configuration Manager 2007 using the report wizard provided in SMS 2003 and available in Configuration Manager 2007 as well should be converted properly to SRS reports using the Copy Reports Wizard available in R2 and these should run fine both from the Configuration Manager administration console as well as SQL Reporting Services web UI.
- Any custom report authored using the report wizards provided in the R2 release (the SQL based report wizard and the Model based report wizard using the 2 shipped models in R2) should run properly from both the admin console as well SQL Reporting Services Web UI.
o If you plan on creating custom report models then the process entails a few extra steps to make them available in the administration console. The details are provided in our online documentation.
- Any custom report authored in a SQL Reporting Services 2005 environment (like using Business Intelligence Development studio or Report Builder 1.0) should run fine from the admin console.
Partial support for authoring and running reports in a SQL Server 2008 environment
- The Configuration Manager 2007 R2 release uses the SQL Reporting Services 2005 report schema underneath and hence reports authored using Business Development Studio 2008 (as bundled with SQL Server 2008) and Report Builder 2.0 will not run from the Configuration Manager 2007 R2 administration console. However you can author reports using any of the tools available with SQL Reporting Services 2008 and can run these reports from the SQL Reporting Services Web UI directly.
--Bhaskar Krishnan
This posting is provided "AS IS" with no warranties and confers no rights.
[In today's post Josh Pointer captures the Configuration Manager buzz at MMS 2009.]
What a week... That's all I can say after spending 5 days with some of my favorite people on the planet and sharing with them the future of Configuration Manager (or at least parts of it). Sometimes I forget how invigorated I get just by spending the week at MMS with our best customers. It always sends me back to work on the following Monday with a lot of energy to pass on to the team. It also gave me a lot of joy to know we are building the right product to solve the needs of not just today but tomorrow. I have to say my single most happy moment at MMS this year was after the "State of the Union" session and one of the guys we had in a focus group last year came up and said "that is so cool - last year we were kicking this around in a focus group and this year we are seeing it in product." Now that to me makes it all worthwhile knowing we are taking the feedback and generating a product that solves problems for IT Pro's.
I spent much of my time that week meeting and chatting with a lot of customers. It's clear that a lot of people are moving fast to Configuration Manager 2007 it was also clear from the questions that Windows 7 is making its way pretty fast into the enterprise. Also, I met with a lot of customers that are at the early stages of working with Configuration Manager 2007 R2 mostly for the App-V technology focus of that release.
We coined a new key word for Configuration Manager at the conference this year as we started to show off parts of Configuration Manager v.Next: "User Centric". As discussed in Bill Anderson's chat during Brad's keynote it really comes down to one main thing: How do we enable user x to get application y in the most efficient way possible? Today our job as IT Pro's is about finding where we think user x is going to be and trying to get the application to that device (and sometimes we succeed). When that device that user x was on dies or gets replaced we completely loose user x and anything that was relevant to that person. So how do we shift the focus of management from device to user but still allow all the controls necessary to manage devices as well. Lots of products including our own provide facilities to be able to target software to a user but it's all the barriers to doing that, that typically prevent the act from being successful (don't install it on this server farm, don't install it on this secured machine). Sometimes where the application doesn't belong is just as important as where the application does belong.
We also introduced a new persona that we aren't typically used to dealing with in the IT world. The end user is the primary driver of revenue for a company and they are radically changing for our customers. Digital Natives are certainly beginning to show up in the workplace. These are folks that have had a computer their whole life and are very comfortable with technology. They represent the next generation of the work force which over time will be an even larger change than gen x and the baby boomers was. They expect that they can work wherever they want, and they can use technology to solve many of the issues they may have at work. The mantra with these folks is ‘give me what I need when I need it on any device'. So we have begun to build a product that enables the IT Pro to handle the many complexities of these Digital Natives and their needs without making all the explicit actions that have to occur in the product today. The goal here is that the only explicit decision an IT Pro needs to make is "user x gets application y".
So we showed a bit of these capabilities at MMS and the response was overwhelming. People were excited to see the change in the product and the Digital Native was definitely resonating with what people are seeing in their environments. After Brad Anderson's keynote it took me close to an hour to walk what should normally take about 5 minutes just answering questions from excited folks about the future direction of the product and it's abilities to solve those problems. It was awesome!!! As MMS closed down last week and I headed to the airport I realized something and smiled. I was thinking these guys haven't seen anything yet. We have only showed them a small portion of what's to come. I kept thinking "man we are going to blow their socks off at IT Forum in Berlin this year and do it again at MMS next year!"
Stay Tuned,
--Josh Pointer
Group Program Manager
System Center Configuration Manager
[Today's post is from Jeff Gilbert]
The latest downloadable quarterly update for the Configuration Manager 2007 Documentation Library has been posted to the download center. The April 2009 version is the newest downloadable update available and contains new material and fixes to documentation problems reported by customers since the last update was published for the January 2009 version.
Both the January and April 2009 versions of the downloadable documentation help updates are now available on the Configuration Manager 2007 Help File Update Wizard download center page and additional, future quarterly updates will also be posted to this location.
To get the most recent downloadable Configuration Manager Documentation Library help, go to http://www.microsoft.com/downloads/details.aspx?FamilyID=71816b0f-de06-40e0-bce7-ad4b1e4377bb&displaylang=en.
For more information about the Configuration Manager 2007 Help File Update Wizard, see this post: "Need the Latest Configuration Manager 2007 Help File?" at http://blogs.technet.com/configmgrteam/archive/2009/02/03/need-the-latest-configuration-manager-2007-help-file.aspx .
Hope this helps,
~Jeff
The Windows Management Instrumentation (WMI) subsystem has evolved over time to become a key dependency for many applications, Configuration Manager being one of them. We've been intertwined since the .698 build of WMI shipped with Systems Management Server 2.0 (there was even a WBEM Inventory component in SMS 1.2).
Given this history and relationship it's important to know what to do when something goes wrong.
I've spent many years investigating / troubleshooting WMI related issues - especially as they relate to SMS / Configuration Manager. Based on that experience I've compiled a few tips and general observations for the community. This list is by no means comprehensive. Assumptions are made regarding a basic understanding of WMI, such as general structure, terms and usage of the WBEMTest tool.
Don't delete the repository (though it may make problems seem to go away).
Rebuilding the WMI repository is a destructive operation that can lead to data loss, applications breaking, and a whole host of slow to appear, difficult to diagnose problems. Generally speaking, the only time this operation should ~really~ be necessary is in the case of true corruption as indicated by tools such as WMIDiag or Winmgmt /verifyrepository.
Can lost WMI data be recovered? Probably, but that's never a good state to be in. Therefore, I say avoid this operation whenever possible. On the flip side, I certainly recognize there is a tradeoff between operational needs and individual investigations. Over time some customers have seen that rebuilding the repository makes a problem seem to go away quickly. Typically this also comes with a loss of ability to find root cause, could mask other problems, and may not actually solve anything long term. On the whole I strongly recommend against deleting the repository folder as a means to resolving WMI issues.
What can I do other than rebuild the repository?
One low risk, potentially high gain operation that can be performed is to recompile MOF files, and register component DLL's associated with WMI operations. If an important class or component registration needed for WMI operation was somehow removed you can put the needed structure back. These steps can be automated easily, but aren't generally recommended on a large scale as they too can mask issues. This is just one more option to try short of rebuilding the repository. There are variations of the steps below available between XP and Vista, but this most basic version should work for either.
//
1. Open a CMD prompt on the server and change directory to %windir%\System32\WBEM (\SysWOW64\WBEM on x64) 2. Execute the following: FOR /f %s in ('dir /b /s *.dll') do regsvr32 /s %s Net stop /y winmgmt FOR /f %s in ('dir /b *.mof *.mfl') do mofcomp %s Net start winmgmt Note: Don't attempt to compile the MOF files in the \bin\i386 folder on a site server, as we contain stub files (names start with an underscore character such as _smsprov.mof) that need to be populated with site specific data through other means.
1. Open a CMD prompt on the server and change directory to %windir%\System32\WBEM (\SysWOW64\WBEM on x64)
2. Execute the following:
FOR /f %s in ('dir /b /s *.dll') do regsvr32 /s %s Net stop /y winmgmt FOR /f %s in ('dir /b *.mof *.mfl') do mofcomp %s Net start winmgmt
FOR /f %s in ('dir /b /s *.dll') do regsvr32 /s %s
Net stop /y winmgmt
FOR /f %s in ('dir /b *.mof *.mfl') do mofcomp %s
Net start winmgmt
Note: Don't attempt to compile the MOF files in the \bin\i386 folder on a site server, as we contain stub files (names start with an underscore character such as _smsprov.mof) that need to be populated with site specific data through other means.
Outside of that, there are many troubleshooting options available, depending on the amount of time you can spend investigating.
Where can I find the log files and error codes?
Start here: the WMI Troubleshooting page on MSDN. This page serves as a jumping off point for many important details such as logging and tracing information, WMI Error constants, and more.
Common Errors
These errors are referenced in greater detail on the WMI Troubleshooting page and subsequent links but I still wanted to mention them here.
WBEM_E_NOT_FOUND – 0x80041002
The Not Found message was very common in XP log files, a little less so in Vista and up. Without context this one isn't very helpful, as you have no way of knowing if the requested data is supposed to be present. Simply put, it may not always be a bad thing.
Access Denied
Echoing the troubleshooting page, if you're seeing 0x80070005 (E_ACCESS_DENIED) when connecting you're being turned away by DCOM, not WMI. Similarly the 0x800706BA (RPC_S_SERVER_UNAVAILABLE) means you're being turned away before you've talked to DCOM or WMI. A Network capture is often the quickest way to get to make progress for the RPC error. There's also a bit more info in the Remoting and Security blog entry from the WMI team.
WBEM_E_PROVIDER_LOAD_FAILURE - 0x80041013
The Provider Event Troubleshooting Classes are a great resource, but may be a little overwhelming. The MSFT_WmiProvider_LoadOperationFailureEvent class is one that I've found useful quite often. Most Provider Load Failures I've encountered have been the result of bad component registration (either in the registry or WMI), or permissions related.
WBEM_E_INVALID_CLASS - 0x80041010 / WBEM_E_INVALID_NAMESPACE - 0x8004100E
Similar to the Not Found error, context is important here. Some operation was being performed against a class / namespace that isn't present on the target machine. Is that bad? Depends on the situation. It may be perfectly normal. If investigation tell you it's not, the class or namespace can usually be recovered by recompiling the appropriate MOF file.
Generic Failure - 0x80004005
Among the least helpful errors, and not WMI specific. I only bring it up here as many people see this and mistakenly think it's an Access Denied message given the 5 at the end. Remember access denied is 0x80070005
WMIDiag
An invaluable tool for diagnosing WMI issues, even if it's a little dated.
http://www.microsoft.com/technet/scriptcenter/topics/help/wmidiag.mspx
It has many configuration options available and can be deployed via Configuration Manager. One of the more helpful features is the report that is generated at the end. It contains details on how to correct many common issues that are found when running the tool.
Tracking resource usage of WMI
By default the core WMI service lives in the shared Network Services instance of scvhost.exe. This can make debugging or identifying resource issues a little challenging. As a general rule of thumb I run (and recommend to customers) that they keep WMI separated into its own instance of svchost.
On XP/Server 2003 this can be accomplished automatically via the following case sensitive command:
RUNDLL32.EXE %Systemroot%\SYSTEM32\WBEM\WMISVC.DLL,MoveToAlone
For Vista and up this is done with
winmgmt /standalonehost
Where is the provider?
The WMI Provider host process (wmiprvse.exe) will create one instance for each different hosting (security) model defined. To find out which instance by PID a given provider resides in (such as smsprov.dll) you can simply run Tasklist /m smsprov.dll It is possible to isolate a provider into its own instance by changing the hosting model.
This is fairly rare and not necessarily a best practice, but if you're running into resource or performance problems that could be traced back to multiple providers running in the same instance, it may be worth investigating a split - at least for the purpose of issue isolation. The Provider Hosting and Security page has more information.
WMI configuration
There are quite a few options available for tuning WMI performance. Two that I'll cover here are important for Configuration Manager Site (provider) servers - the MemoryPerHost and HandlesPerHost values that can be found in the __ProviderHostQuotaConfiguration class in the root namespace. First a little background: For each instance of WMIPrvse.exe that is running, the classes above dictate how much virtual memory or handles that instance may consume. When exceeding that limit the process may terminate, or in some rare cases may hang. As more providers for various applications are being used on server machines, and Configuration Manager environments get larger, it's expected to see increased resource usage with our provider.
Prior to Vista the limits were 128MB (134217728 bytes) and 4096 handles.
In a large Configuration Manager environment (in terms of number of objects that exist, such as collections, advertisements, AdminUI connections, as well as clients) you could definitely exceed those limits. Quadruple the memoryperhost value to 512MB - 536870912 is the value to enter - is what I recommend to all my customers.
512 is even the default value now on Vista and above, further indication that a larger limit was needed. If performance monitoring tools indicate that you're hitting or exceeding the 4096 handle limit, you can increase that as well but be a little more conservative since handles are a shared resource. It could likely be doubled but I usually recommend 5120, again if monitoring indicates an increase is needed.
It's important to remember that increased memory usage alone is not an indication of a problem state, or a leak - it's quite likely just normal behavior. In other words, many objects (and perhaps many objects from multiple remote connections) mean more resources required to handle everything. If you see the Process ID (PID) of wmiprvse.exe that hosts smsprov.dll changing frequently, or multiple instances of smsprov.dll loaded you should definitely increase this value. Some customers have reported an increase helping with Administrator Console performance as well.
WMI repository stability fix
Lastly, if you're still on XP SP2 or Server 2003 SP1 or SP2 you should apply this fix to help further stabilize the repository files. Note it won't correct a system already having problems but makes for good preventative maintenance. http://support.microsoft.com/kb/933062 for the XP version http://support.microsoft.com/kb/933062 for the Server 2003 version
Thank you,
--Brian Huneycutt
[Today's Post is provided by the Configuration Manager Writing Team]
The Configuration Manager documentation library (http://technet.microsoft.com/en-us/library/bb680651.aspx) has been updated on the Web. See What's New in the Configuration Manager Documentation Library for April 2009 for a list of topics that are new or contain significant changes since the December 2008 update. All content that has been updated for just this month has Updated: April 1, 2009 at the top of the topic.
In particular, you might want to check out the reformatted topics that contain supported configuration information. A new top-level topic named Configuration Manager Supported Configurations has been created that lists information that pertains to all version of Configuration Manager 2007 including: hardware requirements, supported multi-language hierarchy setup configurations, specialized storage technologies, workgroup client considerations, and virtualization environments.
Additionally, the supported configurations topic for each individual release of Configuration Manager has also been reorganized into a more standard template to make the topics easier to read and include information specific to the release. In the individual supported configurations topics, you will find the supported upgrade paths, operating system requirements for both site systems and clients, and other configuration specifics including a section in each topic that describes the SQL Server versions supported to host the site database.
All our topics now have the following footer (above the Tags and Community Content area):
Did you find this information useful? Please click the following link to send your suggestions and comments about the documentation to the Configuration Manager Doc Feedback alias: SMSdocs@microsoft.com
Clicking the link in the Web page opens an email with the Subject line containing the title of the topic, and then appends a long number. This number allows us to uniquely identify the topic, even if the topic title changes - so please do not delete it! Emailing us allows customers to contact the documentation team directly, as an alternative to using the Click to Rate and Give Feedback method at the top of every topic. We've mentioned before that often we cannot action the feedback we get through this Web mechanism because the information customers provide frequently requires two-way communication for clarification and response. We do value customer feedback and try to incorporate it when possible, so we hope that customers will use the email method to provide feedback about specific topics. Although we can't promise to make the docs perfect for everybody, we are committed to continual improvement. So, keep that feedback coming, and feel free to contact us about anything related to the documentation by using this address of SMSDocs@Microsoft.com.
On the subject of documentation enhancements, this last month we've seen some great community content that enriches the documentation for other customers. In case you missed the blog post announcement for this, see Announcement: Community Content on the Configuration Manager Documentation Library.
We hope to have a new local help file available soon for download, so watch this space. The last local help file was for December 2008, so it will contain 3 sets of updates. Not sure what the "local help file for download" means? For more information, see Need the Latest Configuration Manager 2007 Help File?
-- The Configuration Manager Writing Team
[Today's post is provided by Carol Bailey]
By default, an issuing enterprise CA publishes its certificate revocation list (CRL) to locations within the forest. When you are using Internet-based client management with Configuration Manager, there are scenarios where you might need to publish the CRL on a separate server, outside the forest. These scenarios include the following:
In these Internet scenarios, it makes sense to publish a CRL that can be accessed over HTTP with an Internet FQDN. If you already have a Web server in the DMZ that is configured for HTTP, it makes an ideal candidate because you just need to add an additional virtual directory - there's no need to add a host entry into your public DNS, or install and harden a new server to run IIS. However, think twice about using a server running Internet-based site system roles because (with the exception of the fallback status point), these use HTTPS to help secure the server from unauthenticated access. Certificate revocation lists cannot be accessed over HTTPS so to add HTTP access to one of your Internet-based site system servers would greatly increase the risk of an attacker connecting to this server.
Disclaimer: The procedures in this blog post are external to Configuration Manager, so you will not find this information in the Configuration Manager product documentation. However, we realize that PKI is often new to Configuration Manager admins, and aim to share our knowledge and experience to help you be more successful with the product. We would also like to pay tribute to the help and information provided by Amer Kamal and Mark Cooper, senior Premier Field Engineers who have designed and implemented CDPs for our customers.
CRLs (base and deltas) are published to CRL distribution points (CDPs). So in our scenarios, the separate Web server in the DMZ will become a new CDP. You can manually publish the CRL onto this new CDP, or you can automatically publish it. Automatic publishing is a whole lot easier but requires a one-way trust from the Web server (CDP) in the DMZ to the CA server in the intranet, and uses SMB traffic for this connection (which you can secure with IPsec). You would need to discuss the pros and cons of this design with your security guys. On the plus side, the connection is initiated by the trusted network only and the automation helps to reduce the possibility of the CRL not being accessible (which in turn, results in a rejected PKI connection). Manually publishing the CRL is the only option when there is no connectivity allowed between the intranet and the DMZ, and obviously carries a higher administrative overhead with a higher possibility of error.
If you are asking yourself how often the CRL gets published, you can view and configure the publication intervals for the base and delta CRLs, in the Certification Authority console. Right-click Revoked Certificates, click Properties, and the publication intervals are on the CRL Publishing Parameters tab. The default value for the base CRL publication is one week, and the default value for the delta CRL is one day. For more information about these schedules and managing certification revocation, see the Certificate Services documentation, for example: Configuring Certificate Revocation.
If you are allowed some restricted access from the intranet to the DMZ, but this excludes connections directly from the CA server, you can adapt the procedures below such that you publish the CRL onto a new server in the intranet and then copy the files to the server in the DMZ - in other words, you automatically publish the CRL to a staging server in the intranet but computers access the CRL from another server in the DMZ. Similarly, the manually publishing procedure below steps through copying the files using Explorer, but you can script this to help streamline the process for each CRL update. Additionally, the command-line utility, Certutil.exe, can be used to publish the CRL.
When multiple CDPs are listed in a certificate, a connecting computer will try each in turn, until it finds an accessible CRL. Generally, you should list the CDPs in the order in which they are most frequently used. For example, if the majority of the connecting clients were on the Internet, specifying the external HTTP CDP first would mean that these clients would not have to first try (and fail) to locate the CRL from intranet CDPs. However, if the majority of your clients were on the intranet and only a minority of them on the Internet at a given time, specifying the internal CDPs before the external CDPs would make sense. Unfortunately, there isn't a reorder option when configuring the CAs for the list of CDPs, so if you wanted to change the order in which clients tried each listed CDP, you would need to delete the existing entries and re-enter them for the required order.
In overview, the steps you will need to perform to publish the CRL onto a separate Web server include the following: