Rocket Man

Yes just after googling the ndis.sys also and see that it is relating to the network card. The above was with my own experiences. I gather you have not packaged individual model specific driver packages for your devices. You are using a pool of drivers and then letting SCCM decide which one is compatible or best suited. If this is the case I would definitely think about creating a driver package for the problematic notebooks, this way it is much much easier to sort out the drivers if any are giving trouble. You could try and disable some drivers to see if this helps you isolate which driver is causing the problem, but this will be a slow process considering you have numerous NIC drivers.

Had a model of a notebook before and they were an absolute pain as they too kept Blue screening. Before we had SCCM implemented we used WDS. Fortunately for us there was a crash dump file created and after using the MS debug tools we found it out to be an outdated graphics driver. Check your graphics driver to see if there is any newer version for it and if there is try and create a driver specific package for that model and query it through WMI. Having had some other BSODs over a period on different types of devices, I automatically check the graphics driver, and 9/10 times this is the cause in my cases. Maybe this is your problem also.

That would be supercedence. You would have to specify in your java update 21 app that your newer java 27 update supercedes it. If it is required deployment and you have a detection method configured properly then the app will always install automatically if it does not detect itself on a system. Same go's for available deployment but this is not automated, the user has to retrieve it first from the app catalog....if it is already installed on the system it wont install again.

Cannot find the file specified. Would it be possible to create a package with the batch file in it and the exe, instead of pointing it to a share to copy locally. Then in deployment specify download locally before running. This way the files get downloaded to the ccmcache folder and can be executed from here which is local. The batch file could be simply: %~dp0csia.exe -i -L EDIT: the program command line would also be the name of the batch file for e:g installsecunia.bat

It depends on your needs. Personally I use packages along with OSD as this suits my enviornment as we refresh machines each year and 99% of time is successful. I do use applications but only for use with the app catalog. specified users can then browse the catalog for available applications if they want, I leave it upto the user. Had trouble getting some applications to install during OSD time, it just seemed to bypass them and the TS still showed as successful. This was on an SCCM2012 SP1 infrastructure. I have CU1 installed now and have not got back to try it again, to see if it has improved any.

May or may not be anything to do with your problem but webDav is not needed with SCCM2012.

I know with CU1 upgrade the SP1 client communicated fine until they were upgraded to CU1..but it is recommended to have both clients and site server on same version. Now having a newer client version than that of the site server....will communication work...that is debateable and may have more underlying issues. Would unpublishing the site server from within the console not remove these enteries from the system management container. This would probably be the best way to do it rather than manually deleting them. Obviously it has not done your system any harm but it would not be the route I would have went.

You should try this and have it doing it via OSD. I am currently doing this on any new build that I have during OSD time as opposed to deploying it out to a custom x86/x64 sp1 collection. The upgrade does update some components and one been the Task sequence Components. What models is been affected, Dell optiplex 390?

Did you try creating a new task sequence and re-referencing the same packages? Not sure if R2 is supported yet in production? Also as I have not applied R2 yet So I am unfamiliar with the client upgrade process. Do you need to deploy any client updates along-side the actual client it self? I do know with CU1 there is an update that can be deployed along with OSD by adding the location of the update to the properties of the client in the task sequence. Is this the same process with R2 or does the R2 update actually update the full client package without having to deploy the extra update package? As for your clients getting stuck in provisioning mode there are 2 reg keys that could be run directly after the client task which may help. I will source them if you want to try it or maybe you have already tried it.

But what if you want to use BITS instead of SMB.......the content needs to be on the content share otherwise you wont have the access all content from DP when running the task sequence option when configuring the Task Sequence (do you have this option without having the client package on the content share?). This method uses BITS otherwise you will have to download all content first which uses SMB(depending on network and number of units to build this could be very slow, but then you have multi-casting option also to overcome this) You should try re-creating the client from definition and make sure to reference the new client in the task sequence.

You dont go to the actual properties of the collection. You only select the collection and down the bottom of the workspace you will see 3 tabs, Summary, Deployments and Custom Client settings! See below. Just select deployments, Right-click on the deployment you want to remove and delete! The same go's for deleting it via the task sequence method!

And in conjuction to what Peter has mentioned you could also go to the collection in question and select the deployments tab and delete the deployment from here also!

Have you re-created a new client package from definition? If you do this then you will have the option to copy to content share. Maybe you have not re-created the new client from definition also? The client could be stuck in provisioning mode... (check regsitry), thus nothing else will work after i:e software updates, packages etc... Provisioningmode should be false and systemtaskexcludes should be blank also as seen in screenshot.

This is probably due to the fact your client has not polled immediately looking for new policies/advertisements. The default polling in the client settings is 60 mins. You could adjust this or you could force a machine policy request by doing it manually on the system or by using the Right-Click tools which can be used remotely and centrally.

Hi Fray Does lync require an install for every user that logs on? Is a lync installation on a system not for everyone to use that uses the system? In my environment Lync is installed at OSD time along with the other office 2013 applications as an Office package in full. There could be as many as 100 users that may use the same machine and the one install of Lync does everyone who visits that machine. I know that this is not the same for you as you need to get Lync deployed now after OSD time but I see that you have configured it to run once for every user that logs on.... would this be appropriate. Is this a package you have created or an application according to your screen shots above I think it's a package. Applications are far more user-centric than packages are and also have alot more functionality. To what are you deploying the package of Lync to, systems or users collections?

The agent is a required step with a B&C task sequence...once the sysprep takes place it will strip back the agent so there will be no trace of it on the captured wim. Without the agent attached to the B&C task sequence the process will fail because if it was not attached and the B&C task has software install tasks then without the agent this is not possible. The method you have used with stand-alone capture media is fine by creating an image on a VM, leaving it on a workgroup, manually customising the image and without the agent installed before capturing it via capture media. Nothing wrong with this method.

Are they showing in the console? Have they been approved via the console? More than likely not as it only auto approves any client in a trusted domain by default. We had approx 150 workgroup laptops we refreshed each year and had no problem getting them communicating to the site server, SCEP policies worked and so did the APP catalog! As it was a new process to me at the time I had a script that executed at OSD time to tick the box to use this conections DNS suffix in DNS registration. Now I am unsure if this was even needed as we had not approved the clients manually prior to this script. And also the only extra properties that was added to the client during OSD time was the SMSMP=xxxxx and DNSSUFFIX=xxxxxx.

You must have used it at SQL configuration time as the account for the SQL services. If any other services were configured using this account then they too will also have to be updated!! Good idea to use and setup a service account with a cannot change password policy configured for such services as SQL! I take it it's not the enterprise admin account that you are using, cuz that would defo be a bad idea..

Do you have the .net 3.5 features enabled?

Looking at some sites this must be normal behaviour on the ports tab. Is the app catalog site components not throwing up any errors? (view the messages) Could be a feature that needs to be installed or it installed unsuccessfully. Do you have the agent configured for the app catalog? (dont think this is the problem)

How have you configured your boundary? AD site name or IP subnet range? As for the applications, they do install correctly individually as deployments as opposed to OSD tasks?

If it is what i think you mean from the above quote.....You do not create a standard package and point it to the source files for the new agent. You right click on the packages node and create a package from defintion and select the configmgr upgrade all 5.0 and finish off the steps, distribute to content share and then change the agent within the task sequence to reflect the new package.

You will have to re-create a new agent from definition and then you have that option. EDIT: once done change the task sequence windows setup configmgr task to reference the new client package.

Sorry, did'nt have notifications on. Have you seen this maybe it's your problem. It maybe the .net update mentioned that is the problem.

This task does take quite a while as stated in the guide and it will also restart the device after completion! Maybe try the command without the /norestart switch as it does restart regardless....