Here are some of the issues I consider when making that call. The first two are fairly cut-and-dried, but after that it's more subjective.

• How much is the product changing?  Is the next version of the product going to be so fundamentally different that very little of the old content is relevant or accurate? If yes, then you don't have much of a choice - start fresh, and take advantage of what's already written where you can. Most product versions aren't so dramatic or drastic though.
• How much time do you have? If there isn't enough time in the schedule to do a new document, then you update the old one. Even if the old doc really needs a rework. You don't want release delayed because the documentation isn't done or incomplete/missing documentation at release. When the next version just has incremental changes and a handful of new features, and you have plenty of time for documentation, then you go to the next question.
• Is there any feedback or customer data on the existing content? If you've only heard from customers that they love the existing doc, it doesn't mean that you shouldn't evaluate the doc for possible reorganization or structural changes or different approaches to topics, but it does indicate that you should carefully consider the potential impact of major changes on customer satisfaction.On the other hand, suppose customer feedback has been mixed or trending toward negative. This, then, is a great opportunity to start over with a new design that will aim to address any customer complaints or confusion. Sometimes you won't have any real data other than "nobody has complained about it." Then you go to the next question.
• Can you make it better? Different is easy; better can be challenging. (How do you measure, for example?) Are you making changes to mark your turf or to improve the customers' experiences? Can you articulate why you believe the changes are a good idea and what you expect the changes to accomplish?

Even when (1) the product isn't changing that much, and (2) you have plenty of time, and (3) there's really no feedback or data, and (4) you have definite ideas for improvement -- you still want to consider whether reworking this doc (rather than just updating) is the most important thing you could be doing with the time you have.

The job description for my new position included a link to a video that interested me. It had never occurred to me that all the gadgets I take for granted had an operating system - I was so desktop/server-centric. "World of Windows Embedded" really piqued my interest and I'm excited to start learning a new product.

 [View:https://www.youtube.com/watch?v=zpwANN22lNY]

• The Authoring Guide adds a new topic, "Diagnostics and Recoveries".
• "What's New" adds an introduction to using Orchestrator in place of connectors.
• Supported Configurations:
• Adds the requirement of .NET Framework 4 if a gateway server manages UNIX/Linux computers or network devices.
• Adds the requirement to install the web console to view Application Performance Monitoring event details.
• The Deployment Guide:
• Clarifies the order to install a management server and the web console on the same computer.
• Adds notes in regards to existing AVIcode 5.7 agents.
• Adds a procedure for assigning UNIX/Linux agents to a resource pool.
• The Operations Guide:
• Adds more tasks to the "Quick Reference".
• Adds the NOAPM parameter to the instructions for installing an agent from the command line.
• Adds note for Solaris UTF-8 support.
• Adds instructions on using a VLAN tag for network monitoring.
• Adds instructions for changing the default session limit for the web console.
• Adds instructions for using scripts to configure the Operations Manager Web Part on SharePoint
• New topics
• Control Access by Using the Health Service Lockdown Tool
• Operations Manager Reports Library
• How to View Group Members, State, and Diagram
• Connecting Management Groups
• Using Operations Manager Shell
• How and When to Clear the Cache
• Recommendations for Daily, Weekly, and Monthly Operations Manager Tasks

• What's New has been reorganized, with some art added, including an upgrade diagram and links to more detailed diagrams. Be sure to notice that the steps in the detailed diagrams each link to the corresponding content.
• Key Concepts has been moved from the Operations Guide to the Getting Started section. In beta, it was basically a stub topic with a few paragraphs, but for RC more of the content has been filled in and it also has art added.
• The release notes and Supported Configurations have been updated.
• Sections of the Deployment Guide have been expanded since beta, such as single-server and distributed deployments. Disaster recovery has been added to the "Backup and Disaster Recovery" section, and also a number of procedures for "Making Changes to an Operations Manager Environment".
• The Operations Guide has expanded content in a number of sections. "Application Monitoring Operator" has been added to the user roles. There is added information for UNIX/Linux credentials and for Run As account distribution. Information has been added to "Network Devices Supported for Discovery", which also links to Network Devices with Extended Monitoring Capability spreadsheet. The section on .NET Application Monitoring is also expanded.
• Last but not least, the Authoring Guide and Cmdlet help are added to the library.
• You also might notice a single topic for Report Authoring -- the Report Authoring Guide for Operations Manager 2007 R2 was just recently rewritten, and (other than the product name) the information is still applicable, so please continue to use the R2 guide for creating reports.    

There is still a lot of content to add - you can see a number of placeholders in the Operations Guide, for example, and we have the entire planning & design section of the Deployment Guide to add. We plan to refresh the TechNet library on a monthly basis to add the new content as it's written. The tentative target for the next refresh is 15 Dec -- follow us on Twitter (@opsmandoc) to be sure to get all announcements.

Anyway, the following is what I came up with for the basic guidance to an admin (not an MP developer):

 When you create a group, you save it to an unsealed management pack. However, an element in an unsealed management pack, such as a group, cannot reference an element in a different unsealed management pack, such as an override or a view. If you are going to use a group to target an override or scope a view, you must either save the group to the same unsealed management pack as the override or view, or you must seal the management pack that contains the group.

If you save the group to the same unsealed management pack as the override or view, you can only use that group for overrides and views that are also contained in that unsealed management pack.

If you seal the management pack that contains the group, you can reference that group from other unsealed management packs. However, you cannot easily change any group settings in the sealed management pack or add new groups to the sealed management pack.

Before you create any groups in Operations Manager 2012, you should plan what groups you will need, the purpose each group will serve, and how to save the group in a manner that will allow it to be used for its intended purpose.

It's common for us to say our audience is the IT pro. But "IT pro" is a lazy shortcut to refer to a wide variety of people and positions. Does every IT pro know how to configure and manage permissions for SQL Server databases? Not necessarily, but the IT pro who uses Operations Manager should. So rather than just relying on the amorphous "IT pro" label, I think we should provide a list or overview of the skills and knowledge you need to successfully install and use Operations Manager.

Think about when you first started using Operations Manager -- what did you need to know about SQL Server, IIS, Windows Server, Active Directory, DNS, PowerShell...? About anything? If you were going to hire someone to set up and run Operations Manager in your environment, what skills and knowledge would you expect them to have? Please click "Email Blog Author" over there on the right and let me know your thoughts!

Edited to add: Just to clarify, I'm looking for the expertise with other products and technologies that you need before getting started with Operations Manager.

The documentation is available on the download site, but we also put it on our TechNet library-- Quick Start, Deployment Guide, Operations Guide, and Supported Configurations. The Quick Start is complete for beta, giving you a set of procedures to try out Operations Manager starting with a clean stand-alone install. The other documents are works in progress -- there will be a lot more content in them by the next release.

And something new...flow diagrams for upgrading an Operations Manager 2007 management group. Interesting viewing, even if you're not upgrading any time soon.

Check them out and let us know what you think. (There's an email link to the writers' team at the bottom of the flow chart. Actually, that email link is at the bottom of every page in our documentation set online for beta - we really do want to hear from you.)

What else do you do with Operations Manager that you think this type of diagram would help you with?

(edited to add tags)

More details: The survey will be sent out approximately 21 March. We will use your responses to help us make decisions about organization and terminology so that the Operations Guide for the next version of OpsMgr will be easier to use. There won't be any information about the next version in the survey, so a non-disclosure agreement (NDA) is not necessary. We hope to get input from OpsMgr novices, experts, and everyone in between.

edited to add: We'll ask that you reply to the survey by 1 April, so that will allow plenty of time for those who are busy the week of the 21st with MMS. 

Lately, I'm encountering that "widget" on more and more sites. Multiple widgets on some -- 3 or 4 between search results and the actual page. Since it finally became too annoying to overlook, I added the widget.pulsemgr.com address to my restricted site (Tools -> Internet Options -> Security tab).

Now "Back" works properly again, I'm content.

As I was going through the current content, it seemed like we mention user roles in a few places but don't really integrate them in the rest of the content. I'm thinking for v.Next, I should add which user roles can do something for every task/procedure. So, if I'm a Read-Only Operator looking at the operator's guide, I can immediately see whether I can do this thing I'm looking up or not.

I don't know yet whether to include it at the beginning of each topic ("this information applies to the Operator user role"), at the end, preceding each procedure...somewhere consistent, definitely.

What do you think, would user roles be a useful addition to relevant topics? Or are user roles easy enough to understand that it isn't necessary?