wilbywilson

Perhaps check out this post for some ideas: http://social.technet.microsoft.com/Forums/en-US/1490752c-effc-49ed-8d47-1901fc6c1151/sccm-2012-r2-adr-issue-with-proxy-authentication?forum=configmanagergeneral Also, I believe I read that someone else on this forum had this issue, and a simple reboot "fixed" it.

Are the XP machines and the Windows 7 machines part of the same collection, where the maintenance windows are being enforced? I guess what I'm asking is, is there a single maintenance window covering all of these machines? Or do you have a collection/maintenance window for Windows 7 machines, and a separate collection/maintenance window for Windows XP machines? If they are separate, you may want to double-check the maintenance window configuration for the XP machines, since it doesn't sound like they adhering to it.

Well, if you use the MSI (when available), it should create its own detection method when you're going through the application build wizard. If you're building an application from an EXE file, then you'll need to create your own method. In those cases, I generally try to detect the presence of the main .exe (chrome.exe for instance), and the file version for that particular release. That way, you can be sure it's detecting the exact Chrome version that you're trying to deploy, and not some potential old/outdated chrome file. And if you uninstall the program, that .exe should definitely be removed from the machine. That seems to be working pretty well for me. I did run into one instance where I had an x86 and x64 version of an app, and the main .exe for that program ended up in the same path on the end user machine, regardless if it was an x86 or x64 machine. Of course, that detection rule didn't work so great, since it though the clients had both the x86 and x64 version of the software installed. In that case, I added a second piece to each detection rule, where it looked for a text file that was specific to the x86 application, and likewise for the x64 application.

In your deployment, are you allowing it to reboot during maintenance windows? There are checkboxes there, where you can specify reboot behavior. I would start by checking those settings...

Yes, it's possible to manage remote clients. However, you're going to need: 1) a PKI infrastructure (clients will communicate over HTTPS) 2) a firewall/TMG solution to allow remote access over the proper ports 3) the firewall/TMG can potentially be bypassed, if you install an internet management point in the DMZ Check out this post, to see what you're getting into. I recently went through this process, and it's not easy. A Standalone Primary instance will work: http://www.systemcenterdudes.com/?p=193

You can also try using the Adobe Customization wizard (http://www.adobe.com/support/downloads/detail.jsp?ftpID=5515) What you're looking for really isn't a function of SCCM 2012, rather it's tied to how your package is originally created.

Thanks for the idea, Jorgen. You've put me on the right track now.

The way we have our SCCM 2012 R2 infrastructure configure is for EndPoint Protection to be installed if a machine is in a certain device collection. For instance, we have a "Endpoint Protection Laptops" collection, which queries for all laptop chassis types, and if a machine gets itself into that collection, it gets EndPoint protection installed with the custom laptop policy. Same thing with desktops, querying for the desktop chassis type, which then gets the desktop custom policy. But how are people handling VMs? It wouldn't be hard to query for VMs, but some of our VMs are Windows 7, some are Windows Server 2008/2012, etc. I wouldn't want the same endpoint protection policy to apply to all VMs, because they have different roles. Is it best practice to manually assign the VM to the Endpoint Protection device collection that it should be in? Or is there some query/strategy that I'm overlooking? Thanks

Are you using Automatic Deployment Rules to make these updated "required?" If so, it sounds like something in those ADRs is not configured properly...

I wanted to ask a follow up on this topic, because this seems to unfortunately be a common issue. I've read numerous accounts in these forums about end users accidentally installing an O/S through the Software Center, without understanding what they are doing. Is there a bug in SCCM, where the Task Sequence shows in Software Center, even if you've set it for "Only Media and PXE?" In my case, I've made that "Only Media and PXE" setting, made sure it was only "Available" (not required), plus I changed it to run only on Vista x32 (which we don't have.) And I'm advertising it to the "All Unknown Computers" collection. I haven't seen the advertisement in any of my client's Software Centers, but I'm curious how it's happening in other environments. Are people not configuring it properly? Bug in SCCM?

If you go to your Task Sequence, right-click and go to its Properties. Then go to the "Advanced" tab. At the bottom, there is an option to "Run on any platform", or you can choose to "Run only on the specified client platforms." Choose something strange like "Vista" (or anything that does NOT exist in your environment.) Then it should never show up on your clients as an option...

Disregard this thread. I just realized that "normal" deployment of my Adobe application also doesn't create an Adobe folder on the Programs Menu. I guess I need to work with the Adobe customization wizard to get things the way I want them.

So I'm building my first SCCM 2012 R2 Task Sequence (integrated with MDT 2013). It actually seems to be working pretty well, with the exception that apps that I select from my customized UDI wizard are not correctly being put into the Start -> Programs menu. For instance, Adobe Pro is installed, and there are numerous Adobe icons in the Start Menu for Adobe Pro / Distiller / Forms / etc. But they are not in an "Adobe" specific folder; the shortcuts are just scattered all over the place. I would expect/hope these shortcuts would get placed directly into an "Adobe" folder on the Start -> Programs menu. Has anyone seen this behavior? Any recommendation on "fixing" it? Thanks!

Yeah, I would check for the existence of another (non-SCCM) PXE server on these 2 troublesome subnets.

My brain isn't that big, but I'm thinking you'll need to create multiple SAPGUI applications. For instance, SAPGUI English, with a dependency of Office 2010 w/ English language. And SAPGUI Chinese, with a dependency of Office 2010 w/ Chinese language. Make sense?

Hey there. Assuming that your clients are getting the correct certificates issued, the Config Manager client cert should say "PKI" So, I don't think you've got the certificate configured/distributing properly. I would highly recommend checking out this blog post: http://www.systemcenterdudes.com/?p=193

Hmmm....thanks for the reply Peter. Your response leads me to believe that I don't have my boundaries/boundary groups configured correctly. I'm still in the process of building out the SCCM 2012 environment here, but so far I am just using 1 Boundary Group, which contains 3 Boundaries (3 offices that each have a local Distribution Point. Each of these physical offices corresponds to a subnet in AD Sites and Services.) If I look at the "Site Systems" tab on any of the 3 boundaries, I see all 3 Distribution Points listed there. This makes me believe that a local client might use any of the 3 DPs, instead of *only* the local DP. But looking at my SCCM logs (so far), the clients seem to be smart enough to download files from the local DP, and not across the WAN. Should I be creating a boundary group for each AD Site, if I want to limit that particular office/subnet to a local DP? This is quite a bit different than what I remember from SCCM 2007...

Hmmmm...sorry to hear that happened. It is possible that Microsoft modified the IE11 update, and that's why it got put into your deployment? For instance, usually a new IE browser is listed as "optional" in the Windows Update catalog. Eventually (many months or a year later), Microsoft decides that the new browser version is "important" or "critical." I don't use ADRs for Windows Updates; I'm just thinking out loud here.

It sounds like the client machine may have the Windows Update in cache. On the client machine, go to Control Panel -> Configuration Manager. Then go to the "Cache" tab and click "Configure Settings." Delete the cache. Then I would manually force a "Software Update Deployment Eval Cycle" and a "Software Updates Scan Cycle" (from the Actions tab) on the client machine, to make sure that it doesn't try to install the update again.

APUG666, I believe that's "normal" behavior. I'll let others weigh in, but I'm doing the same thing as you are...

I have a couple of questions about SCCM clients that will exist in physical sites that unfortunately won't have a local distribution point. 1) Should I set up boundaries as normal for these small sites, but set them to "Slow"? 2) I realize that I can deploy some applications with the option to NOT download source files from a fallback point, thereby limiting the amount of WAN bandwidth that these "slow" clients can use. However, some deployments (monthly Windows updates for instance) are absolutely required, and I'll specify those deployments to download updates from fallback points. My question is, how does a "slow" client decide where to grab the source files from? Does it go straight to the Primary? Randomly picks another distribution point (the environment will eventually have 10-12 DPs)? Does it somehow use AD Sites and Services to find the closest DP? Thanks for any guidance on expected behavior and optimal configuration for sites that don't have local DPs.

I think that best practice is to *not* include all clients in the collection for OS deployment. Just add in clients *as needed*, and subsequently remove them from the collection after imaging. That way, you have helped to safeguard against unintentional imaging of machines. That is my take on the subject; others may disagree.

You may want to try using the "%~dp0" variable: http://www.windows-noob.com/forums/index.php?/topic/6919-environmental-variables-with-sccm/

It sounds like something may have happened with your Network Access Account. Did the account password potentially expire? Check out this post, which has very similar errors to your log: http://venusingireddy.blogspot.com/2013/08/401-authentication-failure-on-request.html

Within the SCCM 2012 console: Administration -> Client Settings From there, you'll see "Default Client Settings", or if you're using custom settings profiles, those will also show up. Look for "Client Policy" in those profiles. The default is 60 minutes, which should be adequate. Trying to crank that up too much could have ill effects on your network traffic.