wilbywilson

I ended up having to do a wipe and reformat on this Windows 8.1 laptop. Not 100% sure what the issue was, but I guess WMI, even though it was a relatively new build. After re-installation of the O/S, the Software Center works.

Are you pushing out software updates through SCCM? If so, might I suggest that you deploy IE11 (KB2841134) through the Software Updates mechanism? Your SCCM console will show you which machines need IE11, and you can just deploy the version that's applicable to IE11 for Windows 7 x64. If you deploy it through Software Updates, you can also set the deadline for 4 days (or whatever you need), and the user can install it at their discretion, up until the deadline.

Hi John, Thank you for your report. I'm sorry to hear that you're having issues. I'm always wary of "patching the patch infrastructure", because if something goes wrong, the entire environment could be affected. On the WindowsUpdate.log that you pasted above, what is the operating system on that machine? I see that it's already at Windows Update Agent version 7.6.7600.320, which I believe is the latest release (depending on the O/S). Do you have any machines that are still at 7.6.7600.256? Is their behavior the same? I think the first step would be to try and find the common ground. For instance, are all machines in the environment having issues checking in for updates? Or just certain operating systems? If it's just certain operating systems, what version of the Windows Update Agent do they have? Hopefully that will get you on the right track. I think for now, I'm going to hold off on applying KB2938066. Microsoft should hopefully be putting out more information on troubleshooting/fixing, when/if things do go wrong with this patch.

In this month's list of updates, Microsoft came out with new patch for WSUS servers (3.0 and above.) In a "normal" WSUS environment, updating the main WSUS server would then automatically/gradually update all of the managed clients to the latest Windows Update Agent. But in an SCCM environment, most of us have disabled Automatic Updates per best practice recommendations, and the updating of the client WUA version needs to be done via some other method. This blog goes into more depth on that scenario: http://blog.configmgrftw.com/the-wua-dilemma-in-configmgr/ My question is, has anyone applied KB2938066 to their WSUS servers yet? If so, are your SCCM clients still checking in and getting Windows updates without any issues? I don't think we're ready to update the Windows Update Agent version on our clients (currently 7.6.7600.256) throughout the environment at this point. I want to make sure that if I update the main SCCM/WSUS server, I don't create some sort of "mismatch", where the clients wouldn't be able to receive updates (until they get the newer Windows Update Agent at a later time.) My Primary/SCCM server is Windows 2012 R2, fully patched as of last month. Just not sure if I should include KB2938066 with this month's updates. Thanks for any advice.

Morris, What you are seeing is "normal" behavior. Unless your SCCM Primary/Management Point server is publicly accessible (with all of the necessary firewall ports open), then your client machines will not be able to access it from outside the network. If you need to be able to manage machines over the internet, then you're going to need to install and configure an Internet Management Point, likely located in a publicly accessible Datacenter/DMZ. Please read this post for more info, but what you are trying to accomplish requires additional set up, and unfortunately it's not that simple: http://www.systemcenterdudes.com/internet-based-client-management/

From my understanding, no. I don't use the Application Catalog heavily, but I believe that an administrator would need to login to the SCCM console and specifically look for any new software requests. I'm told that there are 3rd-party addons, that will make this whole request/approval process smoother. I don't know the specific names of those add-ons, but someone else that uses this piece of the product could probably tell us some options.

Yes, per my original post, we've completely uninstalled and re-installed the SCCM client a few times, with no improvement. I'm sadly beginning to think that we need to do a complete wipe and reformat on this particular machine.

Yes, App Catalog is configured and works on all machines, except for this particular Windows 8.1 client. Part of the reason I'd really like to figure this out, is that I'm in the beginning stages of my SCCM 2012 deployment, and I'm not sure if this same error will crop up on additional machines. But if it does, I'd like to be able to resolve it (without a wipe and reformat.)

Thanks for the tip, Peter. I've attached the SCClient_device@user.log. I don't want to attach the entire CCMSDKProvider.log, because it's got sensitive info, but here are a couple lines from that log file that look problematic: Failed to get method for DeviceId. Return code: 0x80041002 Retreiving Application Catalog URL from Client Agent Config Making call to get portalUrl from MP. Failed to get method for retreiving Application Catalog URL. Return code: 0x80041002

1) I don't think there will be any "effects", IF they've got the firewall and ports configured securely. It's not a conventional setup, but it could work if it's locked down properly. Best practice would be to have the Primary residing in the domain, and if your client needs to be able to manage machines over the internet, they can set up an internet MP in the DMZ (ideally in a separate domain.) 2) I don't believe that ICMP is required, so no bad effects that I'm aware of. 3) I'm sure there are others that have it set up like this, but you've REALLY got to trust your firewall, ports, and DMZ security. It's a risk. Check out this post for a recommended way to set up an internet MP: http://www.systemcenterdudes.com/?p=193

We've got a Windows 8.1 laptop where the SCCM 2012 R2 client appears to be successfully installed, but it's not able to open the Software Center. If you try to open it, you get this message: "There is a problem loading Software Center. Loading Software Center returned error code 0x80041002 (-2147217406)." We've tried to completely uninstall the SCCM client, reboot, and reinstall. Same behavior. This is a relatively new machine, and I doubt that WMI is corrupted. Any ideas? Which log files might indicate what the problem is?

We are in the process of migrating machines into a new domain, which already has SCCM 2012 configured. Shortly after migrating a machine, it will show up in the SCCM 2012 console (via AD System discovery ). From that point, we can highlight it, and push down the SCCM 2012 client. Usually this happens quickly, but in a couple of cases its taken some extra time. That potential/initial delay isnt that big of a deal in my opinion; the big issue is that the SCEP client does not always come down promptly after the main client installation. I configured SCEP according to Microsoft recommendations: its not part of the default SCCM client settings, its part of a separate/custom SCCM client setting. We have SCEP policies for laptops, desktops, VMs, servers, etc. Each of those policies is associated with an SCCM collection. So, the issue is that when a machine gets the SCCM client, it then has to run software/hardware inventory, and report back to the MP. From there, it will join itself to the proper EndPoint collection, and subsequently get the SCEP client and correct SCEP policy. This is all working; its just taking a while (a few hours, or sometimes the next day), and in the interim, clients have no anti-virus installed. (The machines previously had an anti-virus software called Vipre, and we are removing Vipre with a script right before we push down the SCCM client. Unfortunately, SCEP 2012 cannot automatically remove Vipre when it installs itself. So unless we want 2 anti-virus programs running at the same time, we need to remove Vipre beforehand.) So, we are mostly worried about that interim period. Especially for laptop users that may leave the office with the SCCM client, but not necessary with SCEP, if they havent got the SCEP client/policy delivered to their machine yet. I guess that we could manually add each machine to the appropriate EndPoint collection (the SCEP client *does* come down very quickly if we do that), but that is a manual step, and were trying to automate things as much as possible. Does anyone have an suggestions on how we can make this as smooth as possible, without exposing the clients to that interim period where they have no anti-virus software?

In SCCM 2007, you can simply alter the collection that the advertisement points to. (In SCCM 2012, you would have to recreate the advertisement freshly. There are plusses and minuses to both approaches. I think the main concern is that your reports/logs could be somewhat flawed if you just switch around where the advertisement points to. For instance, if you were working on building/testing the app, and it initially failed on a bunch of machines, those failures would be retained in your logs if you just point the original advert to a new collection. Whereas if you create a new advert, the reports on success/failure start "fresh." This isn't even an issue in many environments, but in some businesses, the managers want to see accurate success/failure reports.)

HHancock, Here is a post on this topic: http://social.technet.microsoft.com/Forums/systemcenter/en-US/2b767836-56cf-4f6f-bda2-e44acdb43b26/4037-error-when-testing-mpcert-mplist?forum=configmgrgeneral As Peter suggests, your machine may not be using the correct certificate when browsing to the url, but that doesn't necessarily indicate that there's a problem. From that link above, "if you're seeing 'Call to HttpSendRequestSync succeeded for port 443 with status code 200, text: OK' in your mpcontrol.log as per my screenshot above, that's a good sign the MP is functioning correctly." So, check out your mpcontrol.log, and see what you've got.

Hi Iroqouiz, While you can specify in the OCT that previous versions of Office should get uninstalled, it is *NOT* a clean upgrade. In Office 2010, there is a piece called "SharePoint Workspace". In Office 2013, there is no equivalent SharePoint software. Therefore, Microsoft has designed the OCT to not uninstall SharePoint Workspace (I guess in case someone still needs that piece.) So, after the upgrade, you'll have Office 2013, and Office 2010 SharePoint Workspace and associated Office 2010 Tools. Also, if you've already got Lync 2010 in your environment, that was not included in the Office 2010 suite. However, with Office 2013, Microsoft decided to include Lync 2013. So, we need to find a way to remove Lync 2010, and my only thought is that it needs to be uninstalled before the upgrade, because the OCT will not automatically upgrade/uninstall Lync 2010. So, due to the changes between Office 2010 and Office 2013, the OCT does not take care of some of these pieces, and we're having to jump through hoops to get a "clean" upgrade.

I don't know if I have an answer, but at least for your PXE clients, the platform settings shouldn't matter at all. A lot of people (including me) set the OSD task sequence to only be available for a strange Windows platform that does NOT exist in our environments (like Vista x64 SP1). This is done so that uninformed end users don't accidentally image their system from within the Config Manager Software Center. It essentially forces an IT person to PXE boot the machine, type in the password and and select the task sequence to start the OSD process. So, while that doesn't solve your issue, I don't believe your problem is related to platform requirements. Do you have another Distribution Point with PXE enabled? Does the same problem exist there?

I had a thread going the other day on this forum, which discussed a bug with superseding applications that were referenced in an optional Task Sequence. I want to report that I think this bug may extend beyond that scope. I'm working on an Office 2013 application, and I want it to supersede Office 2010. I added in the supersedence settings earlier today, and targeted an "optional" deployment to a small set of machines. I clicked on the Office 2013 application manually (via the Software Center) on a couple of machines to test it, but I also noticed on a couple of other machines that in the Software Center, the Office 2013 application was showing as "Past Due - will be updated". This is an *optional* deployment, and I certainly don't want machines to automatically upgrade. I want this type of deployment to be manually triggered, at the end user's time preference. I believe that Office 2013 would have tried to deploy itself at the next maintenance window to these machines (that had Office 2010 installed), had I not just removed the supersedence settings from the application. One point of debate are the proper choices in the actual supersedence menu. Obviously you choose the old application that you want to supersede, but there is also a selection for "Replacement Deployment Type." Here, you can select either "Do not replace", or you can select the new application. I chose the new Office 2013 application based on another blog I was reading, but perhaps "Do not replace" would have resulted in different behavior (not "forcing" existing clients with Office 2010 to update themselves at the next maintenance window?) Does anyone have in-depth experience with superseding applications? What is the difference between "Do not replace", and selecting the new application? Can supersedence work with "optional" deployments?

I'm working on building an Office 2013 application in SCCM 2012 R2, and due to the way that Office 2010 was rolled out in this corporation, I can't do a simple "upgrade." I am having to do a complete "uninstall" of Office 2010, following by the installation of Office 2013. I am using the Supersedence tab in the Office 2013 application, and I'm telling it to uninstall Office 2010 (I made an SCCM package for Office 2010, just so that we could do an uninstall of it.) For the most part, it seems to be working. However, after the uninstallation of Office 2010, the machine reboots itself. When it comes back up, the Office 2013 install does *not* resume itself automatically. I have to go into the Software Center, and click on "Install" again. Right now, this is an optional application, as opposed to required. Is what I'm seeing normal? Would any behavior change if I made it "required"? I'd obviously prefer if the installation of Office 2013 kicked itself after the machine reboots, as opposed to having to go back into the Software Center and "force" it to continue. Thanks for any input.

Thanks for the info, simulacra75. I figured that was the case, but I wanted to check with the forum, because I'm about to deploy a bunch of DP's.

Peter, Can you expand on that last part (bug while using supersedence for an application which is used in any optional task sequence?) I am using 1 optional task sequence, where I'm deploying Windows 7 to "All Unknown Computers", and I've integrated MDT 2013 with the UDI wizard, and it has optional applications in that task sequence. Thanks for your advice. It almost sounds like I'd be better off creating a regular "package" for this, as opposed to an "application."

Peter, Thanks for the reply. I do see that "Dependencies" tab, but I'm not sure that will work in this instance, because I'm not trying to check for the presence of another application. I'm trying to call an uninstall program from another package. Are you suggesting that the "Dependencies" tab will be able to handle an application uninstall? Maybe I'm just not thinking about things correctly...

I used to select the "Run Another Program First" option frequently in SCCM 2007. Now we're using SCCM 2012 and Applications (not packages), and I can't find this option any longer. The scenario is that we are planning a rollout of Office 2013. Due to some existing Office configurations already out there, I can't just "upgrade" it with the new package. I first have to uninstall the Office 2010 suite, using a separate SCCM application. But I can't figure out how to call that Office 2010 uninstallation from within my Office 2013 application. I don't see anything like "Run another program first" in the SCCM 2012 Application settings. Am I missing something? Thanks for any advice.

Sisko, One possible solution: Your log says "failed to run script msiexe.exe" There could be a typo there, because it's msiexec.exe (with a "c") Potential typos aside, I have been through similar trials with other software. My first step is to Google for support documentation from the vendor. Most vendors will have a PDF that explains all of their installation options and syntax. Failing that, I would contact the vendor directly, and ask them for recommendations on silent installations. Good luck.

I know that the SCCM Primary/Management Point needs full rights to the Systems Management container. But what about machines that are just serving as Distribution Points? Do they also need rights to the Systems Management container? Thanks!

I'm running SCCM 2012 R2 CU1, with a standalone Primary. The Primary has WSUS installed, but the actual SUS database lives on a separate SQL server (which also holds the main SCCM database.) It looks like SCCM 2012 has some nice new features which automatically remove expired and superseded patches from the SCCM console. It also appears that if you "edit the membership" of an expired patch, and remove it from any associated software groups, the files are subsequently removed from any distribution points with that package. But I believe that the WSUS "source" files on the main Primary server still remain. I know that people say not to mess with the WSUS console (only configure the SUP settings within the SCCM console), but I know there is a Cleanup Wizard in there, and that would likely get rid of the source files and permanently remove expired/superseded updates, if you ran it. So, what is the recommended best practice here? Are people running the WSUS cleanup wizard periodically? If my SUS database lives on a remote SQL server, would that cleanup routine even work for someone in my scenario? Thanks for any recommendations. I'm not having any performance issues right now, but I'd like to keep things running tightly.