h4x0r

As an update to this, the Apply Driver Package step appears to have fixed (at least part of) the issue. It is currently installing software, which is further than it had been making it previously.

When I've added drivers to CM, I create the driver package as well (old habbit from CM2007), though I never "use it" in that I have only ever used the Auto Apply Drivers step in the TS. So to this end, I have never messed with updating the DP's on the driver packages past their initial creation. So please tell me if I'm understanding your suggestion...are you suggesting that I update the DP on the driver package for the workstation, even though I had been using the Auto Apply Drivers step? I've got the workstation on my work bench now, and it is imaging using a TS with the Apply Driver Package step instead of the Auto Apply Drivers to see if that has any bearing on the situation. Naill, I'm also curious what methodology you use for applying device drivers...do you use the Auto Apply or Driver Package method (both cases filtered by WMI)?

I have a few Dell Lattitude E5550's that are new to our organization, and I dropped our image on one to see what devices I needed drivers for (turns out, A LOT). In either case, after downloading drivers from Intel and Dell, verified that they are correct for the hardware, and added them to CM like I always have...I re-imaged the workstation, but it still had a ton of devices without drivers. I thought this was odd...so I checked my WMI query, and it was good...I even set a single step in the TS to simply apply all drivers (unattended install of unsigned drivers was checked as well), but I still got the same result. So what to do at this point? Searching returns mostly articles regarding how to add drivers to CM, or driver "strategies", but not many address this issue. I found a similar post on these forums in which the NIC driver needed to be added to the boot.wim, but I already have that added. I just need ideas on what to troubleshoot, or what logs to look at...because, frankly, applying drivers in CM has always worked for me and I've never had to troubleshoot this I'm going to apply a driver package in the TS instead of the Apply Drivers step to see if that makes any difference...so here's hoping. Thanks!

Just wanted to post a follow up as a resolution to this issue. The reason they keyboard and mouse were not working was due to the Intel ICH9 (and ICH10 on some models) usb hub not working due to a driver issue. Even downloading the proper driver from the Intel site and importing those into SCCM would not install correctly. I ended up downloading devcon and creating a package with different programs for the different generations of USB hubs in the impacted workstations. Then in my task sequence I added the programs with WMI filtering to run for the specific models. The program command looks like this (the hardware ID obviously changed depending on the model): devcon.exe updateni "C:\Windows\inf\usbport.inf" "PCI\VEN_8086&DEV_2936" This updates the driver for the usb hub, and the keyboard and mouse correctly work after OSD.

Now I feel all herp-derpish...I had tried to build a collection of objects based on AD groups at one time, but there was an issue with the sql query I was trying to create...little did I know how simple it actuallly is (I guess it also helps to have better search strings!). Jacob, here are a couple links with further info... From our own forums Creating Collections based on AD group membership -- scroll down to the section titled "Device Collection based on an Active Directory Security Group" for easy step-by-step instructions, too. Note that you'll need AD system discovery turned on for this as well.

I think you're going to have trouble packing it alll into a single TS...I've used a two-part method due to no access to our WSUS server (so it makes automatic updates during TS a little tricky). The first TS builds the reference workstation, and I then install/update/whatever and then run part two...I could even schedule part 2 to run automatically at a given time, thus eliminating the need to run it manually from the Software Center

Good point, Peter...I was pretty sure you could do user collections based on groups, but what about device collections?

Actuallly, you might want to take a look at this...on your deployment type, if you go to the Requirements tab, click on Add..., under Category select Custom and then Create. Under the Setting Type, you can select Active Directory query...I'm not an expert in LDAP queries/filters, but you might be able to tweak that requirement condition to see if it will work with your AD groups.

If you are just trying to protect a TS, have you seen this thread here in the forums? http://www.windows-noob.com/forums/index.php?/topic/2336-password-protect-a-task-sequence/

Just a couple thoughts on this...but quick question first...what exactly are you trying to accomplish? I mean, there's no need to re-invent the wheel, if someone already has a fully functioning wheel My initial inclination is to suggest looking at the HTA and webservice frontend subforum to see what options already exist that might do what you are trying to do. If you want a UDI for a workstation refresh, then having that launch before your TS runs would be ideal. As far as the technicalities of what you might be trying to do...be careful about deploying an OSD TS (even when marked as Available instead of Required) to all your workstations...in general that's just a bad idea, IMO. There are a number of horror stories out there of OSD-gone-wrong because of situations like this, and giving an end-user the freedom to re-image their station whenever they feel like it might cause more problems then it solves.

I would double-check that you're adding the correct architecture of driver to the correct boot image...meaning, you'll have a tough time adding a 64 bit driver to the x86 boot image I'm trying to remember which log file it is that will show you the info you're looking for...my inclination is to look at distmgr.log (but that's going from memory, and might not be accurate)...aside from that, when you update the bootimage, it should give you a list of exactly which driver is failing to be imported at the Summary screen after you finish the updating DP process.

Thanks...I didn't know the frontend had been updated. I looked at the original post, but didn't see any links to an updated version. Maybe we could update the original post with a link to the new frontend?

What if I do not need the self-service portal? Count it as a side-effect of the "political" environment in our organization, but licensing SP is simply not going to happen...but that aside, the way our helpdesk works at the moment sort of excludes the need for a SSP. Can anyone tell me if the SSP is required to run SM?

SMSTS.log will show you where it is erroring out, but really, we would need more information in order to help. Since they are "new" I'm guessing you're doing bare-metal imaging...so you're doing that via PXE? If I had to guess, I would suggest your boot image needs the network driver imported in order to function in PXE...other wise, you'll PXE boot the workstation, PXE will launch, you'll get a couple status bars pop up once WinPE is loaded, but then the computer restarts due to a lack of network driver. Hence, it does not get formatted, it does not get the image, etc.

I think you're going to need an application for each icon, because the client will look for detection methods based on what you have in your deployment types, and if one of them is met, then it will consider the app deployed. It is really meant more for things like architecture detection (as a simple example) where you have 32 bit and 64 bit version of software you need to deploy. Obviously a 32 bit OS can't have 64 bit software running on it...so the two deployment types allow for the install of a single app. If it were me, I would create an application for each icon, with a scripted detection method...my first inclination is powershell, but that might be tough to get AD group membership without the RSAT AD Powershell module also installed on the client...so something like VBS might be a better option there.

Versions of??? I assume that Maik Koster's web service is still at v7.3...I'm unsure what the latest build for CM is in the technical preview...so as long as the web service is working, then I presume that any changes that need to be made to the front end piece will be fairly minor.

Has anyone tested this frontend with vNext much? I'm curious if there have been any issues with the web service.

This is a couple days old, but I wanted to comment as this was something that came up in discussion recently. The top couple items have already been addressed: 1) OSD and 2) Application deployment Outside of that I would have to say that the remote capabilities of SCCM are certainly NOT one of the reason we use the product here, much less why we would keep it around. We use GoverLAN as part of our "helpdesk" software, which compliments SCCM very well...definitely far better remote tools. But for additional list points, Garret804 pretty much summed it up...I would say that the list could be extended like this: 3) Asset intelligence 4) System compliance 5) Reporting (perhaps a subset of 3 and 4) 6) Power management Points 3 and 4 can be broken down into hardware and software subcategories.

You could also script the creation through powershell, and just run that script as a step in your TS. Unfortunately, I don't use PS for my VM creation, so I can't give you any specific pointers there...but google is your friend

Updated our image shortly after installing CU5, but now we have one model of workstation where the keyboard and mouse do not work after OSD. After some research, it appears the issue is related to improper driver install...going into Device Manager and updating the driver for keyboard and mouse will fix the issue. Since it only impacts one model of workstation, it is not major issue, but definitely adds an extra step for my helpdesk techs. The image is being created from a VM on Hyper-V running on Win8.1, and was created/updated in the same fashion as we have done previously. The only change since the last image update was the install of CU5, so I'm wondering if that has something to do with it. In either case, I was wondering if anyone else had run into this issue of keyboard and mouse failing due to bad drivers after OSD? I haven't yet installed SP1 for R2, as I was just going to wait for the release of vNext, but I may give that a try to see if there is any improvement there. Any help is appreciated...thanks!

"Installation of image 2 in package WH10012E failed to complete.. The system cannot find the file specified. (Error: 80070002; Source: Windows)" Have you tried re-distributing your image and watching distmgr.log to verify that it completed successfully? *edit Sorry, missed your last comment about multicasting...still, if it is succeeding with vanilla OS, then you might try re-creating your image package, and then update your TS.

Nope...we have a JP language pack that we use on demand in a couple locations, but nothing we include with the OSD. Thanks for pointing that out though

One thing I noticed was that my .NET installer was ~100MB...but after extracting it, it was right at 1GB. I wonder if there isn't some sort of caching issue going on, since the installer would need to decompress anyways (though I would have thought it would have done this in a temp folder or something)...in either case, I copied my existing .NET application, pointed the content location to where I had extracted the installer, and updated the program commands...and bingo, .NET is now installing as an Application from within the TS.

I will try adding a logging parameter to my deployment type and see if that sheds any light during the TS

Thanks for mentioning that...I actually already added that in an attempt earlier this morning.