xc3ss1v3

Bueller?

In regard to certificates in this situation, I'm a bit confused. Currently, I have WSUS self-signed certificates in both the CAS and PSS servers in the Trusted Root Certificate Authority, Trusted Publishers, and WSUS. Do I need to have the opposite server's certificate stored in each store as well? In other words, have the CAS's WSUS self-signed cert stored in the PSS's Trusted Root Certificate Authority? Sorry if this is an ignorant question. Just have never really messed with this.

Update: So it looks like we had updates being published to what is basically the secondary WSUS server instead of the top-most WSUS server. After changing that, the option to choose Adobe products appeared in the Product list for Software Update Point settings. However now, it seems we are having some certificate issues in publishing the actual content to the CAS. Starting to wonder if it wouldn't just be easier to install SCUP on the CAS instead of on the PSS.

Just thought of another question... Sorry for bringing up yet another. In my hierarchy, we have a Central Admin Site and a Primary Site Server. The CAS has the WSUS role installed and configured to go out to Microsoft to retrieve updates. The PSS also has the WSUS role, but is configured to pull from CAS (not sure if that's needed or if redundant, as that is just how it was configured by my predecessor). We have installed SCUP on the PSS. Is that going to create an issue? Does it need to be installed at the top level site for updates to be seen by the SUP?

So I found this little blip on another thread... I'm guessing that since the Adobe Product group is not showing up, something isn't right with SCUP publishing the catalog to WSUS?

Thanks for that... will check it out. I did notice that I didn't have "updates" selected under Classifications in Software Update Point settings. I've done that and re-synced. While it seems that I've now synchronized a butt-load more updates, I still am not seeing the one published from SCUP. Also, will all of these new updates that just synced with the setting change be deployed with the already created ADR for monthly Microsoft Updates? If so, there's going to be a ton :/ Another thing... I still don't see extra groups under Products. Just "Local Publisher." Anyone know if that is a ConfigMgr version thing that I'm missing?

Yes, that is what I noted in my EDIT above. I've selected "Locally Published Packages" under All Products > Local Publisher. However, I do not see specific 3rd party vendors in my list like I do in some screenshots around the web. Not sure if that's a ConfigMgr versioning thing or what. Note that after selecting that option last night, I still am not seeing the Adobe Reader update in my list. Is there a way for me to check that the update is, in fact, published to WSUS other than the SCUP.log?

I'm hoping this one is something simple (thinking it will be). I'm just getting started on using SCUP 2011 to handle our 3rd party software updates via ConfigMgr. So far, I've been able to install SCUP 2011 on my Primary Site Server, download an Adobe Reader 11 catalog, and publish it to WSUS (seems to be successful according to scup.log). Of course, things were going too smoothly for that catalog to just magically show up in ConfigMgr for me after running a synchronization. What I have a feeling I'm missing is that ConfigMgr doesn't know to go look for the Adobe Reader update and I cannot, for the life of me, figure out where to set that up. I also don't seem to find any documentation on the topic. Everything seems to be aimed at how to set up and configure SCUP for downloading and publishing catalog, but not how to actually get them into ConfigMgr. Am I missing something somewhere? Thanks in advance. *EDIT: I just found under Software Update Point on the Central Admin Site where I can select to synchronize updates from a local publisher. I have checked that and am running synchronization again. We'll see...

Okay... in this particular case, this error was definitely being caused by a corrupt .wim file created by a failed offline servicing. Just for fun, I created a new .wim using a B&C and also used the .bak wim file, re-scheduled offline servicing which completely successfully on both, and was able to use those to successfully deploy an OS again. Thanks for the assist!

I'm think that is what caused it. I looked back in the logs and there was an error concerning copying the .wim back to the source drive (think I inadvertently restarted during the process) and now when I try to re-schedule those updates, I get an error saying that it can not read the image format. Guessing there's some sort of corruption in it. Instead of just reverting back to the .bak file, I'm running a new build & cap for a completely fresh .wim. Will report back what I find. Thanks for the help.

Hey guys and gals... I've suddenly run into an issue where my OSD TS is failing at the Apply Operating System step with an error code of 8007000B "An attempt was made to load a program with an incorrect format." Upon some preliminary research, it seemed this early was likely due to some kind of mismatch between x86 and x64 boot images vs. OS image or possibly with WinPE 5.0. I've double and triple check the bitness of both the OS being deployed and the boot image being used. Both are x86 in this case. I've deployed fresh WinPE 5.0 images with no extra drivers installed to be sure that wasn't the issue. I can't imagine it's the actual OS image as it was working just fine and nothing has changed AFAIK other than offline servicing of latest Windows Updates. Could that possibly be an issue? I've attached an SMSTS.log for review. smsts.log

Everything looks good in that regard. And, it seems all my clients are now updating properly. The only thing I can think of is that policy that was keeping clients from updating via ConfigMgr after being out of date for X days. Did you see any thing out of sorts in the logs?

As requested... Support.zip

Here you go. Note that this system (like all others) was successfully updated yesterday via Microsoft's update. We did that to make sure all clients are back to current for the time being. But, we have initiated the block on that access again and now systems, such as this, are not showing updates for today's definition. We're using R2 Oh.. and other software updates do appear to be working. Windows updates were pushed last night and they seem to be installing without incident. WindowsUpdate.zip Logs.zip

Do you happen to have any other ideas of what I might be able to try to test with or look at in regard to what's going on? I asked my network guys to allow clients out to update definitions, which all have done, so all is okay on that front. But, that's not something they want to continue to allow. I can't help but think that this is being caused by something on their end, but I can't say that without having some kind of proof. I need to be able to show that 1) the definition updates are available for clients to receive and 2) an error of some kind showing that the client is attempting pull definitions from ConfigMgr and cannot.

If by that you mean is the deployment up to date and available on the distribution server, then Yes. But, I might not be understanding exactly what you're asking.

One thing I just noticed... It appears as if Default Client Antimalware Policy AND Endpoint Protection - Managed Device Policy are both deployed to clients even though I don't have Default Client Antimalware Policy actually deployed? Is that one that is applied no matter what? If so, do the settings in my custom policy override it? I currently have the custom policy order set to 1 and Default is set to 10000.

Basically every client is just like this or at least similar (last update being older). We are currently blocking updating from outside sources. I did notice that in the Antimalware Policy, there is a setting that will only allow clients to update from outside sources after so many hours of not being able to update with ConfigMgr. To take that setting out of the loop, I set it for 720 hours (30 days), but the clients still don't seem to be updating. I will also note that the majority of clients haven't pulled Antimalware Policies any time recently. Is that indicative of a somewhat broken SCEP client? Note that on this particular machine (in the screenshot), it is pulling current policies.

Thanks for the clarification. In looking at those logs, I'm not seeing any errors (that I can tell). To me, this just seems like some kind of break down of communication between the clients and servers in particular regard to SCEP. Completely at a loss ):

I hope you can excuse my "noob-ness" in this regard, but would you care to elaborate?

Hey guys... It's come to my attention that all of our clients are now out-of-date in regard to definition updates. I will first note that our networking side did replace the firewall around the same time that this issue started. However, I don't really have any ammunition to go at them with as to why it is (if it is) their fault. This has just been one of those things that has always worked. As for my set up, I have an ADR created that creates deployments for definition updates as soon as they are downloaded each day. From what I can tell, it last downloaded and deployed an update this morning around 10 a.m. So, it seems as if the issue is that the clients aren't getting the deployment. Is there a log of some sort I can look at to find potential issues? Thanks in advance.

The task sequence completes successfully (aside from not installing the applications because of the network unavailability). In doing some more investigation, it appears as though the drivers for the USB3 Controller get installed, but the Fresco Logic USB Root Hub does not, although those drivers are all available and show to install during the TS. I've noticed that as soon as I run the setup application for the device, that driver successfully installs and the device starts functioning. Of course doing that in the TS will take some strange voodoo that I'm not aware of at this point. Any ideas?

Has anyone had success using a USB-Ethernet adapter to deploy an OSD via PXE on a tablet or XPS type system without a network port? So far, I've been able to inject the drivers for the adapter into the boot image and boot the system from a USB stick so that the system will be allowed network access and start the OSD TS. However, after it applies the OS and restarts after driver installation, the system no longer has network access and the TS eventually fails because it cannot talk to the site servers. I'm guessing this is being caused the by drivers for the adapter not being applied to the OS such that after the reboot the boot image is no longer being used and so the adapter does not work any longer. I've tried inserting a "Apply Driver Package" step after the OS application step hoping that would allow the adapter to function, but that didn't seem to work. Does anyone have any suggestions?

Hey guys... So after a lot of tedious reinvention of the wheel type work because of a former employee's lack of organization, I've finally got my OSD task sequencing working and at a point where if errors come up, I know how and where to troubleshoot them (many thanks to Niall!). With that said, I'm looking for some ideas on how you guys are handling deploying OSD sequences to various models and how you are handling driver installation. It seems that the TS works best when you tell it exactly which driver package to look to for drivers (for instance I have a package for a Dell Latitude E6530) that I specified in the TS and the TS worked flawlessly on that model. Without specifying, I noticed that the TS was pulling drivers out of other packages. I guess that's okay if the TS still completes, but my worry is that the driver being pulled isn't fully compatible. So, I'm wondering, do I really have to create a TS for each model device we utilize? Is there some way for the TS to recognize the model then choose the appropriate package? Or, am I just completely over-thinking this and should just let the TS pick the drivers out itself from any category and troubleshoot potential errors as they arise? Thanks again.

Thanks as always. I'm re-doing all of our drivers to get them organized.