draker

I found the solution. In our environment we have separate admin accounts. The console is ran using that admin account. I simply had to add my admin user as a local admin on my workstation. I've also had other admins test this and it is working for them. Problem solved!

Hello! We have an SCCM 2012r2 (No CUs) environment setup in a single AD site. It consists of a single primary site server, one DP, and a dedicated MSSQL box. No PKI configured. We are using self signed certs that are created as part of the wizard. We have delegated admin rights for other users. The problem we are having is these delegated admins are no longer able to create Task Sequence Media. No longer, meaning this used to work. When a delegated admin is attempting to create bootable media, they are prompted for credentials after the Summary step in the wizard. These credentials will fail and leave the following in the logs: CreateTSMedia.log: Failed to open to WMI namespace '\\oursccmsite.com\root\SMS\site_101' (80070005) Failed to open WMI namespace '\\oursccmsite.com\root\SMS\site_101' (0x80070005) CreateTsMedia failed with error 0x80070005, details='' 80070005 = access denied. Media creation does work with my credentials, which has local admin on all site servers. This leads me to believe the issue is actually related to WMI permissions on the primary site server? Are there some additional permission I need to check on the server side to allow for media creation? Do I need read access to WMI on the primary site server or write access as well? Things I've tested: Disable host firewalls = Test failed Create test user with full global admin permissions within SCCM = Test failed Added test user to local admins group on primary site server = Test Failed In all of these scenarios, using my admin credentials will allow for media creation. Any feedback would be appreciated. Thank you!

Yeah, correct. I just don't think that hotfix applies in my situation. Was there another slow download issue noted/resolved in a later CU?

I recall seeing issues with slow OSD deployments and there was a fix for that in one of the CU's. I don't know if that fix applies to deployments that are not OSD. I do agree that upgrading to R2 SP1 is a good idea.. although with SCCM 2016 around the corner I was hoping to delay a bit.

We are experience a strange issue with some application deployments. It appears application deployments containing a large number of files are very slow to deploy. Examples being Adobe products and Autodesk products, but not limited to these applications. Initially, I thought perhaps network bandwidth might be the issue however, if I download a file directly from the DP via http, it downloads at normal speed. On the flipside, if we deploy autodesk, the download will sit at 0% on the client for a very long time. Hours even or days even.. As a test we zipped the files and did a test deployment transferring a large zip, and it downloaded quickly. Looking at the IIS logs I see files downloading to the client, but at a very slow rate. Generally I'll see a 401 - not authorized, followed by a 200 right after with domain\computeraccount$ for credentials. Smaller deployments work great. There are no bits throttling settings specified. No 404 errors seen in the IIS logs. No bandwidth throttling in IIS. bitsadmin /list /allusers usually shows 'CONNECTING' state. I am at a loss about where to look next to troubleshoot this issue.

Thanks for the replies! I will give it a shot next week. Do you run the wizard with all clean-up options selected?

Hello, I have read several articles on WSUS and SCCM. Many articles don't mention the fact that WSUS if not maintained will eventually slow to a grinding halt because it needs monthly maintenance ran on the DB. This article actually describes what I am trying to avoid pretty well! http://blog.coretech.dk/kea/house-of-cardsthe-configmgr-software-update-point-and-wsus/ I've also been told that no changes should be made to WSUS because SCCM controls the WSUS server. At this point I have edited the membership on all expired and superseded updates. I would like to run the cleanup wizard on the WSUS server.. and if it fails I would like to run manual obsolete update queries on the DB as described in the linked article above. I have ran these on our standalone WSUS instances with great success. My concern here is that somehow SUP will break because updates are missing or something. I have read the articles on manual cleanups of the source directory etc, that's not what I am looking to do. I am looking to maintain WSUS so my nightly syncs don't start failing.. etc. Can anyone speak to what is described in the linked article above? Is running the wsus cleanup wizards monthly safe?

Premier confirmed sharing the logs in the Logs folder is fine.

For those of you that have delegated OU admins how do you handle access to the server logs? Do you delegate read access to the logs folder?

And updates here? Looking to see how your roles look compared to mine.

I can confirm, that's how the collections are setup.

I'll confirm this tomorrow.

I would love to compare them side by side. Also, I've got some other questions for you regarding delegation. But I'll wait until I can compare.

For the computer import role:

Thanks for the input so far. I'll post what I have setup so far. It sounds very similar. btw, I'll try that query. OU Admin Read Only Permissions: Permissions assigned to: OU Admins Specific Scope Rolls Assigned to OU Admin: