willisj318

This is sort of a PITA to accomplish but it is how we are running here with 250+ OUs each needing this. We have done it via security scopes, custom roles, and limiting collections. For example. OU1 needs rights to OU1 PCs and has to be able to deploy Corporate pakcages,make their own, but not modify corporate packages. Also needs to be able to import computers. I can provide more details, but in general. Create a role for 'read' access and assign it to the 'read' scope you will be creating. This gets assigned to the user under the Security Scopes tab > Associate assigned security..... menu. Create a role for 'write' and assign it to the security scope you create for the OU. Assign the OU top most level collection to this. Create a role for import computers. default scope is ok. Assign it to the limiting collection for that OU. The limiting collection should be based off of all systems. We query machines like so. We only import computers for imaging purposes. select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where (SMS_R_System.ResourceId not in (select SMS_R_System.ResourceId from SMS_R_System where SMS_R_System.Client = 1) and SMS_R_System.AgentName like "%Manual%" and SMS_R_System.Name like "%OU GOES HERE%") That says give it to OU if manual build and no sccm client. We also have a role for distributing content to the DP and a scope to go along with that. This can probably be done simpler, but we decided to segregate some of the roles, we feel if anything needs to be changed going forward this may be easier on us. I can provide screen shots and more details if you want.

Windows 7 x86 and 7 x64 are not the same OS, one is 32 bit and one is 64. They have a separate checkbox for each for you to choose from.

Yes. Create two deployment types. Under requirements of the deployment select the appropriate OS to install it on.

Your deployment settings purpose needs to be REQUIRED and in user experience make sure it is set to Hide in software center and all notifications. Or if it is a package uncheck the allow users to run this independently box.

Choose download to get it into the package. R2 might be slightly different.

Just going by what you have in the post, you don't mention ever deploying the updates. If you do not deploy them the status will be unknown for clients. Otherwise the clients do not get the sccm policy for the WSUS server, unless you are setting it via GPO.

Can you post a screen shot of what you see?

No problem, I tried to explain it in print as well as I could. I have documentation I have done I don't mind taking out our company info and sharing if you wish. Yes what Peter said as well. They are necessary in any scenario.

Nope. What we did was create the update group and driver package on the first run through of updates. We did this on our CAS as we will update the entire enterprise in the same fashion. I attached a screen shot. Each update group is associated with its update package. As you can see some groups are broken down a bit oddly due to the 1000 update deployment limit for update groups. Our old update groups are deployed and simply sit that way forever. So 2009 Updates is deployed to our patching collection, if someone builds a machine by the DVD for some reason, it gets updated fully. In June we will run our update scan, create our 2014-06 update group and create two deployments. One to our test patch systems, and one to our prod systems. The updates sit in the 2014-06 update group, and the 2014 update package. Once done I will go into the all updates group you see and remove any expired and superseded updates from any update group. Every few months I will remove the old month specific groups. So in June I will remove the march update group. Simply by editing it the membership to be in the main 2014 update groups and no longer the march one, then delete the march one. We only keep the past 3 or 4 months because people sometimes want them for reporting. I anticipate that sometime soon we will be able to remove the 2009 and 2010 group. It sounds like a lot but really takes about 20 minutes of work to do. Honestly probably not even that much.

We don't worry about creating specific groups for specific platforms. The machines will only find and get the updates they need. We do our updates by past year and past 3 months. They get assigned and clients pull whatever they need. Any new machine gets the required updates no matter how they were built. It is probably 20 minutes of work max once a month.

You need a /qn on your command line. We use a batch file which uses the setup.exe and has a reg edit to remove entries from the registry. And lastly any directories from the users profile. setup.exe --uninstall --force-uninstall regedit /s removeChromeRegEntries.reg rmdir %LOCALAPPDATA%\Google /S /Q

Quite odd indeed, all I see of note is this Disk full: Out of disk space -- Volume: 'D:'; required space: 2.198 KB; available space: 0 KB. Free some disk space and retry. MSI (s) (8C:34) [13:26:53:910]: Product: Configuration Manager Client -- Disk full: Out of disk space -- Volume: 'D:'; required space: 2.198 KB; available space: 0 KB. Free some disk space and retry. then trying a repair again Property(S): WelcomeDialog_DesktopWarning = WARNING: A previous version of the ConfigMgr client agent is already installed on this computer. Continuing will cause the previous version of the ConfigMgr client agent to be removed.

Indeed, which is what I don't want. So it is now clear to me why the Only Instance of objects method wont work for us. Thank you.

Thanks Peter. Yes looks like I simply cant use the Only Instances method. I understand the concept (I think, god knows I should I've read enough about it), but not the deployment of them. With the scope I am defining the object, in this case, Adobe Reader. I apply the 'READ' scope. Which is associated with the 'READ' role. If this role is all the user has assigned, the user has read access as anticipated. The second I give the USER the 'WRITE' role, regardless of what happens in the "Only the instances...." section. The user can now make edits to Adobe, even though I did not assign the write scope to the Adobe Package. The way I understand it is that since we have only applied the read scope to Adobe, that is what rights users should have. However that is not the case. To do it that way I'm thinking it should work, or does work in this case, I need to use the Associate Assigned option. Doing it there lets me (so far) assign rights how I need them. Since it is here that I can assign the read role with the read scope. As the other method, there is no way. This leads me to my greater problem. Scripting this out or copying the admin user. I have found no way in powershell to add admin users and their rights to the Associate assigned security.... section. it always adds it to the top part. We are thinking of working with our SQL guys and monitoring the DB and editing it directly. But we would really like a script for when we bring on new divisions and whatnot.

Sorry if I missed this but have you tried updating the new image yet? And then testing?

I don't know that as a fact, just what it seems like via the log. I don't believe the client is supposed to stay installed doing the capture. We don't really use that method here and I have not messed with it much. My knowledge is that the client is wiped/removed when done capturing or prepping it. Did you use the built in servicing option to install updates? Is it possible that you are using a SUP to install the client and it got caught in those updates during servicing?

It almost sounds like the sccm client is already a part of the image. In the ccmsetup.log you attached. Client (5.00.7958.1000) is installed and is the same or lower version. Initiating repair. Repairing version 5.00.7958.1000 of the client with product code {8864FB91-94EE-4F16-A144-0D82A232049D} My guess is the new image works because you captured it without the client installed. The log looks weird, it shows start date of 4/14 then a date of today 5/6

We have a pretty unique setup here where we have roughly 150 divisions who all need to do basic admin tasks such as create collections, packages, etc, and to be able to deploy them to collections which they manage. We don't want them to be able to edit packages and task sequences that are not theirs. I have figured out a method to do this, however it seems it isn't the best way. But looking at alternatives leaves me confused. For example I created two custom security roles and scopes, read and write basically. I have a package and have assigned the read security scope to that. When the user is just assigned the read, they can see the package as expected, and do nothing with it, as all that is granted via the read role is the read right. Now, when I grant the user the write role, they automatically get that access to the package, even thought he package does not have that role assigned to it. So I feel that I am confused as to why this is happening. My user has been granted both roles, and for Security Scopes I have it set to "Only the instances of objects...." I read this as, yes you can have the write role, but only when assigned. However I am obviously wrong about this, as users are granted write on existing objects regardless. Using the "Associate assigned security...." option fixes this, to a point. However doing it this way seems are to script via powershell.

What Peter said. You could also look at the windowsupdate.log on a client and see what the wsus server setting is is pointing to. Or look at the local group policy on the client.

There is a report telling you the status but it is not as detailed as in 2007. Look under Task Sequence - Deployment Status

Nice catch I forgot about that one. We once got a bunch of Lenovo's with bios dates back to 2010 and had the same issue. So many things to think about!

I don't know at this point without the log file, you will need to pull the smsts.log file to see what the problem is. If you can do that and post it here that would help.

Yes you will need to delete the machines or use a unique dongle for them.

What is your Server Version and SCCM Version? You need WSUS installed on your primary site as well as the server designated as your software Update Point. Is that what you are saying you did?

Can you successfully start the image when using boot media? Try if you haven't, if it works that is good and we can go from there. If it errors pull the X:\Windows\temp\smsts\smsts.log file to see any errors that may be occurring. Is your task sequence being deployed to unknown computers or to a collection that you import computers to?