IBCM Problems...

Tuesday, August 11, 2009 12:20 PM.Tim Harrison

0
Sign In to Vote
I had an issue where I needed to work on my certificate server a few days ago and after ironing out all the issues, I re-deployed certificates to most machines. One that I forgot to re-deploy until yesterday was the Site Server Signing Cert to the Central Site Server. Several machines had been imaged, talked to the MP at least long enough to download the Signing Cert and then sent to the field. I wasn't getting reports from any of the machines. I re-deployed a new signing cert to the Central Site server, but it seems to be causing problems with machines in the field downloaded the updated cert.

I have just deployed a handful of laptops with an IBCM-only configuration to the field and I'm only hearing back from a handful of them. These machines have a proxy configured in IE for internet browsing, but I wouldn't think that would affect the agent. On some machines I'm getting full reports, on others, I'm only getting software inventories and on others I'm getting them to show up in the collection, but when I go into resource explorer, I have no data. On my DMZ-based MP, for one of the machines that I'm getting a software inventory but no hardware inventory, under the MP_Status.log, I got one "SMS_ServiceHost_CertificateOperationsFailure" for it, a "DPBITSConfigDeleted", a couple "SMS_PolicyAgent_PolicyMismatch" events, then a bunch of "SMS_PolicyAgent_BitsPolicyDownloadFailed", and lastly another "SMS_PolicyAgent_PolicyMismatch" event.

For one of the machines that I've gotten nothing from, at first I had a bunch of alternating "SMS_RemoteClient_SiteSigning_AuthFailure_Trust" and "SMS_PolicyAgent_PolicyAuthorizationFailure" events, but now I'm just getting a bunch of "SMS_PolicyAgent_BitsPolicyDownloadFailed" events and one "SMS_PolicyAgent_PolicyMismatch" event.

All of the machines I'm having problems with are showing up in the MP_Status.log on the DMZ MP with either the "SMS_PolicyAgent_BitsPolicyDownloadFailed" and/or "SMS_PolicyAgent_PolicyAuthorizationFailure".

Thanks in advance.
- Reply
- Quote

Answers

Thursday, September 03, 2009 6:12 PMBrian Huneycutt [MSFT]MSFT

0
Sign In to Vote
To one of the earlier notes in the thread - the details of the proxy configuration (.pac versus .js) are transparent to the ConfigMgr client - from a code perspective we don't take that into account, we just try to establish a connection.

There's also no exact formula for what could cause one aspect of client communications to work and another to fail.
For the policy download issue, more investigation from the BITS / network side may be warranted but is unfortunately outside the scope of a forum post.
I too suggest opening a support case if you haven't already for further assistance in sorting out what's going on and why - the final outcome of which could also be posted back to this thread as needed.
Thank you,
Brian
- Marked As Answer byCarol BaileyMSFT, ModeratorThursday, September 03, 2009 9:07 PM
- Reply
- Quote
Wednesday, November 04, 2009 2:58 PM.Tim Harrison

0
Sign In to Vote
After a lot of research and painful trial and error, I found "the glitch". Apparently, when the Microsoft people tell you that "the System Center client uses whatever proxy settings are in IE", they don't mean that it actually uses and reads a proxy auto-configuration script. What system center does is essentially perform a proxycfg -u command and use whatever settings come back. If those settings are invalid, you will get the error of, "ErrorMessage = "BITS error: 'The supplied proxy server or bypass list is invalid.\n' Context: 'The error occurred while the remote file was being processed.\n'" in your PolicyAgent.log file. If you see this, ensure that the manually specified proxy bypass list under Internet Options -> Connections Tab -> LAN Settings -> "Advanced" under Proxy Server -> Exceptions is a valid list. This list can only contain entries such as http://www.domain.com or *.domain.com - there can be nothing following the ".com" part or it will be considered invalid.

Thanks
- Marked As Answer by.Tim Harrison Wednesday, November 04, 2009 2:58 PM
- Reply
- Quote

All Replies

Tuesday, August 11, 2009 12:46 PMCarol BaileyMSFT, Moderator

0
Sign In to Vote
Tim, since you redeployed the site server signing certificate - does the following apply to you? (from http://technet.microsoft.com/en-us/library/bb680839.aspx)

Native Mode Clients Become Unmanaged When They Use a New Site Server Signing Certificate
If a Configuration Manager 2007 client uses a new site server signing certificate that chains to a different root certificate than was used with the previous site server signing certificate, the client will not accept the new site server signing certificate when it receives policies signed with the new certificate.

This will occur if the root certificate for the site server signing certificate changes from the client's point of view—for example, in the following circumstances:
- If you move a Configuration Manager 2007 client from one Configuration Manager 2007 hierarchy to another (for example, a company merger).
- If you configure the site to use a new site server signing certificate from a different root certification authority than the one that issued the previous site server signing certificate.
- You renew your root certificate with a new key pair and then issue a new site server signing certificate.
This behavior provides security prevention against clients accepting a new site server signing certificate from a compromised management point. In this scenario, clients will not attempt to download the new site server signing certificate and will reject the policy they have downloaded, sending an error to the management point to alert the administrator to the fact that policy authorization failed.

Solution

Either delete the copy of the previous site server signing certificate on the Configuration Manager client, or uninstall or reinstall the client.

For more information about this scenario and remedial actions, see Renewing or Changing the Site Server Signing Certificate.
- Reply
- Quote
Tuesday, August 11, 2009 12:52 PM.Tim Harrison

0
Sign In to Vote
Carol,

I did have to renew the root cert, but I believe all these machines were imaged at the same time and all have the same trusted root cert. The wierd thing is that some work and some don't. The other oddity is that, if I turn off the proxy in Internet Options -> Connections -> LAN Settings, the client immediately connects and downloads policy. Do the IBCM clients use IE policies for any kind of certificate checking?

Thanks
- Edited by.Tim Harrison Tuesday, August 11, 2009 1:12 PM
- Edited by.Tim Harrison Tuesday, August 11, 2009 1:13 PM
- Reply
- Quote
Tuesday, August 11, 2009 1:51 PMCarol BaileyMSFT, Moderator

0
Sign In to Vote
They can use the proxy Web server settings in IE. From http://technet.microsoft.com/en-us/library/bb693755.aspx

Specifying the proxy Web server details as a Configuration Manager property means that computers remain managed even when users are not logged on. However, if the proxy Web server settings are not specified as a Configuration Manager property, Configuration Manager client computers will try the following proxy Web server discovery methods to connect to the specified Internet-based management point:
1. The proxy Web server settings configured in the default browser
2. The system context
3. The currently logged-on user's credentials
- Reply
- Quote
Tuesday, August 11, 2009 2:23 PM.Tim Harrison

0
Sign In to Vote
OK, so just for clarification, if my IBCM machines have a proxy script specified in their Internet Options -> Connections -> LAN Settings area, and this has not been configured for the client, the agents will authenticate and show up in my collection, but they will not ever download policy.

If https://cm.domain.com is not specified as a "safe" address in the proxy auto config script, would it cause this kind of behavior? Where the laptops authenticate but won't download policy?

If I need to specify proxy settings for the clients at installation, is there a command-line switch to do so? I don't see one on this page: http://technet.microsoft.com/en-us/library/bb680980.aspx

**EDIT**

OK, I really don't understand now - I have re-configured the proxy script to allow *.domain.com* so https://cm.domain.com should be included in that. I am able to open IE and actually navigate to https://cm.domain.com and it says "Under Construction" as it always has. It still isn't downloading policy and its showing the "SMS_PolicyAgent_BitsPolicyDownloadFailed" error on the MP. The ideal scenario, I guess, would be a way for me to tell the agent to ignore the IE proxy settings and just connect normally. We only use a proxy script to restrict the websites our internet machines are able to access to corporate sites only.
- Edited by.Tim Harrison Tuesday, August 11, 2009 2:42 PM
- Edited by.Tim Harrison Tuesday, August 11, 2009 3:22 PM
- Edited by.Tim Harrison Tuesday, August 11, 2009 3:10 PM
- Edited by.Tim Harrison Tuesday, August 11, 2009 3:21 PM
- Reply
- Quote
Tuesday, August 11, 2009 3:31 PMCarol BaileyMSFT, Moderator

0
Sign In to Vote
I'm afraid I don't have knowledge of exact symptoms if IE settings prevent this from working - so you would either have to do some testing on this yourself to verify, or specify the proxy server details that work in the client properties.

The proxy server is one setting that you can't specify on the command line at installation but it is supported with the SDK, using the SetProxy Method. I don't use the SDK myself but when I asked for relevant links, I was given these:

Configuration Manager Client Configuration (a couple of generic examples)
http://msdn.microsoft.com/en-us/library/cc145296.aspx

SetProxy Method
http://msdn.microsoft.com/en-us/library/cc143274.aspx

Hope this helps.

- Carol

This posting is provided “AS IS” with no warranties and confers no rights
- Reply
- Quote
Tuesday, August 11, 2009 4:01 PM.Tim Harrison

0
Sign In to Vote
Is there any way that you know of to simply tell the client not to use IE proxy settings, but to just connect as if there were nothing configured for IE?
- Reply
- Quote
Tuesday, August 11, 2009 4:36 PMCarol BaileyMSFT, Moderator

0
Sign In to Vote
No - I'm afraid it's hardcoded to try proxy server settings in the order documented if client properties are not specified.
- Reply
- Quote
Tuesday, August 11, 2009 5:02 PM.Tim Harrison

0
Sign In to Vote
so would you say that config manager is simply incompatible with .js or .pac automatic proxy configuration scripts?

I just don't understand why it uses IE's proxy settings to try to download policy, but it doesn't use them to authenticate with the site server and download the site server signing certificate, etc.
- Reply
- Quote
Tuesday, August 11, 2009 5:51 PMCarol BaileyMSFT, Moderator

0
Sign In to Vote
No, it's designed to work with either browser settings or the configuration in the client properties. For the browser settings, it uses auto-discovery to find the proxy server first, and if this fails it then looks for statically defined settings for the proxy server. I'm not aware that there's anything additional that you need to configure for this to work and I don't understand why it would "half work" as you're seeing. This was tested by the product group, so I'll ask if we have any additional information that I'm not aware of that might explain your scenario.

- Carol

This posting is provided “AS IS” with no warranties and confers no rights
- Reply
- Quote
Tuesday, August 11, 2009 6:08 PM.Tim Harrison

0
Sign In to Vote
So it should work with a .js auto config script then. Yes, if you could give me a sample of the auto config script they used in testing, I would greatly appreciate it.

The one that was "half working" (giving software inventory but not hardware) was a fluke - none of the others are doing that. Unless you mean "half working" by their ability to authenticate but not download policy.

In case it helps, here's the format of our .js script.
```
function FindProxyForURL(url, host)
{
    var proxy_yes = "PROXY 10.10.10.10:8080";
    var proxy_no = "DIRECT";

    if (shExpMatch(url, "*.contoso.com*")) 
        { return proxy_no; }
    if (shExpMatch(url, "http://www.contoso.com*")) 
        { return proxy_no; }
    if (shExpMatch(url, "https://cm.contoso.com*")) 
        { return proxy_no; }

    return proxy_yes;
}
```
It will basically send the user "directly" to the sites we specify but have it go through a non-existent proxy server (10.10.10.10:8080) to get to anything else. Of course, since no proxy server exists at 10.10.10.10:8080 for Internet-based clients, their browsers just sit there until they time-out for any site other than those we specify.
- Edited by.Tim Harrison Tuesday, August 11, 2009 6:30 PM
- Edited by.Tim Harrison Tuesday, August 11, 2009 6:29 PM
- Edited by.Tim Harrison Tuesday, August 11, 2009 6:27 PM
- Edited by.Tim Harrison Tuesday, August 11, 2009 6:26 PM
- Reply
- Quote
Wednesday, August 12, 2009 11:58 AM.Tim Harrison

0
Sign In to Vote
I have another strange development - When I first install the client, with the proxy enabled, the client goes out to the DMZ MP, authenticates (its name shows up in the collection, I can see its IP address, etc.), and then tries to download policy for the first time. On the DMZ MP mp_status.log, I get one "SMS_PolicyAgent_PolicyMismatch" event followed by several "SMS_PolicyAgent_BitsPolicyDownloadFailed" and then it goes silent. If I turn off the proxy, reboot and then force a manual policy update on the client, it will get policy. Now the really weird part is that if I then turn the proxy back on, once it has downloaded policy for the first time, and make a policy change, the machine will get it. So its as if the machines are able to get so-called "delta" policies, but not the first, full policy.
- Reply
- Quote
Wednesday, August 12, 2009 4:03 PM.Tim Harrison

0
Sign In to Vote
Apparently the CM client doesn't like to use .js files. I copied the exact code from our proxy.js file to a proxy.pac file, uploaded it and voila - works perfectly.

Thanks.
- Unmarked As Answer by.Tim Harrison Thursday, August 13, 2009 4:13 PM
- Marked As Answer by.Tim Harrison Wednesday, August 12, 2009 4:03 PM
- Reply
- Quote
Wednesday, August 12, 2009 4:39 PMCarol BaileyMSFT, Moderator

0
Sign In to Vote
I'm pleased you managed to identify what was the issue because I've been really puzzled by this. Thanks for the update - I'll follow up with the product group so that they can investigate this limitation.
- Reply
- Quote
Wednesday, August 12, 2009 7:08 PMAdam Meltzer [MSFT]Moderator

0
Sign In to Vote
I'm surprised that .js files didn't work for you where .pac files did. Did you try the .js file in Internet Explorer and did it work?
- Reply
- Quote
Thursday, August 13, 2009 4:45 PM.Tim Harrison

0
Sign In to Vote
Adam - I have unmarked my post as the answer as it seems the machines are only sometimes reading the PAC file - not consistently - but ALWAYS read the .js file correctly. By this I mean I copied the exact same code to a PAC and IE will be blocked from the sites correctly but then I'll reboot and they wont, etc. I've gone back to the .js because everyone seems to think that should work and SOME machines in the field ARE reporting... with the exact same settings. I don't know why this is.

I looked into it a bit and found a setting called Automatic Proxy Result Cache that can be turned off (its on by default) that could have been causing problems. I followed THIS article to make the registry entry that turns this feature off. I'm testing right now...

Which logs would help me figure out whats going on here? I don't understand why I'm seeing some machines in the field report in successfully.
- Reply
- Quote
Thursday, August 13, 2009 5:21 PMAdam Meltzer [MSFT]Moderator

0
Sign In to Vote
What errors are you getting in the PolicyAssignments.log? If you're still getting BITS errors, what's in DataTransferService.log? Anything that would point to why BITS jobs are failing?

You can monitor the proxy configuration by looking at the InternetProxy.log file.

Are you going through an ISA firewall to get to your MP?
- Reply
- Quote
Thursday, August 13, 2009 5:36 PM.Tim Harrison

0
Sign In to Vote
1 - I don't see a PolicyAssignments.log in the Central Site Server, DMZ MP or client

2 - The InternetProxy.log file shows:

<![LOG[Couldn't find 'CCM_NetworkProxy' instance for protocol 'https'.]LOG]!>
<![LOG[Couldn't find 'CCM_NetworkProxy' instance for protocol 'http'.]LOG]!>
<![LOG[Couldn't find 'CCM_NetworkProxy' instance for protocol 'https'.]LOG]!>
<![LOG[Couldn't find 'CCM_NetworkProxy' instance for protocol 'http'.]LOG]!>
<![LOG[Failed to get logged on user token but will continue..., hr 0x800704dd.]LOG]!>
<![LOG[Couldn't detect proxy information for the URL: https://CM.<domain>.COM/ccm_system/request]LOG]!>
<![LOG[Couldn't find 'CCM_NetworkProxy' instance for protocol 'https'.]LOG]!>
<![LOG[Couldn't find 'CCM_NetworkProxy' instance for protocol 'http'.]LOG]!>
<![LOG[Failed to get logged on user token but will continue..., hr 0x800704dd.]LOG]!>
<![LOG[Couldn't detect proxy information for the URL: https://CM.<domain>.COM/SMS_MP/.sms_aut?MPKEYINFORMATION]LOG]!>
<![LOG[Couldn't find 'CCM_NetworkProxy' instance for protocol 'https'.]LOG]!>
<![LOG[Couldn't find 'CCM_NetworkProxy' instance for protocol 'http'.]LOG]!>
<![LOG[Couldn't find 'CCM_NetworkProxy' instance for protocol 'https'.]LOG]!>
<![LOG[Couldn't find 'CCM_NetworkProxy' instance for protocol 'http'.]LOG]!>
<![LOG[Couldn't find 'CCM_NetworkProxy' instance for protocol 'https'.]LOG]!>
<![LOG[Couldn't find 'CCM_NetworkProxy' instance for protocol 'http'.]LOG]!>
<![LOG[Failed to get logged on user token but will continue..., hr 0x800704dd.]LOG]!>
<![LOG[Couldn't detect proxy information for the URL: https://CM.<domain>.COM/SMS_MP/.sms_aut?MPKEYINFORMATION]LOG]!>
<![LOG[Couldn't find 'CCM_NetworkProxy' instance for protocol 'https'.]LOG]!>
<![LOG[Couldn't find 'CCM_NetworkProxy' instance for protocol 'http'.]LOG]!>
<![LOG[Couldn't find 'CCM_NetworkProxy' instance for protocol 'https'.]LOG]!>
<![LOG[Couldn't find 'CCM_NetworkProxy' instance for protocol 'http'.]LOG]!>

3 - I'm not going through an ISA firewall - I don't think - I have an MP/SUP/DP out on the DMZ that allows ports 1433/443/135/etc. back to the internal central site server.
- Reply
- Quote
Thursday, August 13, 2009 6:35 PM.Tim Harrison

0
Sign In to Vote
I have another strange development... I took the proxy.js file from our server, stripped the file extension and stuck it in the c:\windows\system32\drivers\etc folder and pointed the Internet Options to "file://c:/windows/system32/drivers/etc/proxy" and it works perfectly. IE acts no differently than before - it blocks what should be blocked and opens what should be opened. So the problem is only when the proxy script is on a web server and not stored locally. Any ideas?
- Reply
- Quote
Tuesday, August 18, 2009 12:17 PM.Tim Harrison

0
Sign In to Vote
So it seems machines are very slowly reporting back. I don't know why these machines are having such a hard time with the proxy script. Some machines, it seems, report right away and others take several cycles of "SMS_PolicyAgent_BitsPolicyDownloadFailed" and then finally connect. Is there any kind of limit to the number of machines that can be connecting/reporting at any given time?
- Reply
- Quote
Tuesday, August 18, 2009 8:05 PMCarol BaileyMSFT, Moderator

0
Sign In to Vote
Tim, I don't think we can help you any further with this problem. Adam assures me that we tested .js and .pac files and we always stress-test our product under simulated loads. I have asked that .js files are tested again but if the same file works locally for you and it was previously tested by us, I don't think waiting for that result is going to help here. It's almost as if there's an external configuration factor that we haven't yet identified - maybe something within IE as you suggested.

From the product group side, Adam & I both recommend that you open a support case for this, so that they can check specifics for your environment and perhaps delve into the IE configuration side more. I'm sorry that we can't help you further.

- Carol

This posting is provided “AS IS” with no warranties and confers no rights
- Reply
- Quote
Tuesday, August 18, 2009 8:10 PM.Tim Harrison

0
Sign In to Vote
Could someone please outline for me exactly what could cause machines in the field to successfully authenticate with the site server but not download policy? I need to get this fixed - I have about 2/3 of the machines deployed that aren't working right now. Every machine shows up in the All Systems collection and from it I get all kinds of data (last logged in user, workgroup name, computer name, ip address, MAC address, etc.) but the machines do not get policy so I don't get hardware/software inventory and I can't push anything to them. I repeatedly get "SMS_PolicyAgent_BitsPolicyDownloadFailed" errors for the machines that aren't reporting - I'll get about 15 of these errors in a span of about 2 minutes and then it stops. Eventually, some of them start working, but most do not. Could this be caused by some kind of certificate error?

I just need to know what possible problems could cause this because I need to get this fixed soon...

Thanks.
- Reply
- Quote
Tuesday, August 18, 2009 8:52 PMAdam Meltzer [MSFT]Moderator

0
Sign In to Vote
You can try to use the "bitsadmin" tool to get some ideas of why policy downloads are failing. More information is at: http://msdn.microsoft.com/en-us/library/aa362813(VS.85).aspx

The syntax you'll want to use is "bitsadmin.exe /list /allusers /verbose". This might give you some clues as to why policy downloads are failing.

Hope this helps!
- Reply
- Quote
Wednesday, August 19, 2009 2:02 PM.Tim Harrison

0
Sign In to Vote
would I run this on the DMZ server or a failing client?
- Reply
- Quote
Thursday, August 20, 2009 2:36 PMCarol BaileyMSFT, Moderator

0
Sign In to Vote
I'm afraid I have no knowledge about running this external tool and I have never seen a problem with symptoms that match these. So if it is urgent, I can only repeat my recommendation of opening a support case.
- Reply
- Quote
Thursday, September 03, 2009 6:12 PMBrian Huneycutt [MSFT]MSFT

0
Sign In to Vote
To one of the earlier notes in the thread - the details of the proxy configuration (.pac versus .js) are transparent to the ConfigMgr client - from a code perspective we don't take that into account, we just try to establish a connection.

There's also no exact formula for what could cause one aspect of client communications to work and another to fail.
For the policy download issue, more investigation from the BITS / network side may be warranted but is unfortunately outside the scope of a forum post.
I too suggest opening a support case if you haven't already for further assistance in sorting out what's going on and why - the final outcome of which could also be posted back to this thread as needed.
Thank you,
Brian
- Marked As Answer byCarol BaileyMSFT, ModeratorThursday, September 03, 2009 9:07 PM
- Reply
- Quote
Wednesday, November 04, 2009 2:58 PM.Tim Harrison

0
Sign In to Vote
After a lot of research and painful trial and error, I found "the glitch". Apparently, when the Microsoft people tell you that "the System Center client uses whatever proxy settings are in IE", they don't mean that it actually uses and reads a proxy auto-configuration script. What system center does is essentially perform a proxycfg -u command and use whatever settings come back. If those settings are invalid, you will get the error of, "ErrorMessage = "BITS error: 'The supplied proxy server or bypass list is invalid.\n' Context: 'The error occurred while the remote file was being processed.\n'" in your PolicyAgent.log file. If you see this, ensure that the manually specified proxy bypass list under Internet Options -> Connections Tab -> LAN Settings -> "Advanced" under Proxy Server -> Exceptions is a valid list. This list can only contain entries such as http://www.domain.com or *.domain.com - there can be nothing following the ".com" part or it will be considered invalid.

Thanks
- Marked As Answer by.Tim Harrison Wednesday, November 04, 2009 2:58 PM
- Reply
- Quote
Thursday, November 05, 2009 5:30 PMAdam Meltzer [MSFT]Moderator

0
Sign In to Vote
Tim, I'm glad you were able to isolate the issue and apologize for how much of an inconvenience it caused while you were investigating it.

It sounds like you may have found a combination of settings between IE settings, proxy autoconfig files, and possibly some other unknown conditions that has created a scenario where the proxy settings just don't work when processed by the ConfigMgr client. We put forward a lot of effort to test many different combinations of proxy settings in IE. This includes multiple Exceptions, proxy.pac and proxy.js autoconfig files, and many other different combinations of settings and never ran into the specific issue that you're seeing.

I want to make sure this issue is investigated by our engineering team so that we can get it addressed as either a QFE or in a future product release. If you could file an incident with CSS providing the necessary information to reproduce this issue, it would be very helpful to us and to other customers so they don't hit this issue as well.

Please let me know if there's anything I can do to help.

Thanks!

- Adam
- Reply
- Quote

IBCM Problems...

Answers

All Replies

Solution