Jump to content


Established Members
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by LawrenceGarvin

  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


    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.
  15. Yep. You need to install the WSUS role first. Cancel out of the setup wizard. Then configure the Software Update Point component in Configuration Manager. If there's no WSUS role installed on the target server, the SUP configuration attempt will simply fail (as WSUS is a prerequisite for a SUP). This basic procedure is not unique to CM2012SP1, it applies to any installation of ConfigMgr when configuring a Software Update Point. The only thing unique about the CM2012SP1 scenario is that it is required to use Win2012.
  16. Yes, you can use WSUSUTIL MOVECONTENT to relocate the ~\WSUSContent folder on any WSUS server, including those configured as a Software Update Point. However, on a SUP there is no useful value in doing so since the only thing stored in the ~\WSUSContent folder of a Software Update Point is: 1. Some text files that are the EULAs for certain updates. 2. Third-party updates that you've published from SCUP, Secunia, or SolarWinds. The steps, however, are identical in both scenarios. 1. Create the parent folder tree where you intend to move the 'WSUSContent' folder. 2. Run WSUSUTIL MOVECONTENT <parentDirectory> -l <logFile>
  17. The WSUS servers are not required on the secondary sites. The sole purpose of the WSUS server is to allow the Software Updates Agent to obtain the update metadata (detection logic) to determine the compliance state of an update. This compliance state is then reported by the CMAgent to the Management Point (MP). All updates are obtained from a Distribution Point. Your concern with bandwidth connectivity is a strong case for having Distribution Points in your remote sites. Whether a WSUS server in the Secondary Site will be of notable benefit really depends on the number of clients in those remote sites. The value in having a downstream SUP in Configuration Manager is to support sites with a large number of clients. If your sites have less than a hundred clients, you probably will not see sufficient value in the deployment of the downstream SUP to justify the expense of maintaining and administering it.
  18. Does "no configuration changes" also mean you've not patched the WSUS server? The remote certificate is invalid according to the validation procedure. This is the WSUS server attempting to initiate an HTTPS connection to do the synchronization. It's failing because the WSUS server has an expired or untrusted SSL certificate for Microsoft. The entire certificate infrastructure for the Microsoft WU system was replaced in June, 2012 (and through subsequent months and additional updates).
  19. Copying VHDs won't really work; you also need the entire Virtual Machine specification. Also if there are any snapshots or save files, that complicates it even more. Yes, theoretically you can build a new virtual machine definition and attach the VHD to the VM; but if there are any inconsistencies between the new VM definition and the old, related to how the OS/Drivers are configured in the installation on that VHD, you may create instabilities or dysfunction in the new instance. Since we're talking about a critical infrastructure machine (a DNS Server), the most reliable methodology is to export the virtual machine and let the system do the work for you.
  20. There shouldn't be. I recently migrated a Win2008R2 Server Core DC/DNS Server from a Win2008 SP2 Enterprise Edition Hyper-V server to a Windows Server 2008 R2 SP1 Datacenter Edition Hyper-V server and had no issues whatsoever. I exported the machine from hyperv1 and imported on hyperv2 and it fired right up.
  21. This really isn't a *WSUS* question, it's a "How to patch with Configuration Manager?" question, and you'll get a better technical answer if you post in the SCCM forum: http://www.windows-noob.com/forums/index.php?/forum/44-sms-2003-sccm-2007-sccm-2012/ However, from a general perspective, the answer is absolutely the same regardless of how a machine gets updated: Automatic Updates, Windows Update, WSUS, or SCCM. It's a very simple question: What updates are NOT INSTALLED? Those are the ones you should install.
  22. I'm not exactly sure I understand the context in which this question is being asked. First, *any* software product can be updated using Configuration Manager Software Updates if you build a package using System Center Updates Publisher. Second, there are, to my knowledge, only three software vendors have products who provide *content* to update applications using Configuration Manager. They are: VMWare vCenter Protect Update Catalog Secunia CSI SolarWinds Patch Manager While those vendors provide a differing list of products pre-packaged, ready for use, all three also provide the ability to package your own updates for applications not contained in their catalogs. NOTE: I am employed by SolarWinds.
  23. +1 on Peter's response. Moving an existing SQL Server in or out of a domain is a royal PITA, and successful endeavors of that type are rare. When installing, it is always appropriate to install SQL Server onto an existing domain-member machine. In fact, while SQL Server presents a very specific use-case, I would argue that any system intended to run applications should be joined to the domain prior to installing any applications.
  24. Generally speaking, the 0x80072EE7 code is a name resolution failure. This thread from the TechNet ConfigMgr OSD Forum may shed some light.
  • Create New...