DaveP

I found an interesting entry in my replicationlinkanalysis.log that shows BCP being sent for both replication groups 'Configuration Data' and 'Asset Intelligence Knowledge Base', but something happens where they aren't being received by the Primary site.

I recently installed a new Primary Site for one of our branch offices, and replication is stuck in a state of 'being configured'. Most Replication Groups with a Data Type of 'Global' seem to have replicated over to P02; save for two 'Asset Intelligence Knowledge Base' and 'Configuration Data' that have held steady at 41% for over two days. Running spDiagDRS on my SQL database shows the status of these two Replication Groups is set to 'Initializing' This link below summarizes the issues I've been having, but there are some important differences. I have three separate SQL databases running locally on each server. My SQL Server service broker port is the same on all three sites, but I don't see how an incorrect SSB port configuration could explain the global data replication that completed successfully, prior to it freezing. http://social.technet.microsoft.com/Forums/en-US/43566705-d330-4b0d-8375-57f54590d166/3-sccm-sites-with-multiple-db-instances-on-sql-server-not-replicating?forum=configmanagerdeployment

I managed to get all 180 updates injected, and verified the integrity of the .wim by running PXE. Everything looks good. Even though I've been unable to find the exact cause of my errors, albeit a slow process, this is a viable workaround.

I'm currently testing a workaround. I select roughly 50 updates at a time and watch the OfflineServicingMgr.log file. I'll wait until the first failure and select only the successful updates from the log file for a second attempt at updating the .wim. I then repeat this process over and over again; eventually including the updates that had failed during a previous scheduled update run. I'll let you all know if this ends up being a viable workaround.

I've been having problems injecting drivers into my install.wim file successfully using scheduled updates. The failures seem to happen at completely random intervals, and it doesn't appear to be caused by any specific update in particular. For example, a security update with ID 1837 might be the first update to fail during a scheduled update attempt, and then install fine upon a second attempt. I have found a few interesting entires in my OfflineServicingMgr.log and disk_sccmAMD64.log however, and I was hoping I could get some clarification on a few things. 1. (Review OfflineServicingMgr1.png) After the first driver install failure, there are many rampant errors proceeding that point in my OfflineServicingMgr.log file, and you end of looking at a sea of red. The first install error is always ErrorCode = 5. Every failure beyond that is ErrorCode = 2096. I made note of the exact time of the first install error in my log and opened my dism_sccmAMD64.log 2. (Review DISM1.png) You can see an E_ACCESSDENIED and an ERROR_FILE_NOT_FOUND at the same time offline servicing broke during the scheduled updates. Thinking it's a permissions issue, I ran a search for KB2691442 (referenced in the OfflineServicingMgr1.png before the first failure) on the C:\ drive of my primary site server to see what I could find. The results of my search all pointed to C:\Windows\Servicing\Packages (Directory.png). It would be helpful if anyone could provide information on the relevance of this directory and whether or not this is the location offline servicing is looking in when it's attempting to install a selected update. 3. (Review DISM2.png) It appears that DISM is smart enough to recognize that an update failure damages the image. I assume all subsequent errors in my OfflineServicingMgr.log (ErrorCode = 2096) can be attributed to this. This is also why it's good to deselect 'continue on error' when running scheduled updates. All that being said, I'm not convinced it's permissions, despite the access denied error I received. That doesn't explain why 50 updates will fail to install during a scheduled update, and then those exact same updates will install successfully on a seperate attempt. Scratching my head on this one...

Fixed! Added the 'Local Service' account with permissions to the Windows\Temp directory. All is good.

Repairing the .NET Framework 4.0 yielded a new error when accessing the application catalog. I was getting prompted for a username and password each time and eventually would get a 401.1 permissions error. Only way I knew how to fix it was to remove and re-add the roles again and I'm back to where I started with the catalog unable to connect to the application server.

I removed both application roles, renamed the CMApplicationCatalog and CMApplicationCatalogSvc folders so they'd regnerate when adding the roles back. Made sure I ran the -i -enable commands for aspnet_regiis.exe in the Framework64 folder for both v2.0 and 4.0. I ran the the .NET Framework veification tool and successfully discovered 3.5 and 4.0. I added the application roles back using all the default settings for http. After the CMApplicationCatalog and CMApplicationCatalogSvc directories generated I browsed the application catalog and it's still giving me the same 'Cannot connect to application server' error. The only thing I can think of is that there's an issue with .NET Framework somewhere. Removing and re-adding the 3.5 features last time did nothing to solve my problem. So either I need to use the .NET Removal tool and install the standalone packages or try running a repair on 4.0. I attempted to do this with the .NET repair tool, but it failed, so I have my suspicions. I'll try and run a repair on it through add/remove programs and keep my fingers crossed.

I 3.5.1 features had been added via Server Manager Console. I ran the -i enable command on 4.0.

SMS_PORTAL_WEB_CONTROL_MANAGER is only showing one log entry in the last twenty four hours. Message ID 500 - "This component has started", and I'm seeing a lot of 1015's when going back further. SMSAWEBSVCSetup.log shows WCF and IIS is activated and installed. Also shows that the installation of SMSAWEBSVC was successful. SMSPORTALWEB.log is looking almost identical to SMSAWEBSVCSetup.log. I'm seeing a lot of the same success messages. No error messages. awebsvcmsi.log is showing "Product: Application Web Service -- Installation operation completed successfully", and "Windows Installer installed the product. Product Name: Application Web Service. Product Version: 5.00.7804.1000. Product Language: 1033. Manufacturer: Microsoft Corporation. Installation success or error status: 0." portalwebmsi.log looks almost identical to awebsvcmsi.log. I have the agent set to automatically detect the application catalog website point under default settings.

So I've been working on this problem for the last three days or so and if there's a thread out there I haven't yet read on the issue then I'd be surprised. So I thought I'd try here to see if anyone could help. From all the logs I've looked in I'm unable to find a problem. Everything looks to have installed correctly. The bindings and connection strings look good. Uninstall/Reinstalling roles and features yields no results. I did notice something a little 'off' in my Site properties under the 'Ports' tab. For 'Active Ports' I see that 'Client Requests-HTTP (TCP)' and HTTPS is listed twice. Only one pair is checked and set to the default ports. The other pair is unchecked and has no assigned port numbers. Assigning the same port number to unchecked ports goes unsaved. Anyone else see this before?

So I discovered if I set the 'Installation behavior:' field to 'Install for user' instead of 'Install for system', the application deployment works. Which is strange, as I'm installing all my applications using the same service account, which is a domain admin on the network and thus an administrator on all machines.

Application: Modelogix3.1.306.0.exe Purpose: Available Issue: When attempting to install the Modelogix application from within Software Center, the application install fails and results in a, "The software change returned error code 0xFF(255)" status. AppEnforce Log Data: App enforcement environment: Context: Machine Command line: Modelogix3.1.306.0.exe /s /f1"\\stlfilep01\configmgr\Applications\Modelogix\recordsettings" /f2"\\stlfilep01\configmgr\Applications\Modelogix\Modelogix.log" Allow user interaction: No UI mode: 1 User token: null Session Id: 1 Content path: C:\WINDOWS\ccmcache\c Working directory: AppEnforce 8/13/2013 8:05:59 AM 3440 (0x0D70) Prepared working directory: C:\WINDOWS\ccmcache\c AppEnforce 8/13/2013 8:05:59 AM 3440 (0x0D70) Prepared command line: "C:\WINDOWS\ccmcache\c\Modelogix3.1.306.0.exe" /s /f1"\\stlfilep01\configmgr\Applications\Modelogix\recordsettings" /f2"\\stlfilep01\configmgr\Applications\Modelogix\Modelogix.log" AppEnforce 8/13/2013 8:05:59 AM 3440 (0x0D70) Executing Command line: "C:\WINDOWS\ccmcache\c\Modelogix3.1.306.0.exe" /s /f1"\\stlfilep01\configmgr\Applications\Modelogix\recordsettings" /f2"\\stlfilep01\configmgr\Applications\Modelogix\Modelogix.log" with user context AppEnforce 8/13/2013 8:05:59 AM 3440 (0x0D70) Working directory C:\WINDOWS\ccmcache\c AppEnforce 8/13/2013 8:05:59 AM 3440 (0x0D70) Post install behavior is BasedOnExitCode AppEnforce 8/13/2013 8:05:59 AM 3440 (0x0D70) Waiting for process 4936 to finish. Timeout = 120 minutes. AppEnforce 8/13/2013 8:05:59 AM 3440 (0x0D70) Process 4936 terminated with exitcode: 255 AppEnforce 8/13/2013 8:06:01 AM 3440 (0x0D70) Looking for exit code 255 in exit codes table... AppEnforce 8/13/2013 8:06:01 AM 3440 (0x0D70) Unmatched exit code (255) is considered an execution failure. AppEnforce 8/13/2013 8:06:01 AM 3440 (0x0D70) Event Viewer Log Data: Faulting application name: Modelogix3.1.306.0.exe, version: 3.1.306.0, time stamp: 0x51a6cc99 Faulting module name: ISSetup.dll, version: 20.0.0.376, time stamp: 0x51a6cc32 Exception code: 0xc0000005 Fault offset: 0x0001ab47 Faulting process id: 0x1394 Faulting application start time: 0x01ce9826a56e998f Faulting application path: C:\WINDOWS\ccmcache\c\Modelogix3.1.306.0.exe Faulting module path: C:\WINDOWS\TEMP\{B057E27D-B11B-4CD1-90B0-9149D8324421}\Disk1\ISSetup.dll Report Id: e726df53-0419-11e3-af22-f01faf2ac4fd Event ID: 1000 Troubleshooting: From the command prompt on any machine I can run the executable from the same directory, using the same response file, log file directory, and the application installs fine. I have another application where I use Install Shield Parameters. I had make a small edit to folder permissions so the .log file could be written out to the share for that application. I've applied those same permissions to the Modelogix directory. I attempted to add the 255 return code into the Modelogix Properties as a 'Success (no reboot)'. UAC is turned off.