Rocket Man

It is possible that it may be continuing to the next script before it has finished all of the other commands from the first script. TBH in any batch file I use for deployments %~dp0 is always inserted in front of any file that is needed to be executed from within the package. You could put a timer run command line in between the execution of the 1st script and second script, So if it is a case the 1st script requires more time to finish the uninstall of the trend program then the timer will kick in to allow this before kicking in the registry removals? Does that make sense? I will do up a quick step by step on how to achieve the above via a task sequence if you like later on at some stage today, with time permitting of course?

That is one big script! Have you thought of running these as part of a task sequence? In the first task you could copy the scripts locally via a run command line and point it to the package that contains these scripts. Then you could execute another command run line that will initiate the first batch file and then you could also use another run command line to execute the second batch file for cleaning the registry. It may be worth a try if you haven't tried this yet?

Along with Peter has mentioned if the quicktime folder is not created you will need to create it. The %AppData% variable does not work, well running it locally from testing that is, but this does work as I have tested it: cmd.exe /c md "%userProfile%\AppData\LocalLow\Apple Computer\Quicktime" xcopy "%~dp0quicktime.qtp" "%userProfile%\AppData\LocalLow\Apple Computer\Quicktime" /Y This will create a quick time folder providing that Apple Computer folder already exists, if not the you will have to create this also with: cmd.exe /c md "%userProfile%\AppData\LocalLow\Apple Computer" cmd.exe /c md "%userProfile%\AppData\LocalLow\Apple Computer\Quicktime" xcopy "%~dp0quicktime.qtp" "%userProfile%\AppData\LocalLow\Apple Computer\Quicktime" /Y How are you deploying this application, required or available to user? If software has any kind of a user profile based installation, I personally prefer to leave the app available in the APP catalog, this way the user has to be logged in and the user profile installs works just fine! Rocket Man

In your preferences.cmd file enter the syntax copy "%~dp0quicktime.qtp" "%userProfile%\AppData\LocalLow\Apple Computer\Quicktime" /y instead of xcopy "%~dp0quicktime.qtp" "%AppData%\LocalLow\Apple Computer\Quicktime" /Y Rocket Man

Does the iTunes initial installation install for all users that use the system (system installation)? If so and you are deploying the full script which is supposed to install iTunes and then copy the preferences files to the user profile then how will this work when someone else logs in as the package is already installed. You should probably have the copy preference files separate and use the application model to this with detection methods based on the files not been in the user profile so it will deploy them. Have you seen this maybe it will help. BTW you should probably use the application model for this program in full and leave it available in the APP Catalog for users to install as needed. This way the user has to be logged in so the user profile copy part should work just fine.

Did you try putting %~dp0 in front of your MST files also?

Have you tweaked the client settings to pole for policies quicker in particular the one below: Take note of the recommendation though as it could tax your network depending on the number of clients in your Hierarchy.

You tried disabling start up items (msconfig), reboot and try install again?

You try cleaning out the %temp% directory and also the windows\temp directory. If neither work... use good old CCleaner and do a registry clean and try again.

Have one of my larger installations sitting on a VM using DELL equalogic SAN storage. SQL is on same box (of course), 2 volumes, C for OS and other for SCCM,SQL data. 8CPUs' and 32 GB RAM. 5500 clients presently, 15 remote DPs and currently performance is running at approx. 17GB RAM. Primary never seems to get too much affected with OS deployments @ PS location, even when deploying 100+ machines at same time using PXE, but of course your network plays a part here also in this. And Primary site PXE DP is also on same box ( probably not recommended, but I have what I have) Advice SQL on same box. I think what Peter means by the minimum amount of requirements for SQL when having SQL on the same box as a Primary site installation of CM is what he quoted. 1GB RAM as Garth mentoned is the minimum requirements just for an installation of SQL, ramping up memory and CPUs depends what you want to run of an instance of SQL.

I think distribution point groups should play a part here. You create DPGs and assign your computer and user collections accordingly...as you have already said try not go over 4000 clients in each....so 4 DPs each in their own DPG should service 16000 clients in total. It's just a matter of getting the collections within your PS divided up equally and added to each DPG..

May not be the answer to your issue but would it be possible to create a new collection and simply add the test collection to it and deploy the updates out to it. If successful then just include your other collection(s) to this collection. 1 ADR and 1 collection effectively??

By this you mean that the systems still won't image correctly or that it won't distribute the boot files after the injection? If it is the first, then have you again checked that you are getting an IP with F8 command support.

This is strange, normally the drivers fail to inject then of course the updated wim file also fails. To get your original boot wim files back to working order, remove the injected intel driver(s) and update the DPs. What I would suggest trying is to create a new boot.wim image and just inject in the intel driver and use this in the deployed Task sequence for the systems.

You have separated the different architecture of drivers and injected them accordingly? i:e x86 drivers injected into the x86 boot.wim and x64 into the x64 boot.wim only.. You could try and remove the newly added drivers from the boot.wims and then re-distribute the boot.wims to the DPs. It must be a driver that is causing this error. Where did you get the drivers from?

And did the drivers inject successfully? Maybe try it again but this time don't select the option to update the DPs automatically.... you can do this manually afterwards if the injection is successful... I have my doubts that it was successful with the error you have above.

I take it you don't have an IP address either? ipconfig in command prompt.. If not then you will need to sus out the correct NIC drivers for these machines..... perhaps go to the manufacturer site for the drivers as opposed to using the DELL drivers..

Have you verified that you are getting an IP address at the preparing network connection stage? (this is achieved by having F8 command support enabled on boot.wims) If you are getting an IP verify that you can communicate with the FQDN of the site server. If you can ping the site server then it could be possible that the BIOS time is incorrect on this particular batch of systems. Check this out, as having the incorrect time and date in the BIOS can cause these symptoms.

And you have specified in the options of both boot wim files to deploy from PXE server? The PXE boot aborted usually means that the system has had a previous PXE deployment sent out to it, so in your case you say you never have been able to image any machine using PXE method, just double check that there is no PXE flag set on the system(s) that you are trying to OSD via PXE, if there is clear the flag and try again..

How about adding the FQDN of the boot server hostname and also using the x86 path for the boot file, so the path will be SMSBoot\x86\wdsnbp.com and the host name will be name of server.fqdn as opposed to the IP address of it.

Also there is a built in report in SCCM named all content in the Software Distribution- Content folder, handy if you want to export to spread sheet and print it off for referencing. Another report named All content on a specified DP, within this report you can view all packages distributed to a DP, if it was a successful distribution and also the package ID. Not sure on how long it takes this info to populate so it may not be real time..

Is this happening on all PXE deployments to every system you are trying to OSD via PXE? OR just this system? If it is just this system you could Push the task sequence out as required to this system (isolate the computer object and add it to a custom collection) with only media and PXE option selected on TS deployment and see what happens. Also, which architecture of boot file are you using in your TS?

Great that it is working, but for the purpose of this thread was it the removal of the DP that fixed your initial issue?

Are the packages in the shares at the remote DPs locations? Are your Boundary Groups & DP Groups configured properly so that any system with in that boundary gets software from the local DP? You could deploy your TS and do not tick the option to allow the use of a remote DP, this way if content is not available on the system(s) being OSD'd local DP the TS will complain that SITECODE***** package is not available on the DP. One way of finding out for sure whether or not content is available.

Quick one you state it has worked for 2 years and your site server is 2012 R2, this is not possible as R2 is not around this long. Did you upgrade to R2? If so you are running the R2 console and not the console pre-upgrade if it is a case that this site was upgraded?