wilbywilson

You may want to try this command: /passive /norestart /quiet as documented here: http://www.itninja.com/software/foxit/reader-3/6-3442 As for the "failed" installation status, it's likely something with the Detection Method that you're using. Go through this document, to understand what's likely happening and how to fix that: http://myitforum.com/myitforumwp/2013/03/13/sccm-2012-application-deployment-detection-methods/

I've never done this personally, but here is a thread that talks about possible solutions for this: http://serverfault.com/questions/483730/deploying-windows-via-sccm-2012-osd-wireless

Woody, It's been a couple years since I set up IBCM, but I posted a thread with some links and comments to help others: https://www.windows-noob.com/forums/topic/10630-ibcm-deployment-results/?hl=ibcm Hopefully this helps you out. I don't have direct access to the SCCM infrastructure that I helped to configure anymore, so I can't answer your questions specifically.

While I've used SCCM and SCUP (with Shavlik integration), I've never tried to deploy driver updates in a business environment. There's just a lot that can go wrong, and the users can end up with unusable machines. A few years ago, the security team brought it to our attention that a certain Radeon/NVidia driver (I don't remember which model/manufacturer, but we had a couple thousand in our environment) had a security issue. They wanted the SCCM team to mass-update the driver. We tried on a small test group, with very mixed results. In the end, it was decided that the chances of this exploit taking place were slim, and we didn't try to push out video card drivers through SCCM. If the security exploit in question is really serious, then I would suggest an SCCM package versus SCUP. The only positive experience I've had with SCUP is integrating it with Shavlik (paid service). Through that, we've deployed Adobe, Apple, and Java patches relatively successfully. I've had poor experiences with the DELL and Adobe-manufactured catalogs. (I think it tells you something when a third-party company is coding/testing the updates for these manufacturers. These big companies don't have a good track record for their own SCUP catalogs.)

I would suggest breaking them into different update groups, but not necessarily 1 per operating system. The way I like do it, is to put all of the "workstation" (Win7, Win8, Office, etc.) patches into 1 group, all of the "server" (Windows 2008, Windows 2012) patches into another group, and perhaps special/custom apps (IIS, SQL, Exchange, etc.) into yet another group. Once those are built and deployed to some test machines, then I set up a deployment for each group. The deadlines for workstations is obviously different than servers, so that's why I like to build my update groups like that. So you may be different, but I like to build my update groups based on the "type" of machine they were targeting, and then set my deadlines accordingly. And yes, I do recommend consolidating these update groups at least once a year; otherwise there are just too many deployments running, and it's hard to make sense of what's what.

You're right. There's more than 1 way to skin a cat. I think the optimal solution is dependent on the size of your environment, and how involved your (change) management team is. I used to a work in a large environment, and we were not allowed to use ADRs to deploy Windows patches (we had ADRs for Endpoint definitions, but not for full-on Windows patches.) You might think putting together a package each month is extra work, but having the control over exactly which patches you select is worth it. Microsoft will inevitably stick in some patches you probably don't need/want, if you're not careful. We would target the patches to a test collection, for at least 5 business days. We'd actually run some reports on that test collection, showing that X percentage of that collection received the patches, and review the HelpDesk tickets to make sure there were no common/widespread problems. If all was well, we'd then create a *new* deployment, targeting the remaining machines. (Actually, 1 deployment for servers and another for workstations, with the difference being the enforcement deadline.) But splitting them into separate deployments is key, because if management every comes back to you when there is an unexpected problem, you'll be able to show them your test deployment statistics, with the associated SCCM reports you already have in hand. If you just re-use the existing deployment and re-target it, your numbers/reports will be skewed. So I always created new advertisements when moving to production. Best to cover your bases, before an ADR distributes something while you're on vacation, and blows something up

Yep, that's all you need to do. It's quite straight forward (compared to the rest of the OSD task sequence): https://www.vmadmin.co.uk/microsoft/64-mssystemcenter/353-sccmwmicwmiquerydrivers

Bump. Any input folks?

Anyweb, I hear what you're saying, and I totally agree in principle. My first suggestion to the management staff was for 1 single drive. I don't know if it's because of previous standards already established, or something that's being passed down from "corporate." If I can give them a number of compelling reasons on why they SHOULDN"T have 2 partitions in the main OSD image, I may be able to convince them to change their minds. So, I guess I have 2 questions now: 1) What specific complexities/problems does having 2 partitions (as opposed to 1) in the OSD image have? 2) If I can't convince management to go with 1 single C partition, what's the best method (ideally automated through the task sequence) to assign the Windows pagefile to the D partition? Thanks!

We've got a working OSD Task Sequence (integrating MDT 2013), which has a C (OSDisk) partition, as well as a D partition, per the company's requirements. Right now, OSD is putting the Windows pagefile on the D partition. But we would like for the pagefile to automatically be placed on the C drive. How can one accomplish that? Is there a step in the task sequence that needs to be customized/added? Thanks!

In your task sequence, are you letting the machine search through all of your driver packages? Are are you adding a explicit query for each machine model, to specifically only search inside that model's driver package?

SCCMrookie, I think 30 minutes for a light build is pretty accurate. Mine takes closer to 60 minutes, but we have apps like Office 2013, Adobe Acrobat, etc. One of the benefits of SCCM is that you can integrate it with MDT 2013, and make a user-driven menu, so that you can select which apps you want to install during each build. There are pros and cons for each software. SCCM may be a little slower than Acronis, but the customization options make up for it (in my opinion.) As for the "real world" question, I think it's dependent on the environment, and your switch speed and hardware. If I were the IT guy, on my first "mass push", I would do that during the evening, or on a weekend. As with all things in SCCM, test it out and see what the limits are, and then you can determine if it's something you can run during working hours, without negatively affecting the environment. From what I've seen, SCCM imaging hasn't stressed my environment, though I'm not using multicasting at this point.

P@docIT, Be very careful with the supersedence settings. There are definitely some "gotchas", where the app will deploy to machines that aren't even within targeted collection. See here: http://www.windows-noob.com/forums/index.php?/topic/10199-problem-with-supsersedence/?hl=%2Bapplication+%2Bsupersedence http://www.windows-noob.com/forums/index.php?/topic/10912-potential-issue-with-superseding-applications-be-careful/?hl=%2Bapplication+%2Bsupersedence

It sounds like your OSD advertisement is for "Unknown Computers." So, if you try to deploy Windows 7 to a machine that's already in he SCCM database, it will fail. This is by design, and it my opinion, it's a good failsafe. This way, you won't accidentally wipe out a system by mistake. You need to manually delete a previously existing machine from SCCM, before deploying the operating system.

What differentiates the student's machines from the employee machines? Do the names of the employee machines contain something unique? Is there a piece of software on the employee machines that does *not* exist on the student machines? I think you're going to need to find a unique difference, and query for that.