In my environment, it was decided that we would reboot all PCs once a week. The merits of this are intensely debated on the internet, so this may not be the right route for your organization to take, but it definitely does serve some valid purposes in our opinion.
Like I said, there are many people who see this as unnecessary or detrimental, but others who think it’s a great idea. For the most part, we’re in the latter camp. In order to set this up, I first created a collection with a Maintenance Window from 10pm Tuesday night until 3am Wednesday morning. It is very important that you have a Maintenance Window configured before you set up these forced reboots, otherwise machines that are already powered off before the users left for the night will reboot themselves when powered back on the next day.
To set up the forced reboot advertisement:
It’s important to note that your clients will not reboot at exactly the time you set the advertisement for. For example, if you have it set to run at 10:30pm, but have a Countdown Notification Length of 5 minutes, your machines won’t reboot until 10:40pm (advertisement time + Countdown Notification Length + lead time built into the command line). Also important to note: users with administrative privileges can execute a shutdown /a to abort the shutdown, but only after the Countdown Notification has ended.
I’ve previously discussed how to deploy Java via SCCM 2007. The most common reason for this deployment to fail in our environment is “Internal Error 2753. regutils.dll”. It looks like this error is typically caused by having a browser or Java itself running when you try to update it. Here’s what we do to resolve it (with JavaRa and JavaMSIFix on network shares, this whole process takes less than a minute per client):
1. Open SCCM Client Center and connect to the PC in question
2. In the Inventory Actions section, select the AddRemove Programs tab and click Get Installed Software.
3. If Java is listed, remote onto their machine and go to java.com in IE. Click Do I have Java?. You should get a message that Java is installed, or maybe one saying your version of Java is out of date. This is good (unless your environment should have the latest version of Java). You’re done!
4. If Java is not listed, remote into their machine and close out of all web browsers. Run JavaRA as Admin. Select Remove Older Versions. Once that’s complete, you should get a text file logging the progress. Close out of that.
5. Run JavaMSIFix.exe (also as Admin). It’s pretty self-explanatory.
6. Go back to the SCCM Client Center, and rerun the appropriate Java advertisement.
7. Check to make sure Java is now correctly installed by pulling up Add/Remove Programs. If it’s listed there, you’re all set!
Here at the company I work for, we have a number of offices scattered around the world. Computers imaged at each office have to be placed in an OU specific to each office, have an office-specific Local Admin password set, and have the timezone set. Originally, we had a separate Task Sequence for each office, and we’d have to pick the right one. Unfortunately, this also meant that we had at least 5 of each Task Sequence, which made updating software packages pretty tedious, as we’d then have to update them in each TS.
I didn’t want to create an HTA to have the local IT guy manually select an office, and I was also averse to having the local IT guy enter specific values in the form of a Task Sequence Variable. Our offices each have well-defined subnets, so I knew there’d have to be a way to have the task sequence automatically apply these regional settings based on the IP address. Here’s how to do it (note: these instructions are for SCCM 2007; I’m not sure how they’d need to be modified for SCCM 2012 at this time):
You’re all set! If you have any trouble with any part of this, please leave a comment below!
We were experiencing an issue at one of our remote offices where our OSD task sequence would get stuck right before it began installing updates (Windows and Office Updates). This issue seemed to only affect machines that were already in SCCM’s database; unknown machines were unaffected. The issue was most prevalent in one specific remote office (affected approximately 60-70% of machines being reimaged), but was documented only sporadically at other offices. For what it’s worth, our environment is SCCM 2007 R2 running on Windows Server 2008 Enterprise.
My first inclination was that there were just too many updates involved. I built a new Windows image that already included all of the Windows 7 updates that we’ve deployed to-date (a good practice we’ve decided we should do every few months anyway, just to cut down on OSD time). Unfortunately, this still did not work.
A bit of Googling yielded promising results: a hotfix available from Microsoft- “Task sequence that installs many updates stops responding on a System Center Configuration Manager 2007 SP2 client.” Perfect! I downloaded the hotfix, and proceeded to install it on the Site Server. Once that’s done, it also creates a new package called “KB2509007 – Advanced Client Hotfix – [Site Code]”. I had our remote techs try kicking off some OSD at this point, but apparently, I’d jumped the gun.
At this point, what needs to be done is to update your “Microsoft Configuration Manager Client Upgrade 4.0 ALL” package on all your Distribution Points. Also take note of this package’s Package ID, as you’ll need to add the following to the Installation Properties of your “Setup Windows and Configuration Manager” step in each of your Task Sequences:
PATCH=”C:\_SMSTaskSequence\OSD\[Package ID for Client Upgrade 4.0] \i386\hotfix\KB2509007\sccm2007ac-sp2-kb2509007-x86-enu.msp”
Once this is added to your OSD TSs, and the package is updated on your DPs, your Task Sequences should stop hanging during the Installing Updates step!
One would think that since Microsoft created SCCM, it would be really easy to distribute their software using it.
One would be wrong to think that.
Recent updates to Microsoft AdCenter are forcing users to update to the newest version, which is not possible for users in our environment who are not Admins due to the way our GP is configured. I spoke with a number of people at Microsoft, finally getting in touch with a Senior Development Lead for AdCenter who was actually super-helpful. Apparently, the installer used to be available as an MSI, but was changed to only allow per-user installs (so that non-admin users could update the software themselves) after requests from companies that apparently have very different setups than mine. Until the installers can be changed to allow the inclusion of an OPTION of a per-system install, here is my solution:
Let me know if you have any questions!!
When creating packages in SCCM, I strongly prefer to use MSIs over EXEs. They’re just way simpler. A few clicks and you’ve got all the command lines there for you automatically, instead of having to test and re-test or guess at the command line switches for an EXE. One thing that boggles my mind is Microsoft’s inability to release MSIs for their own products. Silverlight and AdCenter both saw updates recently, and both were released as EXEs.
Here are some quick steps to take the Silverlight EXE and get a usable MSI from it:
Once installed, future patches can be managed via Software Updates in SCCM.
SCCM has this really annoying habit of not keeping TS logs accessible after completing an OSD task sequence. Unfortunately, this also applies when the TS fails. To combat this problem, I implemented the following solution from Steve Rachui, which moves the TS logs to a network share for proper archiving and ease of access.
To do this, I added a new group to my main task sequence called Log Upload. I selected the “Log Upload” group and went to the Options tab, and added a Task Sequence Variable condition wherein we check whether _SMSTSLastActionSucceeded equals false. If so, it executes the group. I added four steps to this group:
It’s important to set this whole group to “Continue on Error,” otherwise it will fail if any of the individual steps fail, and report your entire TS execution as a failure. In my first test run, I hadn’t set this option, and the TS failed when it wasn’t able to delete the not-yet-existing folder on the share in step 2. Note that you’ll also want the preceding steps to continue on error as well, otherwise the TS won’t even get to this part on failure.
Next time, I’ll talk about using a script to send an alert email when a task sequence fails!
SCCM installs software using the local system account. This sometimes presents issues when testing before packaging in SCCM, as there is no straight-forward way to run things as this account. Packaging the software, testing by deploying to a test machine, and waiting for the results can be time-consuming, so here’s an alternative method for testing your command-line as the local system account:
1. You should have PsExec on the test machine (for example, my test machine has it located in C:\Program Files (x86)\PsExec.exe). Open an admin command prompt and navigate to the location of your PsExec.
2. Enter psexec -si cmd.exe to open a command prompt as the local system account. To confirm that you’re running this command prompt as the system, you can use the command whoami. It should return nt authority\system.
3. You can now use your command line installation to run under the same conditions as SCCM!
For even more betterness, you can create a desktop shortcut with the following target (be sure to sub in a valid admin username):
C:\Windows\System32\runas.exe /user:[domain]\[admin account] “c:\program files (x86)\psexec -si cmd.exe”
This will prompt for the admin account’s password, and then launch the system command prompt.
-Derived from Richard Balsley’s post, found here
Here’s how I’ve been able to deploy Java via SCCM 2007 (this method works for both Java 6 and Java 7):
1. Download the version of Java JRE you want to deploy HERE (specifically, the Offline installer; we use x86 even though we have x64 machines).
2. Run the Java EXE.
3. Find the temp folder it unpacked to (probably C:\Users\%USERNAME%\AppData\LocalLow\Sun\Java for whatever user context you ran it under).
4. Take the MSI in that folder, along with Data1.cab. Put BOTH those in your source folder (it will fail if you don’t copy Data1.cab as well).
5. Create Package from Definition using that MSI.
6. Deploy! It is very important that when you deploy this to your clients, all browsers are closed and Java is not running, otherwise your deployment may fail. My environment forces all client machines to reboot half an hour into our weekly Maintenance Window, so we always push these updates after that reboot to ensure Java and browsers are not running.
If you have a more efficient method, or any questions, leave a comment!
Suddenly, I have real things to talk about. I stumbled onto the task of managing SCCM for my company, and have learned a LOT. However, as is often the case in Tech, learning is an ongoing process, and “a lot” is a relative term.
As such, I will be posting tips, tricks, and things I learn here for archiving and linking purposes.