Search the Community

Hei ho, I wonder if anyone can help me with this strange error. I have followed the the instructions here to a tee to install a test of SCCM 2012 but have hit a strange error - Config. Manager cannot connect to the site. And this has me perplexed as the account I am using has full domain rights to this test server, has full access to all files\folders, full access to SQL and was used to install SCCM itself. The only item I cannot confirm is point 4: been assigned to at least one role based admin security role. I am presuming that as the account was used to install in the system it should have access, but maybe I am wrong. The SQL Server 2008 has been patched to SP2 with CU7 and is running locally with all the correct edits to accomodate SCCM 2012 If anyone has any advise, I would appreciate it! Attached is a screen shot of the error message

Hi. Ran into a weird thing. We're deploying Config Manager updates via SCUP, and a number of our clients (all of them 32-bit so far) were failing to install the SP1 CU 5 patch for the CM client. The error in the event log was a 1706 saying it couldn't find a valid client.msi package. Digging around in the registry, all of these clients that I've seen so far had an installsource value in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{FD794BF1-657D-43B6-B183-603277B8D6C8} of "\\siteServer\Client\i386" - this share was indeed inaccessible Clients that patched successfully (both 32 and 64 bit) had a value of "c:\windows\ccmsetup\{Product Code for 32 or 64-bit client}" in there, instead. Changing the reg key on problem systems to point to the local copy of the .msi did not work, though I didn't try rebooting them, since they're all live systems. Changing the NTFS permissions on the \\siteserver\client share to grant everyone read (share permissions were already everyone=read) allowed these systems to patch. A system I was testing with and had changed the reg key to point at the local copy of the MSI actually changed that key back to \\siteServer\Client\i386 after patching was complete. So what I'm wondering, is: Is the differing InstallSource location normal behavior? Should the client share have had Everyone with Read on it already? If 2. is "yes" then what's the best way to make sure permissions aren't hosed elsewhere as well? Just wait til something breaks? Reset? Other? If 2. is "no" then what are potential repercussions of granting everyone read access? I'm thinking nothing, but...

Just wondering what permissions does these SCCM 2012's service accounts need EXACTLY, for example: ClientInst = Local Administrator on site computers Network Access Account = ?? What permissions on the file server source?! Domain Join = ?? What permissions, where and how to set these? SQL Service account = ?? SCCM Admin = ?? What and where Definitive list would be good... also looking for some kind of guide for SCCM 2012 Delta Group Policy, how to set the user rights assignments right and so on... Thx in advance.

Hey, I'm hoping someone can point me in the right direction. I'm having an issue in getting my application pool identity cmWebSvc to have enough permissions to query the SCCM SQL database. If I use my CMAdmin account the web service returns results as expected. This is how I currently have it configured but it doesn't seem to be enough.. Could anyone shed some light? Thanks!

Hello all, For a client, we have a number of small offices with a local IT resource in charge of the systems there, something thing 45 offices. We've created query based collections to limit the local IT to seeing only their computers in the console, and this is working fine. However, we also have a large number of Software Distribution collections, and we want local IT to be able to place the users in those collections to deploy software. How do I allow the local IT user to do so, without having to manually add Application Deployment Manager to each one of these collections, for each one of the offices? Is there a better way? I'm still trying to understand Role based access and control, and did extensive googling before posting here. Thanks,

I have packaged up both script and msi based packages in sccm 2012 sp1 and deployed them to user collections. In the application catalog, they display correctly, but when I attempt to install them as a user with 'user' level permissions, the applications fail to install. These applications run fine when launched from the catalog by an 'administrator' level account. In event viewer, the application generates a an error that the user it failed for did not have the necessary permissions to install for all users. I also see logs such as SCClient_domain@user.log and I get the following error: ErrorCode = 2278556452 associated with the application but I have been unable to find information for that code. Does the Application Catalog not use an installer account with elevated permissions? If not, how do you deploy applications to users? Thanks. **I checked the certificate from Microsoft Code Signing PCA and it expired 3/4/2013. I am not sure if this could be causing it.

Hi, I am having a very strange error crop up while testing the deploy and capture of a boot OS via a task sequence. The error occurs on x86 or x64, on VM's or physical clients. SCCM 2012 is installed per the fantastic tutorial here and this error is appearing on part 7. When deploying the boot image to the target pc, the PE environment loads and immediately resets the client pc with this error: Failed to run task sequence - An error occurred while retrieving policy for this computer (0x80004005) After some searching around I found and tried these: Link 1: Permissions & Link 2: Certificates Unfortunately, neither helped. I have granted sufficient permissions to client systems to access the boot.wim image and the only certificate available is loaded into SCCM and is unblocked. Its difficult to be 100% sure re the certificates issue, as that link is to a 2007 SCCM structure and I think that Admin.\Security\Certificates would be the corresponding location in 2012. At this point I have reinstalled the distribution point, setup new boot images for both x86 & x64, created new tasks and sent them out to the clients and still ... nothing. Clients are still restarting immediately after the PE loads. I have tried to look at the smsts.log on the clients, but they are listed as empty, so cannot. The smspxe.log file reports business as usual with no unusual\error based behaviour. Any ideas anyone or anyWeb? At this point I am at my wits end, but need to continue regardless... Cheers & Thanks

I am attempting to capture an x64 image of Windows 7 using SCCM and an image capture disk. I am getting an error that indicates that the user account that I am using to capture and write the image to a directory on the SCCM server does not have proper permissions to to write images to the directory in question. I have checked the NT permissions for the account that I am using and it does in fact have full permissions (this is a Domain Admin acocunt) Here are the steps I am following to failure - insert the disk - enter unc path to directory .wim file is to be written to - enter some other info (version, notes, etc...) - start the image capture process - watch machine reboot - watch the death of my SCCM x64 dream as I see the 0x800704cf one more time All indications that I have fond searching Google are that the account doens't have permission but it does. Any help or even useful ideas would be most appreciated.

Hi everybody! We have a SCCM 2007 R2 environment with nearly 20 secondary sites under 1 central site. Now it comes to security permissions delegations to the local admin at the local sites that they can do their Windows 7 Rollout. I created a security structure in SCCM with a flat hierarchie of groups in the AD. For the moment it works fine. A few days ago we had the situation that seems to clear all PXE flags to the "All Systems" collections. Many machiens that will get an OS over a Task Sequence were still in the OS Deployment collection (mandentory advertised), that means that these machine would have get a new OS after the next PXE request (default value!). In the end nothing happens, because we noticed that very fast. I just stopped our local WDS Service and deleted the direct membership of the machines in the OSD collections. Pig had I'm very scared about that, because the next time that happens we may be not so fast. The first question that I have: How can I figure out who deleted the PXE flag? I searched in several log files, queried the Status Messages, but nothing. Anybody knows where I can find that? The second interesting is: How can I prevent that a delegated user (also like everybody!) can clear the PXE flags on a completly collection?? (What also might be possible to use a script that the direct membership of the computers will be deleted after a successful OSD. I guess I saw somewhere a script like this...) Thanks in advance! Christian