MagnumVP

If we add a new server and keep the primary, are we able to decommission the server or does it have to stay running....forever!!!!? The end goal is to remove the server not keep it running.

The server is on an older server box (Single Proc with 8GB RAM, 36GB HD). Originally it was only going to be used for testing but the more they used it the deeper they got in and the deeper. They are wanting to use it in a more productive manner (software deployment, Windows Deployment, etc...) I didn't create the problem, I'm just here to fix it. Would it be easier to spin up the new server, join the existing site and then remove the old server?

We currently have a single 2012 R2 SCCM server with a single site that is soon to be retired. We are going to spin up a new server and install and configure the new SCCM 2012 R2. Once it's configured what do we need to do to migrate the clients (about 500) to the new server?

I guess I should have looked first. After going to https://technet.microsoft.com/en-us/security/bulletin/dn602597.aspxand searching SQL... I guess those are the only updates available. To be honest I'm kind of impressed that there isn't anything more. Kudos... If there was a way for me to put DUH... over this post I would. Sorry to bother.

I have configured Software Update to sync SQL 2005, 2008 and 2012 within the Software Update.I then performed a Sync of the updates from Microsoft Servers. I then attempt to perform a search for all SQL updates by searching for the term "SQL" However, it shows nothing since August of 2014. It also doesn't show any patches for Exchange, just Roll-Ups... but for now I'm looking into SQL hoping it will fix both. Products Selected Class Selected Sync Successful - wsyncmgr.log Nothing Appears

We have 7 locations. Each location has a 10Mb link between the the primary site where SCCM 2012 is located. Each site contains about 30-50 workstations/servers running Windows 7/8/2008/2012. - WSUS and Software Update Point is located at the central location. - Distribution Points are located at each site. - Clients all point to the single server located at the primary site. A GPO is NOT configured since it would conflict with the settings pushed out by the client. Do I need a separate Software Update Point and/or WSUS installation at each site or will the Distribution Point take care of the software/patches/updates that WSUS detects are needed?

Thank you.

We are running Exchange 2010 within a DAG and was curious if there was a method within SCCM to monitor for events for failures? We would like to be notified if one of the DAG members fails or the DB is moved/mounted to a different server.

Looking over these log I see some interesting errors and I'm wondering if these are erroneous errors. Question. If the network is configuring ALL Workstations/Server to point to the primary SCCM server, do the remote servers/sites need to have the Software Update Point installed? Currently all remote servers/sites have a Distribution Point where the clients can pull their updates from, but do those sites need to have the WSUS installed as well?

Here is what I see in the wsyncmgr.log "Sync failed: WSUS server not configured. Please refer to WCM.log for configuration error details.. Source: CWSyncMgr::DoSync" In the corresponding WCM.log file I see; System.Security.SecurityException: Request for principal permission failed.~~ at Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer(Object[] args)~~ at Microsoft.SystemsManagementServer.WSUS.WSUSServer.ConnectToWSUSServer(String ServerName, Boolean UseSSL, Int32 PortNumber)~~The Zone of the assembly that failed was:~~MyComputer I have verified that both IIS and SCCM are pointing to 8530.

We had an Admin that "Accidentally" uninstalled the WSUS, settings and DB from the SCCM 2012 R2 Server. After reinstalling the WSUS server, settings and DB with the same settings, nothing is syncing with the SCCM 2012 R2 software updates group. When refreshing the "All Software Updates" it only shows the updates from December 2014 and nothing from January. Is there a way to "re-link" SCCM with WSUS or do I have to reconfigure all the groups again from scratch? The original setup of the Software Update Service were followed using the Step-By-Step guides on this site.

The actual data. Our WAN connection comes to a crawl on the second Tuesday of the month the entire day.

How can I configure the updates that are pulled down on the 2nd Tuesday to start the replication after hours?

I have followed the Step-By-Steps for most of the process of setting up our SCCM environment. We even used the script to create the software updates groups. We currently have the SCCM 2012 client deployed to all computers in our domain. All clients are then set to pull from their local Distribution Point. Each site has a Software Update Point and the Distribution Point located on the same server. I have read that I need to "Disable" Windows Automatic Updates through a GPO to all clients that are controlled through the SCCM client. When doing this the client receives a "pop-up" message to configure WAU which allows them to change the time and settings. http://blog.configmgrftw.com/software-updates-management-and-group-policy-for-configmgr-cont/ However, the walk-through show that we need to point the clients to the WSUS server by configuring a GPO and then ENABLE WAU.http://www.windows-noob.com/forums/index.php?/topic/5683-using-system-center-2012-configuration-manager-part-5-adding-wsus-adding-the-sup-role-deploying-the-configuration-manager-client-agent/ Do I Enable or Disable WAU through a GPO? Do I configure the WSUS Server for each client to point to their local WSUS server? I'm assuming that if the SCCM 2012 client is controlling it then it doesn't matter what the GPO says as the local GP settings will apply.

We have clients and servers that are not detecting the updates they need. When I go to the client and manually run the scan for Updates against the local WSUS is shows nothing needed. When I run the scan against Microsoft Online the workstation/server needs updates. When I compare what is needed to what is downloaded/deployed SCCM shows that the server doesn't need the update. The WSUS shows the last sync time as yesterday as scheduled to. I have verified that the clients are part of the deployment rule but the rule shows 0.0% compliance. I'm comparing a particular patch that it shows that the system needs.

Since SCCM 2012 now has a x64 client, what's the best method to deploy the client to the workstations? I want to make sure the x64 client gets installed on the x64 client and the x86 gets installed on the 32bit client. In the past I have deployed the client.msi found under the i386 directory to all computers through a GPO. However, it's only the 32bit version. Should I remove the GPO install and use the Push Installation through SCCM? Will that install the appropriate version onto the client? Of should I push out the 32bit client install and then allow the SCCM server to upgrade to the appropriate version...if that is even possible.

The Client is updated to 5.00.7958.1401

http://support.microsoft.com/kb/2994331 Issues that are fixed Software distribution and application managementContent distribution from a Central Administration Site (CAS) to remote distribution points can take longer than expected. This can occur when multiple applications are updated across all distribution points. An application that is deployed to a collection is not removed from the software center if the computer is removed from that collection. The Export Application Wizard finished with errors when the source contains nested sub-folders, and the content is updated. Errors that resemble the following are displayed in the Export Application Wizard: Error: The target file "C:\Export\A_files\Content_XXXXXXXXXXXX\F2" is a directory, not a file. Changes to the CIEnforceState value for an application are not saved on the client when an immediate restart is initiated outside Configuration Manager. This scenario affects applications and application dependency chains in which the application has the following option enabled: Only when no user is logged on / CM client will force a mandatory device restart Wake on LANWake on LAN requests from a site server to a client may time out in large environments of 30,000 or more clients. MigrationThe data collecting process may time out when Configuration Manager is migrated from Configuration Manager 2007 to System Center 2012 R2 Configuration Manager. This issue can occur in sites in which multiple source sites are used, and many (100,000 or more) records exist only in the database at the destination site. Company portalClients may not configure settings for the company portal for sites in which multiple Application Catalogs are installed. Entries that resemble the following are logged in the UpdateTrustedSites.log file: Updating metro app setting with package family 'Microsoft.CorporateAppCenter_8wekyb3d8bbwe', URL ' HRESULT=80004005Failed to set settings into container 'PolicySettings\CCMSettings' of package 'Microsoft.CorporateAppCenter_8wekyb3d8bbwe'. Administrator ConsoleThe Administrator Console can quit unexpectedly when modifying the following task sequences:Join a domain or workgroup Apply Network Settings Mobile devicesPolicy assignment is not updated a Windows Embedded Handheld device is moved from one collection to another. For example, when a device is moved from a collection for installing an application to an uninstall collection, a rules conflict status occurs. Entries that resemble the following are recorded in the SMS_DM.log file: Uninstall AppPolicy is in conflict with other Install AppPolicy. Bailing out without Processing A race condition may cause renewing the Windows Intune Connector certificate to fail. Entries that resemble the following are recorded in the DMPDownload.log: Renewing connector certificate... Failed to call SaveAccountInfo. error = Unknown error SMS_DMP_DOWNLOADER is exiting... The Simple Certificate Enrollment Protocol policy may not be delivered to a device that is enrolled in Windows Intune and then later renamed by the user. State messages are marked incorrectly as corrupted from Simple Certificate Enrollment Protocol Configuration Items that are targeted to devices and that contain a user entry of SYSTEM. Simple Certificate Enrollment Protocol certificate requests can fail for workgroup clients that Configuration Manager manages. Entries that resemble the following are recorded in the CRP.log file: DB returned NULL. Parameters in CSR and DB do not match Exception: System.ArgumentException: DB returned NULL.Parameters in CSR and DB do not match Operating system deploymentWhen an unknown x64 UEFI computer is started by using PXE in a Configuration Manager 2012 R2 environment, the x86 Unknown Computer object is used incorrectly instead of the x64 Unknown Computer. This can potentially cause the computer to receive incorrect task sequences. ClientThe SMS Agent Host service may quit unexpectedly during the processing of task sequences. Site servers and site systemsThe SMS_Executive service may quit unexpectedly when removing a package from a large number (100+) of distribution points. Entries that resemble the following are logged in the distmgr.log file before process termination: Wait failed while waiting for all DP threads to end. Thread Count = 94, Error = 87 Distribution Manager tried 100 times, it will exit now Note These log entries do not always indicate a problem state that will lead to a process termination. Changing the properties of a distribution point on a Windows Server 2012 R2 server can disable date and time logging in Internet Information Services (IIS). Changing the properties of a distribution that was migrated from Configuration Manager 2007 to System Center 2012 R2 Configuration Manager can result in the upgrade process starting again. Windows PowerShellWindows PowerShell issues that are corrected in Cumulative Update 3 are described in the following article: 2999304 Description of Windows PowerShell changes in Cumulative Update 3 for System Center 2012 R2 Configuration Manager Additional changes that are included in this update Management point communicationsThis cumulative update introduces a new registry entry for clients. This entry will restrict which management point (MP) a client can communicate with. This can be useful in environments that have multiple MPs in different forests, and the clients can only communicate with a subset of them. Setting the registry value to only those MPs that can be reached by the client can improve overall efficiency. The new registry value is AllowedMPs, a REG_MULTI_SZ (multi-string) type that is under the following subkey: HKEY_LOCAL_MACHINE\Software\Microsoft\CCM Each entry is the Fully Qualified Domain Name of the management point(s) with which the client is able to communicate. This value does not affect the selection of any other site systems such as distribution points, software update points, and so on. The value only affects the primary site MP selection. Note After this value is defined, there is no fallback or other method for clients to communicate with other MPs. This new entry is only intended for permanently located workstation and server clients and is not portable to devices such as mobile PCs or tablets. Operating systems other than WindowsThe following operating systems are added to the list of supported platforms for software distribution:Debian 7 (x86) Debian 7 (x64) Red Hat Enterprise Linux 7 (x64) CentOS 7 (x64) Oracle 7 (x64) Software updatesChild sites may perform partial WSUS synchronization when the primary is under heavy load. This partial synchronization occurs when the WSUS Synchronization Manager component on a primary site begins synchronization before WSUS has completed processing all updates metadata. To prevent this scenario, the following registry subkey can be configured to use a new value in seconds: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Components\SMS_WSUS_SYNC_MANAGER\SyncGracePeriod The default value is 120 seconds, and values between 5 seconds and 10 minutes (5 and 600) are accepted. This setting should not have to be changed in most environments.

Thank you. I'm sorry I wasn't more clear. Yes that is what I was referring to. I wanted to make sure that the content would be located in the DP and not a UNC location on a local server.

We just ordered a dozen to distribute to our field reps. This is going to tremendous help. Thank you

I have deployed SCCM R2 CU1 to all clients (5.00.7958.1303) and the client does upgrade. However, not all the components follow suit. Is that normal?

We have a single SCCM 2012 Site and 6 borders. Each boarder has it's only software unc that is unique to that location where local software can be deployed from. (i.e. \\site1dfs\software or \\site2dfs\software...etc) Is it possible to deploy an application to a particular AD site that pulls from the local UNC?

We have 6 different sites where we have configured a Distribution Point at each location. At each site we have the clients point to the local Distribution Point server to get their Windows Updates. This is done through Group Policy. Does that server also need to have WSUS installed if the clients are going to point to that computer?

I have installed R2 CU2 and was looking to Enable Automatic Client Install through the Server. However, it still doesn't show the updated client version. It still shows version from SP1 (non R2) when it should be showing 5.00.7958.1303. I have distributed the packages and deployed them and it won't update. Is there another method to update the server version to push out the correct client? The server where deployments occur show 5.00.7958.1203 (CU1).

It's actually 64 updates since February Patch's Tuesday. I'm going to go through the process again and make sure I didn't forget something. The Step-By-Steps here are helpful (screens are a bit different in R2 CU1) but it gets the job done. Thanks for the assistance.