DavidRandall

Steve, if you have your clients already running and fully functional in ConfigMgr 2007, then you can create a package in ConfigMgr 2007 with the System Center 2012 Configuration Manager client files. Then, you can create an advertisement and target the sets of clients that you want to move over to Configuration Manager on a schedule that you manage. Your command line would need to contain (at a minimum) the parameters: /MP:<servername> /upgrade SMSMP=<servername> SMSSITECODE=<sitecode>. You would replace <servername> with the hostname of your management point, and <sitecode> with the sitecode of your System Center 2012 Configuration Manager site. The following page provides more information about the methods of client installation, and why you might choose one method over another. http://technet.microsoft.com/en-us/library/gg682191.aspx

You somewhat answered your own question in 2a / 2b. You'll need to assess the requirements to move to newer versions, but I agree, it's simpler to have done your migration from ConfigMgr 2007 to System Center 2012 Configuration Manager first - then do the Service Manager integration. Probably worth having more communication with the other team about how to coordinate migrations and integration so that you all get moved over quickly, but don't create too much extra work for either team. I'm not sure what the licensing or purchasing options are, but I do know that each product maintains its own installer, so you even if you did decide to purchase the entire System Center 2012 product, you can still install each component separately as needed. Dave

This typically happens when Software Center cannot find a distribution point. Ensure you have distributed the application (or package) to the distribution point, and that it successfully got there. You can use the Monitoring section of the console to verify the status of the content. You might need to "update distribution points" to re-try transferring the software to the distribution point if it had gotten stuck for some reason. Hope that helps Dave

Wake on LAN and the vPro integration are separate. Out of band management can also send power-on commands to a vPro enabled device, but ConfigMgr can also send the magic packet to devices to wake them up without any requirements for AMT/vPro/out of band management. That said, in System Center 2012 Configuration Manager, you will need to enable the out of band management point site system role to get the functionality required to send out the magic packets from the server. Even though the out of band management capabilities are not required, you must deploy that role to get WoL to work.

Unfortunately, the system does not provide a native revocation feature. Once the application has been approved for the user, it is available for them to install on any system. You can modify the requirements for the application to leverage the "primary user" rule - that would allow the user to only install the application on systems for which they are a primary user. You could also leverage those rules to query for properties that would indicate they are only allowed as a finance person, but not as a PA person. Additionally, targeting for the application catalog is based on collection membership, so if the finance person moved departements, and was no longer in the collection that allowed the application installation, they won't see it in the catalog. Additionally, the system prioritizes "install" deployments over "uninstall" deployments. So, the user could be a member of two collections that both have the application targeted to the collections, one with an Install intent, and the other with an "uninstall" intent. The uninstall intent deployment would likely target devices, not users. As soon as the user is removed the from the "install" intent collection, the "uninstall" deployment takes effect and removes the application. HTH Dave

There isn't a way to deploy OSD to a single machine natively (e.g. right-click a computer and choose "OSD") Two things I can think of: 1. Create a collection with that one computer in it and deploy the task sequence to that collection. 2. You can create a collection that has a required deployment associated with it, and then just add a direct member to the collection (e.g. the new computer you want the TS to run on). Obviously, if you were leaving that collection in the system, you'd want to be sure that it's only used for one computer at a time (and not have an "all systems" query). Once the TS is run, you could remove the system from the collection. Good scenario to test in a lab first. Dave

Conceptually, start by thinking of it like this: Package = "run a command" Application = "keep a program installed on this system" As @willisj318 states, there are other features in the system that are tied to applications (versus packages). However, in the end, ConfigMgr has no idea what running the "install command" did in a package. I could run a batch file, format a disk, set some environment variables, uninstall an MSI, or install an application. Once it ran the command, it was unaware of the change made. Applications (and the application model that they are based on) capture much more about the intent that you as an administrator have for that application. For example, you can define requirement rules for the application. The system determines at install time whether the application meets the requirement rules. Typically, in ConfigMgr 2007 or in MSI's themselves, you had to define collections with those requirement rules, or create custom actions in the MSI to enforce the requirements. A requirement can also be the presence of another application (e.g. a dependency) - so the system will automatically install a required program if it's not present. Applications also can be enforced to be removed (and they will get removed again if the user re-installs them). Applications can be superseded with a new version and have the old version automatically removed. Applications can have their versions tracked over time and you can revert the system back to a previous version if needed. There are many advantages to applications, and we encourage you to look at moving your applications into the application model, out of packages. There may be some need to retain packages (they do work effectively at running scripts or doing simple "tasks"). Software Center can deploy and manage both packages and applications, but the Installed Software tab in Software Center only shows applications (reason being - a package could be simply a script that was run, not a real application that was installed). The Application Catalog supports both packages and applications, but there is limited information for a package that can be shown to users in the application catalog. Some additional info is here: http://technet.microsoft.com/en-us/library/gg699359.aspx under the "Software Deployment" section. Hope that helps! Dave

Two primary sites won't provide 100% redundancy, as they are not mirrors of each other. If you have two primary sites in your environment, you'll likely also have a Central Administration Site (CAS) that both primary sites connect to. Both primary sites will get global data (e.g. the collections, collection properties, applications, and other things that the administrator adds to the system). So, in that way, there is redundancy. However, each site will have a set of clients that are managed, and the information that each client sends to its assigned primary site (e.g. inventory, status, or state messages) is not shared with the other primary site, it's simply forwarded up to the central administration site. Yes, you can re-assign clients from one primary site to another by running a simple script on the client or using the control panel applet on each client. The Survival Guide is a great place to get the most commonly asked information: http://social.technet.microsoft.com/wiki/contents/articles/7075.system-center-2012-configuration-manager-survival-guide-en-us.aspx Additionally, this planning for recovery guide should also answer some questions about how to plan for backup & recovery: http://technet.microsoft.com/en-us/library/gg712686.aspx Dave

The server locator point site system role has been removed. The functionality that was provided by the server locator point was merged into the management point site system role. You should update the ccmsetup command line by replacing the "FSP=SIF" value with "SMSMP=SIF". The client will then use SIF as its initial management point to get additional information about the site configuration. You won't need to worry about the SLP behavior so long as you have the "SMSMP=" clause in your command line. The following documentation may also help for your installation: http://technet.microsoft.com/en-us/library/gg712298.aspx Dave

Software Center does not have configurable options to suppress the icon or notifications natively in the client agent control panel applet or in Software Center Options. However, users can use Windows to configure whether the icon is displayed and whether notifications are shown. Additionally, you can configure available deployments notifications to say "Display in Software Center, and only show notifications for computer restarts". This setting is in the deployment properties, on the User Experience tab. This will prevent the initial "New software is available" notification from displaying, but will still notify the user if the software enforces a restart. Dave

Configuration Manager applications have two types of categories, Administrator Categories, and User Categories. Administrator categories are those used by the IT Administrator to group applications together for purposes of organizing the applications in the console. You can modify the administrator categories by right-clicking on an application, then choosing "Categorize" from the actions, or choose "Classify" from the ribbon. Then you can add/create/manage the categories for the application. This helps you by also allowing application filtering by category. For example, you can "Add Criteria" for the search filter to include the Adminstrator Categories and then add a category to limit your view of applications. User categories are shown in the application catalog web site. Users can filter on these categories to limit the list of applications used in the search criteria, or simply to browse a category of applications. You can set user categories by modifying the properties of an application, and choosing the "Application Catalog" tab - then setting the values in the User Category field. The types of categories that make the most sense for users might be different than the categories used by your IT department to categorize applications for workflow or organizational purposes, so that's why we have the two types. Dave

Take a look at this article: http://blogs.technet.com/b/server-cloud/archive/2012/03/28/business-hours-vs-maintenance-windows-with-system-center-2012-configuration-manager.aspx The admin enforces the installation time via the deployment's deadline. The user can install it before the deadline (e.g. at their convenience) but the software will install when the deadline hits. Even if the user has configured business hours, the software will install at the deadline (or before, if the user chooses to install it ahead of the deadline). The only exception would be when a maintenance window is configured for that system, and the deadline is outside of the configured maintenance windows. In that case,the system will wait until the next available maintenance window to install. Maintenance windows and business hours are similar concepts, but the system treats them differently when it comes to automatically installing software. I understand you want to disable user configured business hours, but that capability isn't built in natively to the client agent as an on/off flag. You can use Settings Management to enforce a specific set of business hours for your users (e.g. your company default business hours). You can create use a CI to get/set those business hours utilizing the SDK (in the same manner as the posted script). By using settings management, you can rely on the system to reset the business hours back to a default value (e.g. company standard) even if the users go and change them. Dave