dlakey

I have some questions about the Deployment Status > Success Categories. I have recently deployed an application to 7,700+ workstations. Checking on the Deployment Status > Success tab, I see 2 categories listed, Already Compliant and Success I thought I understood what these categories meant. Already Compliant = Application is already installed. Success = Application installed successfully The problem is this application was not previously installed and wasn't already on the workstations. The next thing I noticed was that the numbers were changing, Already Compliant dropping and Success increasing. What does Already Compliant really mean under the Deployment Status > Success? How does it flow from Already Compliant to Success?

I went to Global Knowledge last year for Administering System Center 2012 Configuration Manager (M10747). http://www.globalknowledge.com/training/course.asp?pageid=9&courseid=16983&country=United+States

In preparation to upgrade to Configuration Manager 2012 SP1, I am having problems with the Site Maintenance Task - Backup Site Server. The selection of the "Local drive for site server" is grayed out which prevents selection. I have also tried to save to another server, but look to be having issues regarding what looks to be the path issue with the CreateFile operation. I have attempted to use the workarounds listed at http://blogs.technet.com/b/configurationmgr/archive/2012/08/01/support-tip-a-backup-site-server-maintenance-task-may-fail-to-run-in-configmgr-2012.aspx, but without the access to select the local drive it makes it difficult. I can't use the SQL Server instead since it's a cluster used by various things much more critical. Any suggestions would be greatly appreciated, dlakey

My CAS runs Windows Server 2008 R2, 8 Core 2.67 GHz Xeon Processor, 32 GB Ram. My DP's run Windows Server 2008 R2, Quad Core 2.67 GHz Xeon Processor, 16 GB Ram. Let me know if you need any other information concerning my configuration.

Jörgen, That is what I was afraid of. Personally, it just doesn't make sense to have to change that setting for each application I am deploying. I am sure that Microsoft has some great reasoning behind the default set to manual and not allowing us to set our own defaults. It's just one more thing we have to remember when deploying applications, as if things aren't complicated enough already. Thanks, David

SCCM 2012 with Cumulative Update 1 installed. When I enable Multicast on my Distribution Point and attempt to image a single workstation, I get an error when the multicast session attempts to download the image. When I disable Multicast, imaging functions without issue. Any suggestions?

How can I change the default of the Prestaged distribution point settings from Manually copy the content in this package to the distribution point to Automatically download content when packages are assigned to distribution points?

I followed the instructions on the blog below and it worked just fine. I use the application during OSD and as a seperate installation. http://blogs.technet.com/b/mniehaus/archive/2011/08/13/deploying-office-2010-with-configuration-manager-2012-bet

During Cumulative Update 1 Installation, received warning message show in log file: "Task status detail added: A SqlException occurred, Line Number: 51Error: 229 Message: The EXECUTE permission was denied on the object 'fnIsPrimary', database 'xxxxxxCAS', schema 'dbo'." Is there a way to re-run the SQL database update manually to ensure that it gets updated? I have attached the log file if anyone is interested. Davidconfigmgr2012-rtm-cu1-kb2717295-x64-enu.log

I have had this happen a couple of times for three different applications. I deploy an application to a Device Collection. It appears in Software Center just fine, install, uninstalls work as well. Then at some point the "AVAILABLE AFTER" date displayed in Software Center changes to 4/10/1998. After that happens, it may or may not function any more. I have tried deleting the deployment and setting it back up. Uninstalling and re-installing the Config Mgr client. Rebooting the servers. Rebuilding the application within SCCM appears to be the only thing that fixes the date issue and brings the application back to life. Any suggestions would be greatly appreciated?