Microsoft update KB3159398
-
NOTE*
Have used CloneZilla in this manner for nearly 2 years.. have 120 workstations in production via this method. Unbox a new computer, clonezilla download image to disk. and then hostname & domain, and then deploy to desk.
-
meh, just feel like a beat dog today. dealing with some stupid issues from people all week. one of the sayings "cant fix stupid"
one of those "R YOU SERIOUS?!" have had that all week, lol.
But nonetheless. Uninstalling the update KB3159398 resolved the issue. Once removed and workstation restarted, GPO policies apply normally.
as I did gpresult option and reviewed the html file output. Was clearly showing the GPO policies were not applied when KB3159398 was installed. After the removal, the GPO policies were being shown as applied on gpresult.
Microsoft had just pushed out some very questionable patches/updates the past 2+ months. More so, dealing with them on consumer side. This one took the cake this morning in a SMB environment.
Luckily, Only effected a very small set of workstations.
-
@ntoxicator said in Microsoft update KB3159398:
I guess im a fucking noob.. i dont know.
If we had signatures this would be my signature. I'm just putting that out into the universe.
-
@wirestyle22 said in Microsoft update KB3159398:
@ntoxicator said in Microsoft update KB3159398:
I guess im a fucking noob.. i dont know.
If we had signatures this would be my signature. I'm just putting that out into the universe.
You actually listen to advice that's given to you tho..... most people can't reprogram themselves like that.
You also found the best place on the webs to get good advice, that helps a lot.
-
Thanks @ntoxicator
Pulling the update. -
@ntoxicator said in Microsoft update KB3159398:
call me old school.. But sysprep is waste of time -- much faster to get baseline machine and create images...
Considering sysprep has existed since Windows 2000, someone is just being lazy. If you said Ghostwalker, that's old school and hasn't worked in years.
Your GPOs broke because the patch addressed Keberos authentication and GPO.
https://technet.microsoft.com/library/security/MS16-072
Since you have the same SID on all those boxes, whomever grabbed the token first won. All my clients didn't have a single problem with this. Between the hundreds of domains, I haven't heard a single person complain about GPOs. And we have 15 domains just for our corp environment, not to mention the 50 or so with customers VMs.
In other words, work shit right and shit works right.
-
Very much understood and learned about SysPrep and such. However, the domain and environment has worked beautiful.
This patch/update just broke part of the GPO policy -- otherwise, the user profile was fine. It broke their Aero desktop, loaded classic theme.
It also broke BGinfo from being applied (Have .VBS commands that runs at logon). Pulling update restored their normal aero desktop, and BGinfo applied again.
-
This is why I never update Windows, too risky!
-
I've been debating how to approach this, I still don't really know.
@ntoxicator You say that is all working great, but unfortunately that's clearly not the case. You have this problem today, and you have the WSUS problem from before. While it's true that 95% of things work fine when you have duplicate SIDs on the network, but here are two examples of why you shouldn't do that.
You can probably solve this problem in your network by running sysprep now on those machines, don't use the generalize command, you don't want it to forget your installed hardware. set the computer name to the same, rejoin the domain, and you should be good to go. Of course test this on your machine or setup a test station to make sure you don't have other issues.
As for sysprep, JB and I both don't use the unattend.xml, we simply run sysprep /oobe /generalize /shutdown - this allows the machines to detect new hardware and generate a new SSID. Adding this to our deployment setup is pretty painless.
-
As for sysprep, JB and I both don't use the unattend.xml, we simply run sysprep /oobe /generalize /shutdown - this allows the machines to detect new hardware and generate a new SSID. Adding this to our deployment setup is pretty painless.
Thank you for this key detail here. I will work to add this to our deployment as well.
can I pull down one of the images to a new workstation. run the sysprep /oobe /generalize /shutdown command, and then re-clone the machine?
Or this command need to be ran on all newly cloned workstations? Then ofcourse, afterwards update hostname and set domain.
-
Yes you can push your current image to a test machine, then run the sysprep command, then after it shuts down, you can boot to your ghost disk, and make an image of that.
But this image is something you should only deploy on new computers, you don't want to deploy it to existing as the users will loose everything and essentially be on a new install.
to fix your existing machines, (and I can't stress enough - TEST TEST TEST) you can log into the computer as a user with local admin rights, make sure you know the local admin name/password (not a domain one) and run sysprep with no options. let it reboot, log in, change the computer name, reboot, join the domain, reboot, log in as the user and they should have their settings all back. But i've never actually done this, so again - TEST TEST TEST on a user/computer you don't care about first.
FYI, this process does not require leaving the domain, you'll be rejoining hopefully using the same computer name.
-
Understood! We have a documented set username/password for the local machine logon.
I'll be testing this on a fresh workstation I have here and create a new clone image for deployment.
-
@ntoxicator said in Microsoft update KB3159398:
Understood! We have a documented set username/password for the local machine logon.
I'll be testing this on a fresh workstation I have here and create a new clone image for deployment.
Just to make sure we're on the same page. I'm proposing two different things here for you.
- create a new deployment image for new computers/users that has sysprep baked in.
- syspreping existing machines to solve your SID/GPO/WSUS problem.
option 1 is pretty easy - deploy current image to test machine, run sysprep, shutdown, take new image, deploy new image as needed - enjoy life.
option 2 requires a machine that is setup using your old method, i.e. no sysprep. you need to have it joined to the domain, a user logon, create some junk on the desktop, some favorites in the browsers, etc. Now, run sysprep on that machine. upon reboot, do what is needed to get it to be the same name it was before and joined to the domain. Then when you log in as that user, the user shouldn't notice any difference, all files should be where they left them. If this is not the case, then you'll need to find another solution to the SID problem for previously deployed computers.
-
@Dashrender
Thank you so much!We're on the same page :). That is what my mindset was and will be testing.
We use Roaming profile/Folder redirection -- so all user files and data will be just fine.
Starting from today, I'm going to work create a new deployment image for new computers we deploy. I'll pull down an existing image, run the sysprep and then create a new image of this
Question:
Even after I make the clone image after running the sysprep. This will absolutely guarantee a unique GUID for each and every freshly cloned computer after fact?
Greatly appreciate you pointing this command out to me. As before I tried to create sysprep using the unattend.xml configuration.
-
There are no guarantees in life, but you will be using the prescribed method for deploying Windows and should have fewer issues, like PSX, JB and I.
Now if you want to automate more of the setup during the OOBE (out of box experience) during the mini setup post sysprep, you can still create and use an unattended.xml, but as you noticed, that takes a lot of effort and many trials to make sure it works as you desire.
I tell you, the thing I really want, is the ability to give the computer a computer name during the mini setup so I don't have to waste a reboot doing that inside Windows. hell, if I could join the domain during that same mini setup, that would be awesome too. There were ways to allow this in the past, but they definitely weren't simple.
-
Gotcha
Its just the fact the new clone image, when pulled down to a new workstation; it'll boot-up to the OOBE setup. Rather than take to Desktop / logon screen as currently does on our current image. And due to it being the OOBE; this is when the SID will be created.
I tell you, the thing I really want, is the ability to give the computer a computer name during the mini setup so I don't have to waste a reboot doing that inside Windows. hell, if I could join the domain during that same mini setup, that would be awesome too. There were ways to allow this in the past, but they definitely weren't simple.
I completely agree with you here...
-
@ntoxicator said in Microsoft update KB3159398:
Gotcha
Its just the fact the new clone image, when pulled down to a new workstation; it'll boot-up to the OOBE setup. Rather than take to Desktop / logon screen as currently does on our current image. And due to it being the OOBE; this is when the SID will be created.
Correct. You'll go through a mini setup. If it's Windows 7 it might even ask you for a computername, Haven't done one in a while, don't recall. Windows 10 definitely does not ask.
-
