Hi TAMUQITS It is possible, you can download the ISO for FEP from MS volume licensing center, install it as a stand alone. This will mean that if a box is not on the domain and it get the base image deployed to it, it can source updates for FEP from MS update.

If a box get the gold image deployed to it and it is on the domain, Group policy and SCCM client settings should take over the behavior of FEP. I would deploy two boxes and test, one on the domain and the other as standalone using the same Gold image.

Hi, Yes, please try just a single machine. If it doesn't work, try just one patch. Things to check/consider: If you have SCCM SP1 to fix this error go to the settings page in the Administration client in computer, computer agent 'Additional software manages the deployment of applications and software updates' change to 'NO' If not, check these: Is the GPO set to point WSUS to your SUP? Is the format correct - Is it being trumped by any other?

Are the patches even downloading to%windir% ccm cache? Have you checked the local machine logs UpdatesDeployment.log and WindowsUpdate.log? (the second one is the key as it shows what the agent does, although in this case 0 patches are selected) Finally, can you deploy any other software to the same collection? Are all roles in monitoring healthy, especially the MP? If the answer to the last is no, you have much bigger problems. When testing I also set the patch to required (meaning mandatory) and set the time to 'as soon as possible' as a deadline. Office hours are default 9-5pm and I see the patches deploy after 5 or 10 mins tops.

Hi, The rules look fine as those are the settings I use. The last line of the last log is: - Total actionable updates = 0 Which is as if the machine has scanned itself and compared the list of updates and decided that none of them are applicable. Have you verified that any (or all) these patches install if you run them manually?

In this post we will look at the steps on how to deploy software updates using SCCM 2012 R2. Deploying the software updates for the computer.

Also have you deployed the patches to your DP? Check this walkthrough Finally there are two more very useful logs: UpdatesHandler.log - which will tell you about software update compliance scanning and about the download and installation of software updates on the client. The other is UpdatesStore.log that shows compliance status for the software updates that were assessed during the compliance scan cycle. Mike, I looked at the walkthrough and everything seems to be correct. I did note that UpdatesStore.log has no new entries since I installed this box. The only entries in UpdatesHandler.log are:

If you run GPresult does the proper SUP address get applied? I had to correct a GPO at work because they had another domain level GPO pointing at windowsupdate instead. Also, on your test machine, does other software deploy OK? Everything should appear in Software Center. A mini recap: Your patches are imported in SUP? They show as downloaded in SUP?

They are on the DP and the content source is GREEN? You have ADR to make them available ASAP You have no maintenance windows on the client The latest windows update agent is installed on the client (needs to be 7.6.7600)? Just in case: It seems to me that the client 'pull' is not working so replying that everything is fine. Hi, SUP is just the management front-end.

At the backend it uses WSUS on the server and the Windows Update Agent on the client. You kick the whole thing off by synchronising the SUP database with WSUS. WSUS downloads patches and SUP presents them. When you right-click download it makes a copy in the content library I think. On the client, the actions poll on a schedule. It asks the MP - any jobs? If there are it gets a list and then pulls the patches into the cache.

They are now 'available' and the WUA starts installing them in a chain, the same way it does if just connected to windows update.Com. So, yes the WindowsUpdate.Log is vital, but if nothing is arriving in the cache, then it will be empty. It's case of nothing ever being dispatched. The question is is the client giving bad info back to the MP, OR is there something stopping the patch being made available. The CI total you keep seeing is just a headcount of 'configuration items'.

So the client is being told there are 145 things to do, but none are *actionable*. With regards GPresult there *must* be a policy set to point the clients. Normally when you install the client, it sets this for you automatically, so it just works. Given that nothing is working it's prudent to check! There is a nice article here although for 2007: WSUS One thing to check is the WSUS health: WSUSCtrl.log These (server logs in Logs) are handy too Log File Name Description ciamgr.log about the addition, deletion, and modification of software update configuration items.

Distmgr.log Provides about the replication of software update deployment packages. Objreplmgr.log about the replication of software updates notification files from a parent to child sites. PatchDownloader.log about the process for downloading software updates from the update source specified in the software updates metadata to the download destination on the site server. Finally you need to look at the eventlogs too. Look for all WSUS events. Also never, ever configure WSUS if you are running SCCM with a SUP.

SUP provides the means to download, filter, approve, deny but NOT delete patches. Configuring WSUS can break things. Even setting WSUS up is frowned upon. The best way is just enable the role and reboot.

Don't even launch the console:). If you've never used WSUS then there won't be GPO for it. If there was a conflict you would get explicit error code. The odd thing is you are not getting any error codes at all. As for the IT org - that will not affect anything as it is purely cosmetic but maybe check the 'client settings' in the update section. If you set the name as shown here: It ought to work. Info on GPOs etc.

Hi, I've been out all day. Forgetting the client for a moment, are other machines able/are still getting software deployments of any kind? It's a good test, if patching is not happening, push something else that you know, without doubt worked before and still ought to. I don't have any other ideas, no. Have you checked the eventlogs? WSUS health etc.

With the GPO I think I didn't explain one bit: there has to be a local policy (not domain) on each machine which is set when the agent is installed. As I said, if you did have a conflicting GPO you would see an error code. So we can rule that out. There still has to be a policy set somewhere though. As for the machine with the broken client that's not good news. Try a clean install.

Deploying the client itself is a good test of the infrastructure. If you can't even do that then patches won't either. It may be isolated, but once you get the client to reply then you know SCCM is pushing OK, so it's a good target to test patching. I did just notice something under Software Update Point Sync Status under Monitoring. Our wsus server, wsus.domain.local, is showing a successful sync.

It's operating fine. Our ConfigManagerCentral link and our ConfigManager link are showing a blue exclamation with no syncs at all. The unusual part is that ConfigManagerCentral is pointed to Microsoft Updates, while the primary site, ConfigManager, is pointed to wsus.firstcom.local. Neither have synced. Evenflo Exersaucer How To Install Seat. Upon re-installing the SUP role to ConfigManagerCentral, I don't see an option to direct it to our wsus.domain.local server, which I imagine is where it needs to be pointed to.

Can you advise? I came to the realization that ConfigManagerCentral should not need to be marked as a SUP because the external WSUS server is on the same site code. Iwcm.log seems to indicate that it cannot connect to the server. It's pointing to itself, which I believe it's supposed to do? My wsus server is external and on a Server 2012 box, so it uses port 8350, but the primary site that I'm having trouble with is Server 2008 with only the WSUS Admin Console, so I believe it's port 80. Which port do I need to configure my primary site for?

The port for the main wsus server that's running server 2012 (8350) or the port for the local WSUS admin console, which would be 80? If it's 80 I'm getting a 404 error in wcm.log.

If it's 8350, it's denying the connection. So a) which port do I use, and B) if it's 80, why would I get a 404 error, and if it's 8350 then why would I be getting a closed connection?

IIS is installed on all boxes. Hi, Sorry I didn't see you previous reply. You have a CAS installed? That changes things a bit, but as you have found you need to get the SUP to sync with WSUS.

Here's some tips from a very good guy: The combination of ConfigMgr and Software Updates is not always a simple one. This because when it's not working, it's not always easy to find the solution. Here are some best practices for installing and configuring: • When installing WSUS, choose always for a custom website, with ports 8530 and 8531. This way the ConfigMgr Management Point and Software Updates are not both configured on port 80 and 443 (best practice). • check permissions on the WSUS and WSUSContent folder: the Network Service account must have the right permissions. On the WSUS folder set Read permissions; WSUSContent folder set Full Control permissions • For WSUS on a custom website check security in IIS.

This must be set to Anonymous authentication, with a 'IUSR_' account. This must be a Domain User account, with Local Admin rights on the ConfigMgr server. • With MP Troubleshooter (ConfigMgr 2007 Toolkit) you can check if the IIS account has enough permissions for accessing both websites. It's always necessary for having enough (local) rights on the ConfigMgr server. • Sometimes a Proxy server must be used for synchronizing updates. Try both configurations (on and off) with or without an User account.

Sometimes there must also made a bypass on the Proxy server for getting it to work. • At last, do a 'Run Synchronization' on the Update Repository and follow the Software Updates in the wsyncmgr.log (easy to see with SMS Trace - ConfigMgr 2007 Toolkit). When synchronization is done, do it again till no updates are available anymore. Then create Search Folders. • Use Search folders.

Then it's easy to see which updates are available for the last month (example) for a specific product. These updates can be drag-and-dropped on the Update Lists for creating overviews.

So, the answer to the ports is: you need to point the SUP to port 8350, not 80. 80 is only for the console connection. As for the denying, you need to check whether you have SSL enabled on the MP (I think - I don't have sccm access to see). If you do have it set then the port is 8351 instead. Yes, we have a CAS. Here's the structure: We have a central server -- site code FCC, server name ConfigManagerCentral, running Windows Server 2008.

It has the WSUS admin console running. We have an external WSUS server that is part of the central server, FCC site code, listed as wsus.domain.local. It runs Server 2012 and has the full WSUS console installed.

We have a primary site, ConfigManager, that has site code HQ1, running Windows Server 2008. It has the WSUS admin console running. We also have two other primary sites that we use from time to time for special projects. I'm not really worried about these, so disregard them. I don't use SSL anywhere in my configuration.

It was my understanding that port 80 is supposedly used for certain versions of WSUS (3.0 SP2 on Server 2008), and 8350 is used for WSUS on Server 2012. When I set up my primary site as a SUP, it's trying to connect to itself per the log files posted above.

Is that what it's supposed to be doing? If yes, I would have thought I'd have to set the port to 80 because the primary site is running WSUS 3.0 SP2 on Server 2008. Sizzla The Story Unfolds Rarest.

If it goes to port 80, I get a 404 error. If it goes to port 8350, I'm getting connection refused. IIS is running on all servers. Hi, I just posted an addendum and lost it all. First, you made a typo and then I copied it! It's port 8530 and 8531 for SSL, not 8350. As for the WSUS port - yes you're right.

On 2008 it's hard-coded to use port 80 and 443. On 2008R2 and later you can choose. Ideally, for SCCM you choose custom for the WSUS install. It does not have to be 8530, just make it the same! As for the CAS install, I can't remember the wizard option but this is a good walkthrough although they install WSUS on the same box..

And It should not matter where WSUS is as long as SCCM can talk to it. So, forget the 2008 boxes. You have WSUS 3 Full install on a 2012 box. Change the port there AND in SCCM to 8530. Also forget about using the WSUS console anywhere.

You do everything through SCCM now. If you are getting connection refused for 8530 make sure it IS 8530 and that is allowed through any firewalls. I can't think of anything else. Also, any approvals etc on the 2012 box will be void. The patches only appear in SUP.

The approval is implicit by creating rules. Sorry, the port was correct at 8530. 8530 is also the default for WSUS on Server 2012, so it's already been set that way. When I update the role for the primary site in SCCM to reflect 8530, it says the connection is refused.

A reminder: Site code: Server: Purpose SUP installed FCC WSUS External WSUS server Y (working) FCC ConfigManagerCentral Central Site N HQ1 ConfigManager Primary Y This is wcm.log: Changes in active SUP list detected. The SUP on the Primary Site syncs with Microsoft Update and replicates down the Updates down the hierachry. If this role is installed on the Central Site Server itself or on a seperate Server does not matter. The WSUS Admin Console is just required on the Site Server when you push the SUP Installation on the WSUS Server. In order to deploy updates in the child primary site you need a SUP there also. And SUP always means a Full WSUS Installation.

The Central SUP then syncs with the Primary child site SUP. Also check out this. Yes, and when I load the page it shows the IIS screen.

Wcm.log: Changes in active SUP list detected. It takes some time until the processes are going on. Please recheck a few things. Is the ADR working (RulesEngine.log) Is there any update in Software Update Group? Is there any Update in the Package Is the Package updated on DP? (Content Status) Is the deployment linked to your Client?

Rightclick Client ->Deployment (Are there Updates listed?) Are updates listed as required? - On Client run a Software Update Scan Cycle - On the Server run a Software Update Summarization - Are now updates listed as required?

On the Client run a Software Update Deployment Cycle All These processes need some time to run and to get processed, so please be patient. Hi, I know you want to get this going but one thing SCCM teaches you is patience.

It won't deploy anything until the sync is utterly complete. Watch the wsyncmgr.log if you want to see progress. It will take 2 or 3 hours maybe more if you have lots of products/languages/slow internet pipe. In the olden days SMS was known as 'slow moving software' for a reason. Once the sync is complete there is also the wait for rules to trigger and then updates to distribute out to the DPs. Slowly, slowly catches monkey:).

Mike PS: fair enough with the CAS. There might be better ways using Branchcache now but I've never played with that and it's a whole new can of worms. I can see that the items are deployed under the client. I am not sure how to check if they're required, but the client isn't getting a software center prompt nor do I see that anything is downloading. When I run a software update deployment cycle, updatedeployment.log just shows initiating 0 assignments. I will wait until the sync is complete. It's taking a long time.:) And yeah, I've read about BranchCache but I am pretty new to SCCM and there is so much to learn that it's hard to touch on everything very quickly.