Jaybone

Are you sure they're really on the wrong version? We had an issue with non-R2 SP1, CU...something - 5 maybe, where the console would show an older version for a client, even though the client had indeed updated. That seemed to get fixed after we upgraded to R2 SP1.

https://www.windows-noob.com/forums/topic/12936-java-via-scupwsus/ Still using the commandline from that post, just modified to use u65 instead of u60, and the script in it to remove any and all earlier versions that're installed.

I should've said before - if I delete an existing computer and reimage with the TS that includes the auto-join, all is well. And that bit of logfile is from an attempted reinstall of the client on one of the affected systems, not the initial install that happens during the TS and before the domain join. Nothing jumped out at me from the logs right after the reimage, but I'll reimage an affected one again and copy off the logs before messing with anything and post em when I can.

Hi, all. Hoping someone can point out what I'm missing, here. Task sequences to reimage a system are working fine. What we've never done is automatically join the domain - always just did that manually. I copied a TS, added one extra step to the end to join the domain. Testing that TS, what I've found is that systems which already exist in the domain/config manager appear to be completely unable to ever get a working client install. Systems unknown to Config Manager have no problem. The TS with all the exact same steps except the auto-domain-join, client is fine after manually joining the system to the domain. Tried adding a reboot step at the end of the TS after the auto-join. Didn't help. Uninstalling with ccmsetup /uninstall and pushing a new client doesn't help; client push works and installs, but it never hooks up. Forceful uninstall by manually deleting services and ccm/ccmsetup/ccmcache; same as regular uninstall. GUID of the client never shows up in Config Manager - the computer object still has the old GUID from before the reimage, and searching for the new GUID comes up empty. Tail end of the ccmsetup.log has a couple odd entries: Anyone know what I'm missing, here?

I'd guess that there are conditions attached to those steps - take a look at what's on the Options tabs for each of those, and what conditions are in there.

After performing offline servicing for the first time since August (so Sept, Oct, and Nov patches) on the images that this was happening with, it's no longer an issue.

Been seeing the same thing on at least one of our un-updated Win7 images for the last few weeks. One of the September updates seems to be the culprit. A freshly built image has no problems, nor does an image updated via offline servicing.

This has come up before, linking to the old thread. It's referring to a build and capture, but we've used this same thing enable Office updates during OSD - a Package conatining the VBS that runs as a step before the Install Updates step(s). http://www.windows-noob.com/forums/topic/12072-office-updates-during-build-and-capture/

Didn't even think of that, but that seems like a much cleaner way to do it than forcing a deliberate failure. Would need to be updated every time new packages are added, but for how often that happens... might be worth it.

Check for existence first, maybe, so it won't try to overwrite it if it's already there? if not exist c:\windows\sysnative\cmd.exe md c:\windows\sysnative & copy c:\windows\system32\cmd.exe c:\windows\sysnative\

I was thinking that since we have a good number of random systems (5 of X, a dozen of Y, 8 of Z, etc) out in the wild that we don't have driver packages for, but that mostly have well-known hardware at least for the NICs (plain ol' Intel or Broadcom stuff), it might be useful to have an Auto Apply Drivers step in a task sequence, and set it to only run if none of the Apply Driver Package steps were triggered. What I'm not seeing, though, is any real built-in way to easily test this. The best thing I can think of is to set up a step that deliberately fails before all of the Apply Driver Package steps. My reasoning being: The deliberately failing step should set _SMSTSLastActionSucceeded to false If none of the driver packages are applied, _SMSTSLastActionSucceeded stays false If a driver package does get applied, _SMSTSLastActionSucceeded gets set to true (hopefully, heh) Auto Apply step checks the value of _SMSTSLastActionSucceeded, and only runs if false Seems kind of kludgy to me, though. Is there a better way to do this?

"OS drive" = where Windows is installed.

Is there a _SMSTaskSequence folder on the root of the OS drive? I ask because we saw an issue where the client would look like it was installed properly, but not actually work, and instead of having either all of the tabs and 11 actions (normal client) or some of the tabs and only 2 actions (normal client that's not actually approved yet), it would have 5 or 6 actions. The _SMSTaskSequence folder was present, indicating that something had gown wrong during OSD, since this is normally removed automatically. Doing an a full client uninstall/reinstall was the only way to get the clients in this state to work. Root cause for us was an unexpected reboot during deployment (specifically, one initiated by one of the Applications that was being installed).

It was indeed set to all languages. Fixed that. What I don't understand, though, is why the Config Manager stuff would be grabbing multiple languages, if only set to use one. WSUSContent folder is on one disk with plenty of room. The Office 2013 folder that Config Manager is using is on a different disk. Does CM just pull everything over that's found in the WSUSContent folder, regardless of what CM is set to sync?

That's what I don't get, though - why do I have multiple GB of language files for languages I neither need, want, nor have selected for download?

One way: Reporting --> All application Deployments (advanced) Fill in your parameters, hit View Report, and drill down by clicking the status you're interested in either on the pie chart or the specific status, or for an overview click "View Current Data". Drill down from there.

If you've got lots of different models of computers, auto-apply can break stuff for some of them. It'll sometimes pick the wrong "best" driver for a component. I'd say that if if works for you, then hey, great. We ran with it for a long time. Then we got in some Lenovo T440s that required a newer version of a driver used by our existing Dell Optiplex 7010s. When auto-apply picked that "better" driver for the 7010s... BSOD.

Hi, all. I noticed today that the disk space on our Config Manager server was getting a bit more filled up than I'd like. Dumping the .wim.bak files left over from offline servicing helped, but when I fired up Treesize, it pointed out that our Office 2013 updates are taking up a TON of space. Right now, that number is right around 63GB. This for an app that's only three years old, while a 6 year old OS's (Win7) updates are only taking up around 11GB. September's Office 2013 updates alone comprise 231 folders and files worth of stuff, out of 7416 total folders and files. We've only got 139 updates currently deployed that aren't expired or superseded, and they span years worth of stuff, so I'm not sure where all the extra stuff's coming from. I'd imagine most/every update would have two files - 32 and 64 bit - but not tens of files. A lot, maybe a majority of the files appear to be language packs (e.g. proof-zh-tw.cab) that we have zero use for, even though we're only set to download English packages. Anyone know if this is normal for Office 2013? Seems a bit excessive, but I've got nothing to compare against.

...six months later... After upgrading to R2 SP1 CU1 some weeks back, this problem seems to have disappeared. We've got only a handful of systems that are showing old builds in the console, and they're all ones that are either powered off or off-network for extended periods, so it's expected.

Are you sure you're getting your boot image, and not someone else's? Boot server'll show on the screen while PXE is starting up, and the path to the image will show after the screen blanks and starts showing the text progress bar.

It's been a while since I've done this, but I want to say it's doable, though not with the build and capture stuff. Used to do this with XP boxes before we finally ditched them. I think what you can do is essentially: 1. Build a reference system. Manually, via answer files, whatever. Recommend to do it in a VM. 2. Customize/patch up/etc. 2.5 make a snapshot/checkpoint in case anything goes haywire when you... 3. Run pre-imaging procedures for any 3rd party software that needs it, and run Sysprep to get Windows ready 4. Boot it into your WinPE environment 5. Hit F8 to get to a command prompt 6. cd \windows\pkgmgr (errr, whatever path, something like that) 7. Use ImageX to grab a copy. E.g. Imagex /capture d: \\someserver\someshare\Win2003.wim "Server 2003" 8. Import that .wim into Config Manager and create a TS for deployment. Keep in mind that drivers can't be added with the Add Driver step like they can for Vista+ If I'm forgetting/wrong on something, someone please correct me.

Dumb question - did you redistribute the boot images after taking the password off?

Updates, maybe? Depending on how things are set up, you may be in a situation where the client's installed at a lower patch level, detecting that, then running updates on itself.

jre1.8.0_60.msi SHA256 = 8371F27009A9286CAC0D9812E0411DDBFCB106456E46FFEC50E64054E75E4632 I think I grabbed it from %temp% while running the .exe. msiexec /i "%~dp0jre1.8.0_60.msi" JU=0 JAVAUPDATE=0 AUTOUPDATECHECK=0 RebootYesNo=No WEB_JAVA=1 /q call "%~dp0removeOld8.cmd" and the removeOld8 script (modified July 2016 - they changed the MSI code when they rolled to update 101 and needed to accomodate for that) is: REM -------------- REM Java 8 if exist "%temp%\remove32java8.txt" del "%temp%\remove32java8.txt" if exist "%temp%\remove64java8.txt" del "%temp%\remove64java8.txt" REM Find installs of Java 8, 32-bit and dump MSI codes to file for /f "tokens=7 delims=\" %%i in ('reg query hklm\software\microsoft\windows\currentversion\uninstall ^| find /i "26A24AE4-039D-4CA4-87B4-2F83218"') do echo %%i >>"%temp%\remove32java8.txt" for /f "tokens=8 delims=\" %%i in ('reg query hklm\software\Wow6432Node\microsoft\windows\currentversion\uninstall ^| find /i "26A24AE4-039D-4CA4-87B4-2F83218"') do echo %%i >>"%temp%\remove32java8.txt" for /f "tokens=7 delims=\" %%i in ('reg query hklm\software\microsoft\windows\currentversion\uninstall ^| find /i "26A24AE4-039D-4CA4-87B4-2F3218"') do echo %%i >>"%temp%\remove32java8.txt" for /f "tokens=8 delims=\" %%i in ('reg query hklm\software\Wow6432Node\microsoft\windows\currentversion\uninstall ^| find /i "26A24AE4-039D-4CA4-87B4-2F3218"') do echo %%i >>"%temp%\remove32java8.txt" REM Find installs of Java 8, 64-bit and dump MSI codes to file for /f "tokens=7 delims=\" %%i in ('reg query hklm\software\microsoft\windows\currentversion\uninstall ^| find /i "26A24AE4-039D-4CA4-87B4-2F86418"') do echo %%i >>"%temp%\remove64java8.txt" for /f "tokens=7 delims=\" %%i in ('reg query hklm\software\microsoft\windows\currentversion\uninstall ^| find /i "26A24AE4-039D-4CA4-87B4-2F6418"') do echo %%i >>"%temp%\remove64java8.txt" REM Reverse-sort those files of MSI codes, so the newest version is at the top sort /+33 /r "%temp%\remove32java8.txt" /o "%temp%\remove32java8.txt" sort /+33 /r "%temp%\remove64java8.txt" /o "%temp%\remove64java8.txt" REM Loop through those files, skipping the first line and uninstalling other versions for /f "skip=1" %%i in (%temp%\remove32java8.txt) do msiexec /x%%i /q /noreboot REBOOT=REALLYSUPPRESS for /f "skip=1" %%i in (%temp%\remove64java8.txt) do msiexec /x%%i /q /noreboot REBOOT=REALLYSUPPRESS if exist "%temp%\remove32java8.txt" del "%temp%\remove32java8.txt" if exist "%temp%\remove64java8.txt" del "%temp%\remove64java8.txt"

cmd script to install 8u60 from an unmodified msi, then look for older versions and uninstall them. It works, but... bleh. :\