Until we installed WDS yesterday. Now WSUS has basically disappeared from the server.
Not really sure what to say. WSUS and WDS will certainly co-exist on a Windows Server 2012 server, and there's no known reason, nor have I ever seen/heard of installation of a server role causing another to uninstall.
Perhaps it would help if you could describe exactly what you mean by "WSUS has basically disappeared from the server"?
HI Lawrence. I was hoping you would chime in. Pretty much every WSUS post i can find on the net has you solving the issue.
This is a brand new Windows 2012 standard server that i created about a month ago. It's running on esxu 5.1 with the data living on a hp p2000 san. I was pushing out IE 10 yesterday from wsus and pushing out adobe reader installs with transform files from patch manager as well. We decided to install WDS on this server to take advantage of some slower storage that we put in the SAN(for the desktop images) As far as WSUS disappearing. I noticed my WSUS admin snap in that is installed on my workstation could no longer connect to the wsus server. I pull up patch manager console from my workstation, go to all updates and receive another error about not being able to connect to the wsus server.
On the server itself:
I no longer see the wsus snap in under administrative tools, i dont see a shortcut to pull up WSUS, like there used to be.(when hitting the windows button on the keyboard)
There are no wsus related services shown in the services snap in.
I see a few wsus specific errors under event viewer.
When viewing add/remove server roles, i see WSUS is installed but nothing else. (see screenshot)
I tried to reinstall patch manager thinking that would also reinstall wsus. But the installer crashes and i get an app crash(configurationhelper.exe) when it is "configuring the correct WSUS version to the config files".
A couple of notes.
On WS2012, the WSUS console is a "feature", and you'll find it listed under Features -> Role Administration Tools. (See below).
Knowing unequivocally that installing WDS would not remove WSUS, nor can you remove a role using the "Add Roles and Features Wizard", it does beg the questions of WSUS apparently became uninstalled from this server. I would suggest combing through Event Logs for anything relevant to that purpose.
Uninstalling/reinstalling Patch Manager is not going to be able to fix a broken WSUS installation; more to the point, the only thing that would be required is to just fix the broken WSUS installation.
However, now, you also have a broken Patch Manager installation.
If there's nothing else running on this server except WSUS (broken) and Patch Manager (broken), and you've not actually implemented anything with WDS yet, you might just consider blowing it all away and starting from scratch.
Or, if WDS is already configured, or if you don't want to reinstall the OS, clean up the role installations for WSUS, verify all components are removed (e.g. IIS v-dirs, registry keys, %ProgramFiles%\Update Services folder), verify the WID really has been removed. Reboot the server and re-run the PM installation. (If the WSUS server is fully cleaned up, the PM install should be able to build a new WSUS.)
Or (safer, but more work)... install the WSUS role on the server without using Patch Manager. Verify that the WSUS role is installed and functioning, and then install Patch Manager using the "Advanced Installation" option, where it will give you an opportunity to tell it to use an existing WSUS Server.
thanks for your insight Lawrence. This server is hosed. Oh well, more practice. I think were going to finish making a new image for a new model computer we have here now, then export those images and boot images out, kill the server. Then recreate the server with only patch man and wsus, and put wds on a different server. Somehow when adding that wds role, it uninstalled wsus.
thanks again man.
I would encourage you to re-evaluate exactly what happened during your WDS installation.
I can tell you for a fact that it will work, because I have DHCP, WSUS, WDS, and a Patch Manager Automation Role server all installed together on a single Windows Server 2012 instance.
The specific order of installation was:
- WSUS (w/WebServer Role)
- Patch Manager Automation Role
Yeah, when researching solutions to this issue, i cam across several posting by you that said you had been running wds with patch man/wsus without issues. So something obviously went wrong when adding WDS to that server. As far as actually adding it, the whole process is pretty fast, not much to it really. Then we copied our boot images and install images into WDS. We then editing and added some new boot drivers to some of our boot images. Did some testing on some machines. And that was pretty much it. Came in today and it wasn't working.
Well, i built two new servers. One with WDS and one with WSUS/Patch Manager. I think i am good to go, and just published our transform version of Adobe Reader 11. Except i am having trouble seeing the 3rd party updates folder.. Shouldn't it be right here(where the arrow is). I am pretty sure it should be right there so that i can approve it and then approve it for the correct groups that i want to test it on first.
Thank you Lawrence and David. I don't remember doing that the 1st time i setup patch manager. I guess that is why i thought it was supposed to appear automatically. Thanks again guys.
I know this isn't really the best place for my questions, but google isn't really showing me anything.
We are running IE 9 here at work, some websites need it. Now we are transitioning to IE 10. For some reason most of my machines say "Not applicable" and i can not figure out why.
These are all windows 7 pro 64 bit machines. On WSUS i have a rule that automatically approves all security updates and critical updates. ( even though i know IE 10 is an update rollup)
On the Patch Manager side I have approved the update "Internet Explorer 10 for Windows 7 for x64-Bit Edition) released 10/8/2013. I know there are prerequisites for IE 10..
Windows 7 SP 1 - check
I've approved all of those updates. And so far none of my workstations are installing IE 10, even though most of them have installed all those updates by now.(although a few of them have been superseded and are skipped. Any idea of what to do or check on this?
I've restarted my machines, i've manually ran the windows update from the machine. I've done the detect now command from patch manager. thanks
Gotcha. Yeah, i didn't see that update anywhere. Thanks. I have approved that update and will report back with any additional issues. Thanks Lawrence, i really appreciate you taking the time to answers my questions. Overall i am really impressed with Patch Manager.
Can someone help me figure this one out?
"Update not applicable. Unable to find the Update by ID to perform the requested operation. The update may not be applicable for the selected computer Result Code: 0x80240003"
We have a working Adobe Reader XI install with transform. All clients are running 11.0.06.70. And now Adobe came out with 11.0.07. So i am trying to push out the .msp update, and am getting the above error code.I tried following the steps here from David.. but am getting the same issue.
this is from my c:\windows\WindowsUpdate.log (had trouble copy and pasting log, so i made a screenshot of it, below)
Screenshots don't really help if the image cuts off the most important part of the package.
Why aren't you simply using the Adobe Reader update package provided by Adobe?
What are you doing in PackageBoot (that's not shown here)?
In fact, perhaps more to the point, what are you trying to modify about this *MSP* package?
It's pretty basic how it comes from Adobe. You publish it. If Adobe Reader v11 is installed, it gets updated to 11.0.7. If it's not, it doesn't.
There's not really much you can actually modify in an MSP update package.
Hi Lawrence. Thanks for your reply. Well, as you can probably tell..i am new to this. I only took screenshots of the areas where i was changing or editing stuff; otherwise i was leaving the screens at their default settings. Well, since we had a package that works and has already installed Adobe Reader 11.0.06.70 company wide, with a transform. I figured maybe i could create a custom package that just had the .msp updates. And i didn't want to use the default package from Adobe, because i wanted to make sure my transform was taking effect. Make sense?
I didn't make any changes in Package Boot, i just added it to the package because i remember reading how package boot makes sure the environment is good to install applications. Before i added package boot, i just did the reboot before installation option, so the test machine restarted itself, but then found out that the package wasn't applicable, so it didn't work. Then i added package boot to the mix, still didn't work.
To answer your question, i was just trying to install the .msp package to my already installed transformed version of adobe reader 11.0.06.70.
I decided to just create a whole new package and do it just like i did for my original working 11.0.06.70. I now have a new package of 11.0.07.79, with transform. I have approved it and deployed to my workstations. Should I decline the 11.0.06.70 package as well?
Lastly, at some point I am going to start deploying java and maybe gotomeeting plugs ins and flash. Any how to guides or links for information, so i can avoid blowing this thread up more?
thanks again for your time and your help.
I didn't make any changes in Package Boot, i just added it to the package because i remember reading how package boot makes sure the environment is good to install applications.
If you're not actually configuring anything in PackageBoot, merely enabling it does nothing since all of the sample rules are disabled by default.
In your particular case, though, I just discovered the root cause for the Not Applicable. Of course, I was discouraged by the cropped image on the ruleset, so I didn't make the effort to look any farther; however, it turns out you did provide enough information to identify the defect. The highlighted block should be a When ANY of the following....
By making it When ALL of the following... you're requiring a system to actually have both architectures -- which is impossible, thus this package will always be Not Applicable with this ruleset.
Note... also, I would suggest a different logic structure here. Since the only OR value is the processor architecture, consider this logic:
When all of the following...
Windows Version greater than or equal to <whateverVersion>.
When any of the following....
It's cleaner, simpler, and thus much easier to understand (and troubleshoot).
In the examples where you see the logic you used, that's typically because there's a File Version rule in-use that has files in different locations according to the architecture. (If you ever seen your logic used in our packages for a Windows Version rule, except for where it affects Windows XP SP2/SP3, please let me know where and I'll lobby to have that improved.)
Lastly, at some point I am going to start deploying java and maybe gotomeeting plugs ins and flash. Any how to guides or links for information, so i can avoid blowing this thread up more?
Don't customize packages unless you have an express reason for doing so. Use the packages as-provided. Incidentally there's a conversation elsewhere in this forum about trying to package GoToMeeting. It's not suitable for distribution via WSUS because GTM is a per-USER installation.
Okay, i understand about the package boot thing now. Thanks.
Yeah, choosing "When all of the following" was purely a mistake, i meant to choose when any of the following. Okay, 10-4 on the logic, i'll do that next time.
Thanks for the info on go to meeting. Kind of a bummer to hear.
Speaking of java update. What does this line do? (java update =0 and license yes" Is this already turning off the auto update feature? and also accepting the license? So i dont have to include that .cab file from david, or worry about registry gpo hacks to turn off auto update.
AgreeToLicense=YES auto-accepts the EULA.
JAVAUPDATE=0 temporarily disables the auto-updater so that this package can be installed without being adversely affected by the auto-updater doing something conflicting.
Using the mods presented in David's package are one way to approach disabling the desktop auto-updater.
The other way is by using Group Policy.
The advantage to using Group Policy is that you can make the change effective immediately, across all systems, you don't actually have to wait to deploy a JRE update, nor deploy an unsupported custom package to do so.
thanks. Alright, we are just going to continue using a GPO to keep the auto updated turned off. I ran this java updater on a test machine and it installed fine. Went to adobe.com to verify the install and that turned out well.
However, is there a command we can specify in the package that will uninstall old java versions?
for instance on this test machine i have
java 7 u 55 (which is good)
java 7 u 55 64 bit, (which is good)
java 6 update 29--64 bit
java 6 update 31
how can i remove the old versions, since those are those ones with security exploits?
Computer explorer has a function called "Uninstall Software", which can be leveraged against a single or multiple machines. Here's a KB on this functionality.
I guess i was thinking a feature like in the Adobe Reader packages, where it uninstalls the older version first and then installs the new packages.
I need some help troubleshooting a custom package of Java u55. I downloaded the exe from Java's website, extracted the .msi. Opened Orca and changed a few values in the property field, then created my transform file. I imported my files back into the duplicate copy of Java u55 in Patch Manager. When i tried to customize the package as an msi. i got some digital certificate errors, so instead i used the .exe and was able to say yes to Oracle's cert. The package completes fine and i am able to publish it. When i deploy the package i see an error under task history.
From what i can find on google and from the old version of thwack before it was migrated. This is more than likely an applicability rule issue.
So on this package the applicability rule is...
This particular machine has NO java on it(since i uninstalled all versions to see if this new package would work). I go into Regedit and i don't see the path that is above, is this why it is not installing my package?
Can i remove those applicability rules? Any thoughts?
Is there some reason you're not using the SolarWinds-provided packages of JRE7u55 from the catalog?
Yes, I see that if you were going to apply a transform you'd need the embedded MSI; but then you bailed on that because it's not signed and reverted back to the EXE.
What else did you change in the package? What's in the Prerequisite Rules?
Also, the rule you've cited has RegType32=TRUE, but you're not looking in the 32-bit hive for the registry key.
Based on that, I'll assume this is the x86-on-x64 package you've pulled this rule from, and not the x64 package (which shouldn't be looking in the 32-bit hive).
Yes, x86 on x64. I was thinking maybe the unsigned cert error i was getting when creating the package was the reason for it not installing. I can always go back and change it to the .msi. And yes, i wanted to do the transform which is why i didn't use solarwind's version. I didn't change anything else in the prerequisite rules, i left it at what was already selected.
what other information do you need? or should i check?
There are many reasons for an update management task to report an update as "not applicable" (Please note the lower case here)...
This is entirely different from the Windows Update Agent reporting the update as Not Applicable in the console.
- What is the status of the update in the console for this client?
- What's in HKLM\Software\Wow6432Node\JavaSoft?
- Does the *SolarWinds* package properly detect as NotInstalled?
- Does the published update package show the files as "downloaded" in the console?
- Is the client targeted for this update assigned to the upstream server or assigned to a downstream server?
The Status of the update in the console is "Not Installed". I haven't approved this update, was just testing to see if it would work and tried installing via "Update Management". When i go into task history and then status it says not applicable.
In Regedit at HKLM\Software\Wow6432Node\JavaSoft i see this. Those are our two registry keys that we pushed out via GPO to turn off auto updates. I was just going to not worry about a transform since we already have the gpo setup, but then i read about creating a transform for Java, so i figured might as well do it and maybe we can get rid of the gpo.
All clients are assigned to the upstream server.
So an update to what i just said above. I decided to decline and delete that package and create a new one. I duplicated the one you guys provided browsed for my msi and created it, the msi was signed by oracle this time and imported fine. I added in my data.cab file and the .mst i created and published the package. I pushed it out via update management, this time the package installed fine on 2 machines, it says success for download and install for both machines, and then says installed when i explore the computers' updates. However, when i go to the machine(even after rebooting) I don't see java in control panel, i dont see it under add remove programs and when i go to java.com/verify it says it is not installed. So something is wrong. I'm almost thinking of abandoning the transform java idea and just continuing with the gpo we already have in place.
I *THINK* I know what happened here, and it seems that it may be a function of recent changes in behavior of the Windows Update Agent (introduced in v7.6 as best as I've been able to tell) and the specific order of steps performed.
It used to be in the days of WUA v7.4 and earlier that any deployment task (e.g. using the PM Update Management tool) triggered a full detection scan, and the WUA immediately cached any newly discovered update metadata.
However, a few weeks ago, pursuant to an IE10-deploy/IE10-upgrade scenario, I learned that the WUA no longer does a full detection during a deployment event.
What I think happened here is this:
- The update gets published to the WSUS server. At this point the WUA knows nothing about this update.
- The Update Management tool is used to attempt deployment of the update (ostensibly needed, and we know now, after the fact, that this was a true case).
- Unfortunately, because at this point the WUA knows nothing about this update, and does not do a full detection on deployment, the WUA cops out. This will manifest as an entry in the WindowsUpdate.log that says "No extended update metadata available", and that condition results in an immediate evaluation of the update as "not applicable" (i.e. not AVAILABLE), and that gets reported back to the Patch Manager server as the task result.
- Sometime subsequent to that, the WUA does a real detection/reporting event, and the update becomes correctly reported as "Not Installed". This scenario can also be validated by comparing the client's Last Reported Time to the Task Execution Time of the failed deployment task.
The 'fix' for this is to perform these steps in this order:
- Publish the update.
- Force a /detectnow on the client.
- Wait ten minutes and then launch the Update Management task to deploy the update.
Ok. Interesting. I will try that now. Does it matter that the update is not approved? Since i am testing to make sure all is well before approving, that's why i've been using the update management.
Does it matter that the update is not approved?
Well, up until a few days ago I would have said no... but recent observations have determined that the Update Management tool will deploy an update that is Not Approved, if the binary is present on the WSUS server. In effect, the UM overrides the native behavior of the WUA.
Since i am testing to make sure all is well before approving, that's why i've been using the update management.
You might also consider using the Update Management Wizard instead for this task, for two reasons:
- The UMW can be explicitly marked (the default) to only evaluate Approved Updates (or to explicitly include Not Approved updates, or even to filter based on the Approval Date).
- The UMW can be run in Planning Mode, so the WUA doesn't actually DO anything, it just reports what it would do if given the opportunity.
oh ok. I understand. I guess, i would still want to install it, so i could see if the transform took effect, or see if the updates were turned off, etc,etc.
Looks like the install said successful on the PM console.
this was during the install...
This is on one of the clients..looks like it has 'installed" it more than once...something must be wrong with my package. Still don't see anything in control panel/programs either.
When viewing the update, i go to computer summary, and the 2 machines i tried to force it on both say not installed. Of course the last time they contacted was at 4:25pm. I rolled the update out at 4:36pm(after waiting 15 minutes after doing the detect now function) Last reported time is 432pm, which is still before hand. Either way the updates are not on the machines anyway, so the time stamp is kind of moot.
What's the end goal behind the modifications you are making?
ha. I don't even know anymore man. The plan was just to roll out java update 55 with a transform file. That's it. I've also rolled out reader XI with transform that works, as well as flash 13 that also works--both of those troubleshooting steps are in this thread. Finally working on Java. I'm really not doing too many modifications..or at least i don't think i am. I'm just trying to get access to the .msi's create the .mst's, package them up and roll them out. I'm new at this, so that is why there has been so much back and forth.
I decided to delete the packages that i had published. I duplicated the packages that i wanted, renamed them and change their update type from security updates to just updates,(since our wsus installs all security updates automatically) I didn't bother with the transform this time or messing with the .msi or .exes. I published it and rolled it out. It is installing perfectly, We are just going to go ahead and enforce the no java update settings with our GPO that is already in place. Thanks again guys.