Garrett804

.exe, .bat, reg files etc.. would be a package in SCCM and not an application. .MSI would be an application. All you need to do to deploy a script is create a package and point it to your .exe or .bat file etc.. If you are using UNC path's in your file to point to your install files make sure that the share allows for everyone to have access as the SCCM account that will be used is the system account for that specific machine you deploy it to. If you want your existing application to run first simply add it to the top of your script and set your "installation Program" under the deployment type to point to your script file rather than the usual "msiexec /i setupblahblah.msi /q" See my example below for my office install based off a script. What I'm doing in my script is first uninstalling Microsoft Office Communicator, then I copy a Uninstall.xml file into the MSOCache folder for office 2010 and kick off the uninstall command for office 2010. Finally it installs office 2013 onto the machine and restarts the machine. Script file below: I have both the 32-bit and 64-bit folders listed below but you just remove one of them depending on the version of office the person has. @ECHO OFF ECHO Uninstalling Office Communicator ECHO Please Wait while Office Communicator is removed... msiexec /x {0D1CBBB9-F4A8-45B6-95E7-202BA61D7AF4} /q ECHO Uninstall Complete. ECHO Please close out of all Office applications (Including Outlook, Word, and Excel). ECHO Uninstalling Microsoft Office 2010 ... xcopy Uninstall.xml "c:\MSOCache\All Users\{90140000-0011-0000-0000-0000000FF1CE}-C\*" xcopy Uninstall.xml "c:\MSOCache\All Users\{90140000-0011-0000-1000-0000000FF1CE}-C\*" cd "C:\MSOCache\All Users\{90140000-0011-0000-0000-0000000FF1CE}-C" setup.exe /uninstall ProPlus /config ".\Uninstall.xml" cd "C:\MSOCache\All Users\{90140000-0011-0000-1000-0000000FF1CE}-C" setup.exe /uninstall ProPlus /config ".\Uninstall.xml" ECHO Uninstall Complete cd /d %~dp0 setup.exe ECHO The Office Installation has been completed, The system will restart in 15 seconds shutdown /r /t 15

So your deployments of the applications are being deployed to the collection that all these machines reside in?

It looks like you're not able to connect back to the MP. Check out the following link as it should help resolve your issue. http://www.windows-noob.com/forums/index.php?/topic/7281-management-point-pxe-boot-error-80004005-after-sp1-upgrade/

Can you post your SMSPXE.log file. It will be located on the drive you used to install your files for the role under \SMS_CCM\Logs\SMSPXE.log verify PXE installed correctly and you have no errors in there.

If you are sending these through exchange check your exchange receive connectors.

The ADK version you need is 8.1 http://www.microsoft.com/en-us/download/details.aspx?id=39982

Did you follow the tutorials on here for setting up OSD?

I have my helpdesk group setup in security which allows my techs to add/remove from collections that are associated with the "All Users" or "All Computers" Collections only. If there is a collection I don't want them seeing or manipulating I make its limiting collection "All Systems" and it never shows up for my helpdesk tech's. Only things that I have a limiting collection of "All Computers" or "All Users" shows up for them.

Here's an easy way to remember how to do applications vs packages. Scripts, .exe files, reg keys = These would be package deployments .MSI = This would be an application deployment. In the case of me pushing a script it is an application deployment of the .bat file which resides in the same folder as my office install on the source location for the package. SCCM downloads the package and then kicks off the batch file. The batch file as you see above does tasks in a specific order that I have written it out to do. I can expand more on it with some pictures when I'm on a different unfiltered network that lets me upload pics if this still doesn't make sense to you.

you should be updating your OSD image quarterly with all the latest updates installed so that you don't have a ton to install as the year goes on and more updates are released. This will cut down the time it takes to image and the amount of updates that are required to install during or after the imaging process.

I've had this same issue when we went to office 2013. I have a process that does uninstalls then installs office 2013 after and restarts the machine when it finishes. What I use is a batch file that first calls the uninstall for office 2010 suite which fully uninstalls everything from the suite. The reason you have the suite still present is because all the the upgrade does is uninstall the specific applications that 2013 has. 2013 doesn't have the sharepoint tools or the other tools that office 2010 has so it doesn't uninstall the extra "tools" that aren't present in the 2013 suite. We also have Communicator which is also not part of the office suite and has to be uninstalled seperate since we are going to Lync with 2013. Now the SCCM "official way" to do an uninstall is to create an uninstall package using the application .msi file. What this does though is cause your clients to have to download a large amount of data to kick off the uninstall if they originally had the software pre-sccm deployments. Microsoft stores some cached files for office repairs, uninstalls etc.. on the local C:\ under a hidden folder named MSOcache. What I do with my script is I have an uninstall settings file "uninstall.xml" that I copy into the c:\Msocache folder that contains the setup.exe file for the office 2010 installation. Then it calls up the uninstall command for 2010 pointing to the XML file that I've copied into the folder for the settings to uninstall the application. This keeps the downloaded data required to like 1kb and uses the already existing stored files to accomplish the task. Sorry it that all seems a bit confusing but I just felt no need to move large amounts of data around to just uninstall something simple. I do a lot of batch files for uninstall commands to avoid having to move data around. The product keys for office 2010 32-bit and 64-bit are listed in the script so depending on the version you have in your environment you'll want to remove the lines for the version you don't have. Here is my script. @ECHO OFF ECHO Uninstalling Office Communicator ECHO Please Wait while Office Communicator is removed... msiexec /x {0D1CBBB9-F4A8-45B6-95E7-202BA61D7AF4} /q ECHO Uninstall Complete. ECHO Please close out of all Office applications (Including Outlook, Word, and Excel). ECHO Uninstalling Microsoft Office 2010 ... xcopy Uninstall.xml "c:\MSOCache\All Users\{90140000-0011-0000-0000-0000000FF1CE}-C\*" xcopy Uninstall.xml "c:\MSOCache\All Users\{90140000-0011-0000-1000-0000000FF1CE}-C\*" cd "C:\MSOCache\All Users\{90140000-0011-0000-0000-0000000FF1CE}-C" setup.exe /uninstall ProPlus /config ".\Uninstall.xml" cd "C:\MSOCache\All Users\{90140000-0011-0000-1000-0000000FF1CE}-C" setup.exe /uninstall ProPlus /config ".\Uninstall.xml" ECHO Uninstall Complete cd /d %~dp0 setup.exe ECHO The Office Installation has been completed, The system will restart in 15 seconds shutdown /r /t 15 Here is the Uninstall.xml file data as well: <Configuration Product="ProPlus"> <Display Level="Basic" CompletionNotice="NO" SuppressModal="yes" AcceptEula="yes" /> <Setting Id="Reboot" Value="Never" /> <Setting Id="SETUP_REBOOT" Value="NEVER" /> <OptionState Id="ProductFiles" State="Local" Children="force" /> </Configuration>

To control Bandwidth you need to implement Maintanence windows for after business hours to do the applying of updates. These windows will also help control unwanted restarts from happening in your business hours. To remove the updates from deploying simply search for them and remove them from the update group by right clicking them and selecting to "Edit Membership" and uncheck the membership to the deployed group. When deploying the updates be sure to not select the option to install outside and restart outside of the maintenance window unless you are wanting one of those 2 to occur.

Why not just call the uninstall in the bat file and then have the next step be the command for the install. For instance: msiexec /x {product ID} /q msiexec /i Newsoftwareversion.msi /q

Garth is correct on this. That is a big custom report which would require multiple table lookups at first manually to even find the data and then to compile it all together in the end. Most of the first report for OS, RAM, etc.. though you can get off the "Summary of computers in a collection" report under Asset Intelligence. This is a simple report I made for my boss just since he wanted just the Machine name, Login ID, Full Name, Last Logon Time, Make, Model, Serial of our machines. You can always expand on this though as you find the tables you need to pull the other information you are wanting. Select SD.Name0 Machine_Name, --SD.Resource_Domain_OR_Workgr0 as Resource_Domain, SD.User_Name0 as Login_ID, --SD.User_Domain0 as Account_Domain, USR.Full_User_Name0 as Full_Name, PCB.SerialNumber0 as Serial_Number, CS.Manufacturer0 as Manufacturer, CS.Model0 as Model, --SAS.SMS_Assigned_Sites0 as Assigned_Site_Code sd.last_logon_timestamp0 as Last_Logon_Time, COL.name From v_R_System as SD Join v_FullCollectionMembership as FCM on SD.ResourceID = FCM.ResourceID Join v_Collection as COL on FCM.CollectionID = COL.CollectionID Join v_R_User as USR on SD.User_Name0 = USR.User_Name0 Join v_GS_PC_BIOS as PCB on SD.ResourceID = PCB.ResourceID Join v_GS_COMPUTER_SYSTEM as CS on SD.ResourceID = CS.ResourceID --Join v_RA_System_SMSAssignedSites as SAS on SD.ResourceID = SAS.ResourceID Where COL.name = @Collections Order by SD.Name0

The reason they can change the power plan on there own is because you aren't locking it down via GPO. When SCCM pulls a policy it also pulls your power plan settings. Depending on your policy refresh this is a 15+ minute window repetative policy refresh. To keep them from being able to change the setting you need to lock it down via a GPO.

another person solved this issue by the following: Remove distribution point role; Remove WDS role; remove all folders of distribution folders and WDS. (SMSPKGE$, SMSSIG$, SCCMContentLib, RemoteInstall); Reboot Server; reinstall all roles; Redistribute packages. http://www.windows-noob.com/forums/index.php?/topic/4856-boot-images-failing-to-update/

Your AD Schema extension is failing. - Do you have rights on your account to admin the Schema even? - Have you created the System Management folder and given rights to the SCCM server? check out and follow the guides on this website for SCCM Pre-req's before you install SCCM.

This forum is for SCCM not SCOM so you might need to look elsewhere for SCOM questions.

Yup, add it in the console not in SQL itself.

Your site server probably doesn't have the rights in SQL to write to the DB. http://blogs.technet.com/b/configurationmgr/archive/2012/07/25/support-tip-configmgr-2012-setup-fails-at-prerequisites-check-with-error-failed-to-connect-to-registry-on-machine-sql-fqdn.aspx

I'd agree with GarthMJ. Your data doesn't give us anything to go on really and depending on the overall network layout what we may suggest could not even be workable for yoru business environment. Document the network as he said to start with and depending on the layout of that either come back to us with more details on your network speeds etc.. and maybe we can help with a design in terms of network traffic. Hardware though isn't really that complex and will be based off of what the network layout is. For example if you have 1Gb connections throughout your environment then you don't have to control traffic that much depending on your current saturation on those connections. Without having to consider traffic you wouldn't need secondary sites etc.. to mitigate the cross-network policies. If you have DSL 1.5Mb or below and a 10+ clients behind that then obviously pushing OSD or larger packages and even policy and WSUS updates can totally cripple that network.

See if you have a Silent install option which should take away the prompting and allow the default install options to install the application.

The way to tell your entire environment compliance would be to go to Software Library > Software Updates > Software Update Groups. The compliance numbers there are for the entire environment regardless of deployment. To see the compliance isolated to a deployment then you'd have to run a report based on a given collection of machines as you are probably already doing.

you can put the SQL on a cluster or the same box, The only issue you'll run into is performance if you are sharing hardware with another high I/O system.

I'd probably do this with a simple batch file package that has the install commands in order of the lowest to highest versions.