lt.son

I'm not using any filters, just searching for all updates released in the last 1 month. Nothing is found.

Thanks for the replies. I've been traveling for work and have just now started looking back into this. here are the pertinent errors (I think) wsyncmgr.log Wakeup for a polling cycle Starting Sync Performing sync on retry schedule Read SUPs from SCF for __server.sub.domain.com__ Found 1 SUPs Found active SUP __server.sub.domain.com__ from SCF File.~ STATMSG: ID=6701 SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_WSUS_SYNC_MANAGER" SYS=__server.sub.domain.com__ SITE=TSM PID=3428 TID=6968 GMTDATE=Wed Jan 04 09:10:06.799 2017 ISTR0="" ISTR1="" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0 Sync failed: WSUS server not configured. Please refer to WCM.log for configuration error details.. Source: CWSyncMgr::DoSync STATMSG: ID=6703 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_WSUS_SYNC_MANAGER" SYS=__server.sub.domain.com__ SITE=TSM PID=3428 TID=6968 GMTDATE=Wed Jan 04 09:15:06.917 2017 ISTR0="CWSyncMgr::DoSync" ISTR1="WSUS server not configured. Please refer to WCM.log for configuration error details." ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0 Sync failed. Will retry in 60 minutes WCM.log Checking for supported version of WSUS (min WSUS 3.0 SP2 + KB2720211 + KB2734608) SMS_WSUS_CONFIGURATION_MANAGER Checking runtime v2.0.50727... SMS_WSUS_CONFIGURATION_MANAGER Failed to create assembly name object for Microsoft.UpdateServices.Administration. Error = 0x80131701. SMS_WSUS_CONFIGURATION_MANAGER Checking runtime v4.0.30319... SMS_WSUS_CONFIGURATION_MANAGER Found supported assembly Microsoft.UpdateServices.Administration version 4.0.0.0, file version 6.2.9200.16384 SMS_WSUS_CONFIGURATION_MANAGER Found supported assembly Microsoft.UpdateServices.BaseApi version 4.0.0.0, file version 6.2.9200.21848 SMS_WSUS_CONFIGURATION_MANAGER Supported WSUS version found SMS_WSUS_CONFIGURATION_MANAGER Attempting connection to WSUS server: __server.sub.domain.com__, port: 8530, useSSL: False SMS_WSUS_CONFIGURATION_MANAGER Successfully connected to server: __server.sub.domain.com__, port: 8530, useSSL: False SMS_WSUS_CONFIGURATION_MANAGER Verify Upstream Server settings on the Active WSUS Server SMS_WSUS_CONFIGURATION_MANAGER System.IndexOutOfRangeException: Index was outside the bounds of the array.~~ at Microsoft.UpdateServices.Internal.BaseApi.SoapExceptionProcessor.DeserializeAndThrow(SoapException soapException)~~ at Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccessProxy.ExecuteSPGetConfiguration()~~ at Microsoft.UpdateServices.Internal.BaseApi.UpdateServerConfiguration.Load()~~ at Microsoft.UpdateServices.Internal.ClassFactory.CreateWellKnownType(Type type, Object[] args)~~ at Microsoft.UpdateServices.Internal.ClassFactory.CreateInstance(Type type, Object[] args)~~ at Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetConfiguration()~~ at Microsoft.SystemsManagementServer.WSUS.WSUSServer.SetUpstreamServerSettings(Boolean SyncFromMicrosoftUpdate, Boolean ReplicaServer, String UpstreamWSUSServerName, Int32 UpstreamWSUSServerPortNumber, Boolean UseSSL, Boolean HostBinariesOnMU, Int32 ReportingLevel, Int32 MaximumAllowedComputers) SMS_WSUS_CONFIGURATION_MANAGER Remote configuration failed on WSUS Server. SMS_WSUS_CONFIGURATION_MANAGER STATMSG: ID=6600 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_WSUS_CONFIGURATION_MANAGER" SYS=__server.sub.domain.com__ SITE=TSM PID=3428 TID=6936 GMTDATE=Tue Jan 03 15:52:23.576 2017 ISTR0="__server.sub.domain.com__" ISTR1="" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0 SMS_WSUS_CONFIGURATION_MANAGER Waiting for changes for 60 minutes SMS_WSUS_CONFIGURATION_MANAGER and WSUSmgr.log Timed Out...~ Checking for supported version of WSUS (min WSUS 3.0 SP2 + KB2720211 + KB2734608)~ Checking runtime v2.0.50727...~ Failed to create assembly name object for Microsoft.UpdateServices.Administration. Error = 0x80131701.~ Checking runtime v4.0.30319...~ Found supported assembly Microsoft.UpdateServices.Administration version 4.0.0.0, file version 6.2.9200.16384~ Found supported assembly Microsoft.UpdateServices.BaseApi version 4.0.0.0, file version 6.2.9200.21848~ Supported WSUS version found~ Attempting connection to local WSUS server Successfully connected to local WSUS server System.IndexOutOfRangeException: Index was outside the bounds of the array.~~ at Microsoft.UpdateServices.Internal.BaseApi.SoapExceptionProcessor.DeserializeAndThrow(SoapException soapException)~~ at Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccessProxy.ExecuteSPGetConfiguration()~~ at Microsoft.UpdateServices.Internal.BaseApi.UpdateServerConfiguration.Load()~~ at Microsoft.UpdateServices.Internal.ClassFactory.CreateWellKnownType(Type type, Object[] args)~~ at Microsoft.UpdateServices.Internal.ClassFactory.CreateInstance(Type type, Object[] args)~~ at Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetConfiguration()~~ at Microsoft.SystemsManagementServer.WSUS.WSUSServer.SetProxySettings(Boolean UseProxy, String ProxyName, Int32 ProxyServerPort, Boolean AnonymousProxyAccess, String ProxyUserName, String ProxyUserDomain, String ProxyUserPassword, Boolean AllowProxyCredentialsOverNonSsl) Failed to set WSUS Local Configuration. Will retry configuration in 1 minutes~ Attempting connection to local WSUS server Successfully connected to local WSUS server Errors were reported in these WSUS Server components WSUSService, on WSUS Server __server.sub.domain.com__~ Failures reported during periodic health check by the WSUS Server __server.sub.domain.com__. Will retry check in 1 minutes~ ~Waiting for changes for 1 minutes

How do you have your site boundary groups laid out? We have each boundary group assigned to a subnet, then the local DP is assigned to that boundary group. This causes the clients to be pointed to their local DP.

Hello all, On Tuesday afternoon I searched for the new updates and nothing showed up. I figured I might be too early so I went about my business. This morning (Thursday) I searched and it still finds no updated released in the last month. I searched the last 2 months and it found the November Rollups that have already been deployed. Last month in our monthly maintenance window we updated to CU4. Could that be the problem? I have not heard of any issues regarding CU4, although it's still early in it's release. I am not even sure where to look to see why it's not finding the latest updates.

Hello all, I hope I can lay this out clearly so someone can understand what's happening here and help out. We've had OS Deployment working for a couple of years now with no real issues. We have about 30 offices nation wide. We have a single Site and a Distribution Point at each location. The DPs are PXE enabled. They are all virtualized except two, which are located IN ADDITION to the primary DP VMs in our two largest offices. Both of these locations have multiple subnets. They both had speed issues on day one when we enabled OSD. After much troubleshooting and trying every suggestion we tried, we finally got "regular speed" by installing a physical DP on the subnet that the local IT staff were on. Two weeks ago we upgraded the WAN circuits in the 2nd office. We replaced the router and all switches. Because this location now houses our disaster recovery site, we rejiggered the network and added a new subnet that is now where all the clients are located. Now we have the same issue we had when we setup OSD. It took over 30 hours to image a single system. We have moved the physical DP to the new subnet, but PXE is not working now. I can get PXE working, so I'm really curious about the slow deployment across subnets in the same office. Our setup: HQ, 31 Subnets, virtual Site Server & DP, physical DP** on ITs subnet 31 remote offices with a single subnet and VM DP 1 remote office with 3 subnets a VM DP and a Physical DP** on client subnet ** Without 2nd DP imaging takes more than a day.

Ahh, Thanks for the suggestion. I hadn't realized that I could specify something to run BEFORE a App install. I'll look into it. That's the uninstaller I tried to script into the phantom package. Anyway, I believe the issue is fixed. I found the package ID and cleaned it off of all our DPs. This morning it is gone.

This is how it had worked in the past. However, starting in about September, the old versions stopped uninstalling. We were finding systems with multiple versions of the ActiveX Flash Player installed.

Yes, we were following a suggestion that we create a package with a script that first uninstalls all versions of flash, then installed the current (at the time) version.

We created a package to remove all versions of Flash Player then install the latest. This didn't work well so we removed the package. That package is still trying to install and failing. This is what I've found in the client logs: AppDiscovery.log +++ MSI application not discovered [MSI Product Code: {44CF4DB9-707A-4395-839C-573FBC206CB9}, MSI Product version: ] +++ Did not detect app deployment type Adobe Flash Player 19 ActiveX - Windows Installer (*.msi file)(ScopeId_E653C22A-B113-4E94-B3BD-D84F9569E225/DeploymentType_97dd432f-2731-48a8-8aa1-00537c377eaa, revision 1) for system. ActionType - Install will use Content Id: Content_2d063820-6587-4d5c-91a2-d8945f7e5e5a + Content Version: 1 for AppDT "Adobe Flash Player 19 ActiveX - Windows Installer (*.msi file)" [scopeId_E653C22A-B113-4E94-B3BD-D84F9569E225/DeploymentType_97dd432f-2731-48a8-8aa1-00537c377eaa], Revision - 1 I'm not sure from here how to locate the ghost of this package and eliminate it. Thanks, LT.Son

willisj318, Were you able to resolve this issue? If so, how? I have a package trying to install on all clients. The deployment was deleted, but it is still there trying to install.

Thanks anyweb, SQL is installed on another server in our setup. Not sure why... I found two old captured images that are no longer being deployed that were about 12GB each. There are also ISOs for XP and Pre SP1 Win7. I have not found anything in the SCCM console that refers to any of them. Is it simply a matter of deleting them out of their folders in the \Source\OSInstallers subfolder? The largest chunk of space (38% per WinDirStat) is used by very large files in \SCCMContentLib\FileLib. I'm assuming these are our application deployments all packaged up.

Our SCCM 2012 SP1 server has run out of disk space. We can not add more space at this time. We are budgeted for more hardware in Q3 of 2016, but we have no options until then. The SCCM server was originally installed by a consultant. He setup a file structure as so: \Source Main share ----------\Applications ----------\Drivers ----------\OSInstallers ----------\Updates In the Updates folder we have a folder structure for downloading our monthly updates \2015\01 --------\02 etc. Is it OK to delete these folders? It is my understanding that the update packages are copied from here. Others say these downloads ARE the files in use by deployments. What is the correct answer?

Sorry to dredge up an old topic. We recently started receiving this error on our SCCM 2012 SP1 system. MP File Dispatch Manager cannot copy files from "C:\SMS\MP\OUTBOXES\rdr.box" to "\\<server.domain>\SMS_TSM\inboxes\auth\ddm.box\regreq". This thread, and the answers I've found through Googling all say to fix permissions on the outbox or inbox, or to CREATE the outbox or inbox. However, there is no C:\SMS folder structure on our SCCM server. Our setup was installed by a consultant, and he recommended against installing SCCM2012 on the C: drive, so he created a small C: and a large E:\ that SCCM is installed on. I see no E:\SMS folder structure either. So my questions are: Is it a good idea to try and create this folder structure manually? Shouldn't SCCM know where it's inboxes / outboxes located?

It was my understanding that all remote sites needed a SUP to cache and install updates locally. I'm guessing this is not the case?

Yesterday we found that one of our DPs was not receiving packages, so we started digging around to find out why. In the process I discovered that the DP did not have the Software Update Point role installed. "Great!" Nobody who has access has admitted making any changes to the system, of course. Are there any known issues that might cause DPs to "loose" installed roles? I also discovered 2 DPs that no longer had the State Migration Point and Component Server roles installed. I didn't think a DP could exist without the Component Server role... Is there a bigger problem I need to be looking for in our system? Configuration Info: Single Site Server 27 Distribution Points deployed to remote locations DPs all configured with Site System, Component Server, Distribution Point, State Migration Point, and until recently Software Update Point. Please let me know if you need more details. Thanks, LT.Son

Now that the last of the 2014 Software Updates are out, I want to clear out SCCM and setup just a few Update Groups. We've had SCCM for just over a year, and there was a problem early on with people having access that they shouldn't. There are update groups with who knows what in them. Some have updates for every version of Windows possible, every Office update for every version. I think someone even setup updates for languages I can guarantee are not deployed in our environment. One of the problems is the 500GB allotted to our SCCM server is full already. 1) How do I go about clearing out all these unwanted update groups? 2) How do I remove the unwanted files in the SOURCE$ directory? 3) What is the best practice for rolling all the years critical updates into a single Group/Deployment? 4) Am I making any sense with my questions?

<bump> Sorry to bump my own topic, but I'm still unable to figure this one out.

Installation of the DP went fine. The logs show that everything worked fine. The SCCM folders were created. The DP server shows up in the console. Trying to distribute content to the new DP fails with the following errors: ERROR DPConnection::ConnectWMI() - Failed to connect to Office-DP.domain.com. error = 0x800706ba Cannot establish connection to ["Display=\\Office-DP.domain.com\"]MSWNET:["SMS_SITE=TSM"]\\Office-DP.domain.com\. Error = 53 Failed to make a network connection to \\Office-DP.domain.com\ADMIN$ (0x35) CWmi::Connect() failed to connect to \\Office-DP.domain.com\root\MicrosoftIISv2. Error = 0x800706BA The Site server is local admin on the machine. From the site server I can open \\Office-DP\Admin$ , and D$ (SCCM drive) and create folders and copy data. From the link below, I thought maybe the WMI namespace for SCCMPD was not created on the DP, so I ran mofcomp.exe smsdpprov.mof to create it http://silentcrash.com/2013/09/error-0x800706ba-when-trying-to-install-new-distribution-point-in-sccm-2012-sp1/ What am I missing? Thinking it was a problem with this location, I setup another DP in a different location and am having the same issue with it. I think I must be missing a step somewhere, but can't for the life of me think what it might be. Thank you, LT.Son