Jump to content


LawrenceGarvin

Established Members
  • Content Count

    29
  • Joined

  • Last visited

  • Days Won

    1

LawrenceGarvin last won the day on December 4 2012

LawrenceGarvin had the most liked content!

Community Reputation

1 Neutral

About LawrenceGarvin

  • Rank
    Member
  1. Windows 8 is different. Windows 8 offers an option to "Update and Restart", provided it has not been disabled by Group Policy. This also presumes that the updates have not already been installed during the daily scheduled maintenance event, and the machine isn't already in the 72-hour waiting-for-reboot stage. It might help if you could better explain what you mean by the machines will not install updates on shutdown. If you're selecting only the Shutdown option from the menu, then the updates will not install. As noted, Windows 8 is different. You can "Shutdown" the system, or you can "Update and Restart". The "Install Updates and Shutdown" option carried from XP SP2, through Vista and Windows 7 (although hidden from the user in Windows 7 SP1), is no longer available.
  2. The first thing to recognize is that the client must be configured and able to communicate with the WSUS Server before you can update the clients. I'm not sure what you mean by "connected [the clients] to the server", but I don't see anything in the information you provided that discusses configuring the systems to be a WSUS Client. So, likely, the first place to start is with the section "Configure client updates" in the WSUS v6 Deployment Guide. Once you have the clients properly configured, if they still fail to appear in the WSUS console, then we can further troubleshoot those issues using the WindowsUpdate.log.
  3. Since you are running in native mode, have you properly and completely configured WSUS to support SSL connections? Note: The documentation in the System Center Configuration Manager 2007 doc set regarding WSUS and SSL is incomplete. Please refer to the WSUS documentation for implementing SSL for complete instructions: Secure WSUS with the Secure Sockets Layer Protocol
  4. If they're able to use those "stupid passwords", then I would submit that the policy, which may be "enabled", is not actually being applied, or else somebody has overridden that policy for certain user accounts (or computers). You should run RSOP on the affected computers and verify that the correct policies and settings are actually being applied.
  5. This is documented in the WSUS Deployment Guide: Configure a Disconnected Network to Receive Updates
  6. And yet... there is a feature in Active Directory/Group Policy that effectively does exactly this. Password must meet complexity requirements which is found in Computer Configuration -> Windows Settings -> Security Settings -> Account Policies -> Password Policy No, it doesn't explicitly define a dictionary of common words, but with this option enabled, it is near impossible to create a password using anything you'd likely define in such a dictionary.
  7. LawrenceGarvin

    RTFM

    Sadly, I suspect this conversation in the real-world might go in exactly the opposite direction. Today's students have a propensity to "figure things out" without documentation .. in fact, I suspect some of them are unaware that such a concept actually exists.
  8. The GX520 is a standard ATA controller, drivers should not be an issue. The machine is Win7/2008R2 compatible. But then, I'm understanding that this is occuring during while trying to captuer the image.. so where is the image supposed to be written to?
  9. GUIDs are case-insensitive. The lower-case characters should have no relevance. What is the logic process you used to determine that the GUIDs were the specific cause of the inability of the ConfigMgr agent to deploy to the client?
  10. You cannot deploy MSU files with WSUS. Period. That's by design. MSU files are typically associated with hotfixes, which are not intended for mass distribution, thus the lack of support for using WSUS in that fashion. This particular update, however, has been discussed previously with regard to this need. KB2671387 is an informational article about MS12-020, so I'm a bit confused at the statement that you've obtained an MSU associated with KB2671387. The actual patches are found in KB2621440 (WinXP/WS2003) and KB2667402 (Win7/WS2008R2) and are already available for deployment using WSUS presuming they were synchronized to your export server and imported with all the rest of the regular updates. As for a scenario where you need to deploy the contents of an MSU with WSUS, this SourceForge article describes how to do it with the free Local Updates Publisher.
  11. If a Configuration Manager environment is properly configured with a Software Update Point, and the Configuration Manager AGENT is properly installed on the client systems, there is no other configuration of the client required. The Site Server provides the proper configuration parameters to use the SUP via Local Policy. Most likely the case here is that either: - The CMAgent is not yet installed on these clients, or - The CMAgent is not enable to use the Software Updates component.
  12. The challenge here is twofold. The first is attempting to assign a Software Update Point to a Configuration Manager client using Group Policy. It will work, if you're assigning the right SUP; but generally speaking the SUP is assigned to a client based on the SITE assignment of the client by the Site Server. The second is misunderstanding the role of additional SUPs in a single site. Starting with Service Pack 1, ConfigMgr 2012 now supports multiple SUPs within a single site, but the additional SUPs are not operational SUPs, they are fallback SUPs in the event the primary SUP fails. All clients in a site are assigned to the primary SUP. If the client is unable to communicate with the primary SUP, it will fallback to one of the secondary SUPs. The secondary SUPs are defined by the Site Server as well.
  13. If you're using a Configuration Manager SUP for Endpoint Updates, but a standalone WSUS for Windows updates, you will not be able to roll them up into a single system, as they will have two completely different configurations for the WSUS environment. WDS and WSUS will happily co-exist on the same system. I have WDS and WSUS running together. To migrate your existing WSUS environment to the current WDS server, the easiest methodlogy is simply to install a new WSUS role on the WDS server as a replica, and replicate from your existing WSUS server (which will transfer all updates, groups, approvals, and content). When the replication is completed, reconfigure the server as an upstream server, synchronize, verify normal operation, and point the clients to the new server. If the WSUS URL is configured via GPO, you should see all of the clients registered/reported to the new server within a couple hours of updating the GPO.
  14. This is correct. There is no need to configure Configuration Manager clients using Group Policy, because the ConfigMgr Agent will configure the Software Updates options via Local Policy. However, there are a couple of exceptions to this. If you will be using Local Publishing (SCUP, Secunia, SolarWinds), then there is a policy setting that needs to be enabled, Allow signed updates from an intranet Microsoft update service location. This setting can be enabled via Group Policy, Local Policy, or Configuration Manager 2012 settings. There is also a second option that some ConfigMgr experts recommend setting, and that is the setting Configure Automatic Updates to DISABLED. However, there are a couple of considerations with this: 1. Setting this option to disabled prevents the WUAgent from selfupdating. Historically, a functional Windows Update Agent was available as a standalone installer, and ConfigMgr environments could build packages to deploy the WUAgent outside the scope of selfupdate. However, the latest version of the Windows Update Agent is only available via selfupdate, so this option can no longer be functionally disabled, unless it is known that all WUAgents are at the current version. 2. The reason for setting this to disabled, arguably, is to prevent the client from scanning Automatic Updates. However, there are other policy settings that are expressly designed to prevent a client from scanning Automatic Updates and those settings should be used for achieving that specific objective. If you're using Configuration Manager 2012, and need the local publishing setting, I would suggest doing that via ConfigMgr settings management, and keep the entire software updates configuration structure outside of Group Policy.
×
×
  • Create New...