From: admin@lists.myITforum.com [mailto:admin@lists.myITforum.com] On Behalf Of Jake Cohen
Sent: Tuesday, November 24, 2009 6:01 PM
To: mssms@lists.myitforum.com
Subject: Re: [mssms] Problem getting IBCM going

OK so here is the resolve!

First off, the Site Signing server certificate was left as is.  The OID information contained in the certificate is wrong but everything seems functional so I decided not to complicate things by swapping out the certificate.  This will hopefully be replaced shortly.

The Clients.  The solution was easy, albeit aggravating to find.  When on the client system (workgroup client with internet only connection) if you request a Client Authentication certificate from the CA (logged in as an admin) it doesn't work.  IF you launch the web browser you use to request the certificate under the context of the local system everything works like a champ.  The number of internet clients is low so we didn't have a chance to look into using something like certreq to request the certificate under the local system context but I suspect it would work fine.

Now as to why I had to request the certificates this way, I have no idea.  In all cases the little checkbox to store the certificate in the computer certificate store was checked.  If I ever figure out the underlying why I'll be sure to post it.  =)

-Jake Cohen

On Thu, Nov 19, 2009 at 9:25 PM, Jake Cohen <jakect@gmail.com> wrote:

Just putting all of the details I have back together in one place...

I've come in to help out with a SCCM 2007 site where there were a few problems left after the installation was completed.  Primarily I was called in to get Internet only workgroup systems installed as SCCM 2007 clients.  The site is already in native mode and there is a subordinate CA and an Internet MP residing in the DMZ.

 

Let's put the internet clients aside for a minute...

 

In trying to research why the internet clients won't install I found that the OID value entered into the CA template for the Site Server signing certificate is wrong, in fact I can't find the number anywhere on the internet.

 

I've followed this article to ensure that the other certificates are correct and that the Site Server signing certificate is wrong:  http://technet.microsoft.com/en-us/library/bb680733.aspx

 

I've also found this problem, and while the solution sounds workable I am not sure as I've never had to replace a signing certificate.  http://social.technet.microsoft.com/Forums/en-US/configmgribcm/thread/74abda47-33a0-4e0c-9516-eed2dc301ba5

 

So what will I run into when I replace the signing certificate with one that has the correct OID information in it?  Is it likely that this problem also is part of why I cannot get my internet based clients up and running?

 

 

 

Now back to the internet based clients...

 

I have the Site Server signing certificate exported so that I can include it with the client install for the internet clients.  Also, currently there are no clients installed and running as internet only.

 

Good news first.  We built a machine on the intranet and made it a part of AD, confirmed that the SCCM client was functional then moved the machine to the internet.  Once it was on the internet we initiated a HINV and verify that the inventory came back to the SCCM dB before we moved the system back to the intranet.  So we know that the MP is working, well at least to me that means the MP is working.

 

For the internet clients, we are manually requesting a Client Authentication certificate from the subordinate CA in the DMZ (via the /certsrv website), approving the certificate, then retrieving it from the website.

 

After the certificate is received we install the SCCM client using the following command via a batch file.

 

ccmsetup.exe /source:C:\mylocalfolder /native:CRL CCMHOSTNAME=INETMPFQDN.domain.com SMSSIGNCERT=C:\mylocalfolder\SiteSignCert.cer SMSSITECODE=XYZ FSP=INETMPFQDN.domain.com CCMALWAYSINF=1

 

Here are a few things that I've already found and corrected:

1.        The Subordinate CA did not have an internet accessible CRL or AIA, this was corrected and verified with Certutil - URL.

2.        The OID originally used for the internet client certificates was wrong, actually it was the same OID used for the Site signing certificates.

And here is what I have in log files...

 

IIS W3SVC1 log from the internet MP (i've only included the relevant entries for my test system):

 

2009-11-19 19:02:00 W3SVC1 10.100.1.21 GET /sms_mp/.sms_aut mplist 443 - 71.71.194.84 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1) 403 7 64
2009-11-19 19:13:43 W3SVC1 10.100.1.21 POST /SMS_FSP/.sms_fsp - 80 - 71.71.194.84 SMS+FSP 200 0 0
2009-11-19 19:13:59 W3SVC1 10.100.1.21 POST /SMS_FSP/.sms_fsp - 80 - 71.71.194.84 ccmhttp 200 0 0

 

 

ClientLocation.log

 

Client assigned to site 'XYZ' ClientLocation 11/19/2009 2:13:46 PM 316 (0x013C)

GetCurrentManagementPointEx ClientLocation 11/19/2009 2:14:02 PM 4008 (0x0FA8)

Current Management Point is INETMPFQDN.domain.com with version 0 and capabilities: . ClientLocation 11/19/2009 2:14:02 PM 4008 (0x0FA8)

 

 

ClientIDManagerStartup.log

 

RegTask: Client is not registered. Sending registration request... ClientIDManagerStartup 11/19/2009 2:24:03 PM 2168 (0x0878)

RegTask: Failed to send registration request message. Error: 0x80040231 ClientIDManagerStartup 11/19/2009 2:24:03 PM 2168 (0x0878)

RegTask: Failed to send registration request. Error: 0x80040231 ClientIDManagerStartup 11/19/2009 2:24:03 PM 2168 (0x0878)

 

 

LocationServices.log

 

Sending Fallback Status Point message, STATEID='500'. LocationServices 11/19/2009 2:13:41 PM 316 (0x013C)

Processing pending site assignment. LocationServices 11/19/2009 2:13:46 PM 316 (0x013C)

Assigning to site 'XYZ' LocationServices 11/19/2009 2:13:46 PM 316 (0x013C)

LSVerifySiteVersion : Verifying Site Version for <XYZ> LocationServices 11/19/2009 2:13:46 PM 316 (0x013C)

LSVerifySiteVersion: Client is on Internet Enabled - skipping version verification. LocationServices 11/19/2009 2:13:46 PM 316 (0x013C)

Sending Fallback Status Point message, STATEID='700'. LocationServices 11/19/2009 2:13:46 PM 316 (0x013C)

Unknown task LSProxyMPModificationTask in non-quarantine - ignoring. LocationServices 11/19/2009 2:13:46 PM 1124 (0x0464)

Successfully processed pending site assignment. LocationServices 11/19/2009 2:13:46 PM 316 (0x013C)

Security settings update detected, restarting CcmExec. LocationServices 11/19/2009 2:13:46 PM 3764 (0x0EB4)

Security settings update detected, restarting CcmExec. LocationServices 11/19/2009 2:13:46 PM 3764 (0x0EB4)

Successfully stored new site signing certificate... LocationServices 11/19/2009 2:13:46 PM 316 (0x013C)

Name      : The site code of this site server is XYZ LocationServices 11/19/2009 2:13:46 PM 316 (0x013C)

Sha1 Hash : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx LocationServices 11/19/2009 2:13:46 PM 316 (0x013C)

Valid From: 2009-11-09, 21:27 LocationServices 11/19/2009 2:13:46 PM 316 (0x013C)

Valid To  : 2010-11-09, 21:27 LocationServices 11/19/2009 2:13:46 PM 316 (0x013C)

LSGetManagementPointForSite: Client is always on Internet - skipping AD look up. LocationServices 11/19/2009 2:13:46 PM 316 (0x013C)

Failed to retrieve AMP for site code 'XYZ' with error (0x80004005). Nulling existing entry in WMI LocationServices 11/19/2009 2:13:46 PM 316 (0x013C)

Persisted Default Management Point Location locally LocationServices 11/19/2009 2:13:46 PM 316 (0x013C)

Failed to reset certificate request times. (0x80041002) LocationServices 11/19/2009 2:13:46 PM 316 (0x013C)

Security settings update detected, restarting CcmExec. LocationServices 11/19/2009 2:13:46 PM 3764 (0x0EB4)

Security settings update detected, restarting CcmExec. LocationServices 11/19/2009 2:13:46 PM 1712 (0x06B0)

No security settings update detected. LocationServices 11/19/2009 2:13:46 PM 316 (0x013C)

LSGetManagementPointForSite: Client is always on Internet - skipping AD look up. LocationServices 11/19/2009 2:13:57 PM 2168 (0x0878)

Failed to retrieve AMP for site code 'XYZ' with error (0x80004005). Nulling existing entry in WMI LocationServices 11/19/2009 2:13:57 PM 2168 (0x0878)

Persisted Default Management Point Location locally LocationServices 11/19/2009 2:13:57 PM 2168 (0x0878)

 

 

CCMExec.log

 

The 'Certificate Store' is empty in the registry, using default store name 'MY'. CCMEXEC 11/19/2009 2:13:57 PM 2168 (0x0878)

Raising event:

 

instance of CCM_ServiceHost_CertRetrieval_Status

{

DateTime = "20091119191357.477000+000";

HRESULT = "0x00000000";

ProcessID = 2064;

ThreadID = 2168;

};

CCMEXEC 11/19/2009 2:13:57 PM 2168 (0x0878)

[CCMHTTP] AsyncCallback(): ----------------------------------------------------------------- CCMEXEC 11/19/2009 2:14:02 PM 2168 (0x0878)

[CCMHTTP] AsyncCallback(): WINHTTP_CALLBACK_STATUS_SECURE_FAILURE Encountered CCMEXEC 11/19/2009 2:14:02 PM 2168 (0x0878)

[CCMHTTP]                : dwStatusInformationLength is 4

CCMEXEC 11/19/2009 2:14:02 PM 2168 (0x0878)

[CCMHTTP]                : *lpvStatusInformation is 0x1

CCMEXEC 11/19/2009 2:14:02 PM 2168 (0x0878)

[CCMHTTP]            : WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED is set

CCMEXEC 11/19/2009 2:14:02 PM 2168 (0x0878)

[CCMHTTP] AsyncCallback(): ----------------------------------------------------------------- CCMEXEC 11/19/2009 2:14:02 PM 2168 (0x0878)

Raising event:

 

instance of CCM_CcmHttp_Status

{

DateTime = "20091119191402.547000+000";

HostName = "INETFQDN.domain.com";

HRESULT = "0x80072f8f";

ProcessID = 2064;

StatusCode = 1;

ThreadID = 2168;

};

CCMEXEC 11/19/2009 2:14:02 PM 2168 (0x0878)

Failed in WinHttpSendRequest API, ErrorCode = 0x2f8f CCMEXEC 11/19/2009 2:14:02 PM 2168 (0x0878)

[CCMHTTP] HTTP ERROR: URL=http://INETMPFQDN.domain.com/ccm_system/request, Port=443, Protocol=https, SSLOptions=63, Code=12175, Text=ERROR_WINHTTP_SECURE_FAILURE CCMEXEC 11/19/2009 2:14:02 PM 2168 (0x0878)

HandleRemoteSyncSend failed (0x80040231). CCMEXEC 11/19/2009 2:14:02 PM 2168 (0x0878)

CForwarder_Sync::Send failed (0x80040231). CCMEXEC 11/19/2009 2:14:02 PM 2168 (0x0878)

CForwarder_Base::Send failed (0x80040231). CCMEXEC 11/19/2009 2:14:02 PM 2168 (0x0878)

 

 

One last thing, there is no MP_RegistrationManager.log on the internet MP yet...

 

 

Well I believe that is about it  any help would be greatly appreciated!

 

-Jake Cohen

On Thu, Nov 19, 2009 at 5:48 PM, Jake Cohen <jakect@gmail.com> wrote:

Ok...I've found something else...

The template that was used to create the Site Server signing certificate (i.e. "The site code of this site server is ???") has the wrong OID defined.

Anybody have experience on re-issuing the site server signing certificate?  The good news is that it will be issued from the same CA as the first.

(Doing research now on what needs to be done and what the impact will be)

-Jake Cohen

 

On Thu, Nov 19, 2009 at 4:12 PM, Jake Cohen <jakect@gmail.com> wrote:

That is exactly how I exported the certificate and I am using SMSSIGNCERT as a MSI property during installation (The exported certificate is with the client install files, local on the internet client for install).

-Jake Cohen

 

On Thu, Nov 19, 2009 at 3:45 PM, Dzikowski, Michael <MDZIKOW1@hfhs.org> wrote:

I think it’s how you’re deploying the certificates.

 

http://technet.microsoft.com/en-us/library/bb932126.aspx

 

http://technet.microsoft.com/en-us/library/bb694140.aspx

 

Mike Dzikowski

WinTel Engineer

Henry Ford Health System | OneIT

2571 Product Drive | Rochester Hills, MI 48309

mdzikow1@hfhs.org

248.853.4891

 

From: admin@lists.myITforum.com [mailto:admin@lists.myITforum.com] On Behalf Of Jake Cohen
Sent: Thursday, November 19, 2009 3:32 PM


To: mssms@lists.myitforum.com
Subject: Re: [mssms] Problem getting IBCM going

 

Hi troy,

 

Thanks for the response.  Yes I actually found that the CRL-DP and AIA locations did not have any internet accessible entries, I was able to add them from the Certificate Authority MMC (Right click on the CA, goto the extensions tab) and I was able to use CERTUTIL to show that the new entry for the CRL was working properly.  As far as for the entry for the AIA location I was not able to verify it, but I know the path is correct and if I try to open the path directly in a web browser I am prompted to download the .crt file listed for the AIA.

 

I would like to avoid rebuilding the DMZ CA if at all possible but that may be my only choice...

 

Like I mentioned before, a client that is built on the intranet (and in AD) works just fine with the internet MP, however a client not in AD and only on the internet (workgroup mode) never becomes a client.  Here are the recent entries from my ClientIDManagerStartup.log

 

<![LOG[RegTask: Client is not registered. Sending registration request...]LOG]!><time="14:38:11.580+300" date="11-19-2009" component="ClientIDManagerStartup" context="" type="1" thread="3700" file="regtask.cpp:1434">

<![LOG[RegTask: Failed to send registration request message. Error: 0x80040231]LOG]!><time="14:38:11.799+300" date="11-19-2009" component="ClientIDManagerStartup" context="" type="3" thread="3700" file="regtask.cpp:1139">

<![LOG[RegTask: Failed to send registration request. Error: 0x80040231]LOG]!><time="14:38:11.799+300" date="11-19-2009" component="ClientIDManagerStartup" context="" type="3" thread="3700" file="regtask.cpp:1314">

<![LOG[RegTask: Client is not registered. Sending registration request...]LOG]!><time="14:42:11.782+300" date="11-19-2009" component="ClientIDManagerStartup" context="" type="1" thread="3700" file="regtask.cpp:1434">

<![LOG[RegTask: Failed to send registration request message. Error: 0x80040231]LOG]!><time="14:42:11.985+300" date="11-19-2009" component="ClientIDManagerStartup" context="" type="3" thread="3700" file="regtask.cpp:1139">

<![LOG[RegTask: Failed to send registration request. Error: 0x80040231]LOG]!><time="14:42:11.985+300" date="11-19-2009" component="ClientIDManagerStartup" context="" type="3" thread="3700" file="regtask.cpp:1314">

<![LOG[RegTask: Client is not registered. Sending registration request...]LOG]!><time="14:50:11.916+300" date="11-19-2009" component="ClientIDManagerStartup" context="" type="1" thread="3700" file="regtask.cpp:1434">

<![LOG[RegTask: Failed to send registration request message. Error: 0x80040231]LOG]!><time="14:50:12.275+300" date="11-19-2009" component="ClientIDManagerStartup" context="" type="3" thread="3700" file="regtask.cpp:1139">

<![LOG[RegTask: Failed to send registration request. Error: 0x80040231]LOG]!><time="14:50:12.275+300" date="11-19-2009" component="ClientIDManagerStartup" context="" type="3" thread="3700" file="regtask.cpp:1314">

<![LOG[RegTask: Client is not registered. Sending registration request...]LOG]!><time="14:58:12.244+300" date="11-19-2009" component="ClientIDManagerStartup" context="" type="1" thread="3700" file="regtask.cpp:1434">

<![LOG[RegTask: Failed to send registration request message. Error: 0x80040231]LOG]!><time="14:58:12.462+300" date="11-19-2009" component="ClientIDManagerStartup" context="" type="3" thread="3700" file="regtask.cpp:1139">

<![LOG[RegTask: Failed to send registration request. Error: 0x80040231]LOG]!><time="14:58:12.462+300" date="11-19-2009" component="ClientIDManagerStartup" context="" type="3" thread="3700" file="regtask.cpp:1314">

<![LOG[RegTask: Client is not registered. Sending registration request...]LOG]!><time="15:14:12.337+300" date="11-19-2009" component="ClientIDManagerStartup" context="" type="1" thread="3700" file="regtask.cpp:1434">

<![LOG[RegTask: Failed to send registration request message. Error: 0x80040231]LOG]!><time="15:14:12.602+300" date="11-19-2009" component="ClientIDManagerStartup" context="" type="3" thread="3700" file="regtask.cpp:1139">

<![LOG[RegTask: Failed to send registration request. Error: 0x80040231]LOG]!><time="15:14:12.602+300" date="11-19-2009" component="ClientIDManagerStartup" context="" type="3" thread="3700" file="regtask.cpp:1314">

 

 

As always, your help is appreciated.  =)

 

-Jake Cohen

 

On Thu, Nov 19, 2009 at 3:02 PM, Troy Martin <Troy.Martin@1e.com> wrote:

Ok…so, when that DMZ CA was built, it sounds like the AIA and CRL-DP locations still have “file-share”, FTP (and possibly Active Directory) locations listed.  These settings in certs tell clients where to “find” the path to a root cert.  Clients on the Internet need an HTTP location specified.  If an HTTP location is not specified, the client will fail.

 

The problem with configuring this on a CA that will service Internet clients is that the setting can only be configured during CA installation…it cannot be configured after the CA is installed.

 

When installing a Microsoft CA (W2K3), I always start by creating a file called CAPolicy.inf and putting it in C:\Windows of the CA.  Then you can add the CA via Windows Components in Add/Remove Programs.

 

The contents of CAPolicy.inf are:

 

[Version]

Signature="$Windows NT$"

 

[Version]

Signature="$Windows NT$"

[Certsrv_Server]

RenewalKeyLength=2048

RenewalValidityPeriod=5

RenewalValidityPeriodUnits=Years

[AuthorityInformationAccess]

[CRLDistributionPoint]

 

Notice how AuthorityInformationAccess and CRLDistributionPoint are blank…

 

My suggestion would be to verify/validate the configurations of your Root CA and rebuild the CA in the DMZ, following the tutorial below

 

http://www.isaserver.org/tutorials/Publishing-Public-Key-Infrastructure-ISA-Server-2004-Part1.html

http://www.isaserver.org/tutorials/Publishing-Public-Key-Infrastructure-ISA-Server-2004-Part2.html

http://www.isaserver.org/tutorials/Publishing-Public-Key-Infrastructure-ISA-Server-2004-Part3.html

 

 

 

Troy L. Martin | Senior Consultant | 1E |

Mobile: 678 898 6147 | US/Canada Toll Free: 1 866 592 4214

troy.martin@1e.com | www.1e.com

 

From: admin@lists.myITforum.com [mailto:admin@lists.myITforum.com] On Behalf Of Jake Cohen
Sent: Thursday, November 19, 2009 2:42 PM


To: mssms@lists.myitforum.com
Subject: Re: [mssms] Problem getting IBCM going

 

Microsoft.

 

Root CA on the intranet, subordinate CA in the DMZ (used for all internet only client certs).

 

-Jake Cohen

On Thu, Nov 19, 2009 at 2:14 PM, Troy Martin <Troy.Martin@1e.com> wrote:

What is your PKI?  Microsoft or other?

 

Troy L. Martin | Senior Consultant | 1E |

Mobile: 678 898 6147 | US/Canada Toll Free: 1 866 592 4214

troy.martin@1e.com | www.1e.com

 

From: admin@lists.myITforum.com [mailto:admin@lists.myITforum.com] On Behalf Of Jake Cohen
Sent: Thursday, November 19, 2009 1:30 PM

Subject: Re: [mssms] Problem getting IBCM going

 

Good catch.  =)  So the Subordinate CA in the DMZ did not have SAN enabled so the certificate it issued to the MP didn't have the Internet FQDN listed.

 

New results since getting the Subordinate CA and the MP cert updated...

 

A client originally built on the intranet and then moved to the internet was able to communicate with the internet MP (proof by initiating a HINV while connected only to the Internet).

 

Now to figure out why the internet only clients with certificates from the Subordinate CA will not install the client and talk to the MP...

 

-Jake Cohen

On Thu, Nov 19, 2009 at 1:17 PM, Dzikowski, Michael <MDZIKOW1@hfhs.org> wrote:

What Mike said:

Subject Alternative Name property = very important

 

That hung me up a few hours when I was testing IBCM…

 

Mike Dzikowski

WinTel Engineer

Henry Ford Health System | OneIT

2571 Product Drive | Rochester Hills, MI 48309

mdzikow1@hfhs.org

248.853.4891

 

From: admin@lists.myITforum.com [mailto:admin@lists.myITforum.com] On Behalf Of Mike Terrill
Sent: Thursday, November 19, 2009 1:08 PM


To: mssms@lists.myitforum.com
Subject: RE: [mssms] Problem getting IBCM going

 

Double check FQDN of the server that is acting as the Internet MP.  If the intranet FQDN is different than the Internet FQDN, then you will need certificates that support the Subject Alternative Name property.

 

Mike Terrill | Systems Management Practice Lead | 1E |

Mobile: (480) 862-9137

US/Canada Toll Free: (866) 592-4214

mike.terrill@1e.com | www.1e.com

blog32 rss32 twiter32 uTube32 linked32 facebook32

 

From: admin@lists.myITforum.com [mailto:admin@lists.myITforum.com] On Behalf Of Jake Cohen
Sent: Thursday, November 19, 2009 10:58 AM

Subject: Re: [mssms] Problem getting IBCM going

 

We got the test done, the test system works fine on the intranet but does not do anything on the internet.  Looking into the Internet MP cert now...

 

-Jake Cohen

On Thu, Nov 19, 2009 at 12:12 PM, Jake Cohen <jakect@gmail.com> wrote:

Attempting to do that now, the system is not ready yet.

 

-Jake Cohen

 

On Thu, Nov 19, 2009 at 9:42 AM, Dzikowski, Michael <MDZIKOW1@hfhs.org> wrote:

What happens as a test, if you take a machine that has the client installed and certificates installed that is on the domain, then sit it on the internet…does it get policies, etc?

 

 

Mike Dzikowski

WinTel Engineer

Henry Ford Health System | OneIT

2571 Product Drive | Rochester Hills, MI 48309

mdzikow1@hfhs.org

248.853.4891

 

From: admin@lists.myITforum.com [mailto:admin@lists.myITforum.com] On Behalf Of Mike Terrill
Sent: Wednesday, November 18, 2009 11:58 PM

Subject: RE: [mssms] Problem getting IBCM going

 

Also, how are you installing the clients?  Are they being installing manually while on the Internet?  Are they being installing manually/Client Push/etc on the intranet?

 

Mike Terrill | Systems Management Practice Lead | 1E |

Mobile: (480) 862-9137

US/Canada Toll Free: (866) 592-4214

mike.terrill@1e.com | www.1e.com

blog32 rss32 twiter32 uTube32 linked32 facebook32

 

From: admin@lists.myITforum.com [mailto:admin@lists.myITforum.com] On Behalf Of Troy Martin
Sent: Wednesday, November 18, 2009 7:22 AM
To: mssms@lists.myitforum.com
Subject: RE: [mssms] Problem getting IBCM going

 

How did you install the Client Authentication cert on the Internet clients?

Is the cert in the Computer or User personal store?

 

Which IBCM scenario is your site configured for?

How do you know that (end-to-end) your entire PKI is configured properly (from the inTRAnet and the InTERnet)? Please answer this one

 

Is CRL Checking on the site enabled, or disabled?

What tests have you conducted from the client (while on the Internet) to see if it has access to the CRL-DP’s?

 

Run the following commands from the Internet client, AND from an inTRAnet client:

 

Certutil -URL <URL used when defining CDP/AIA in certificate>

Certutil -verify <UNC to CRLDP-share>\<name>.crt

 

Please post the CCMSetup.log, LocationServices.log and ClientLocation.log

 

 

Troy L. Martin | Senior Consultant | 1E |

Mobile: 678 898 6147 | US/Canada Toll Free: 1 866 592 4214

troy.martin@1e.com | www.1e.com

 

From: admin@lists.myITforum.com [mailto:admin@lists.myITforum.com] On Behalf Of Jake Cohen
Sent: Tuesday, November 17, 2009 11:01 PM
To: mssms@lists.myitforum.com
Subject: [mssms] Problem getting IBCM going

 

Hey everyone,

 

Here is what I have...

 

I am trying to get workgroup mode clients connected into SCCM via internet only.  I get the client installed and it has a site code defined but the client never seems to actually report into SCCM.  Here are the errors I'm seeing...

 

I've checked the certificates and everything seems to be in order.  I did have a problem where the Root CA did not appear to be trusted, I got that squared away but still no luck.

 

In the ClientIDManagerStartup.log on the client:

-The 'Certificate Store' is empty in the registry, using default store name 'MY'.

-RegTask: Failed to get certificate. Error: 0x80040281

 

In the FSPStateMessage.log on the client:

-State message with TopicType 800 and TopicId {3260E198-E0B7-44D2-A24E-4D5D1788E4C8} has been sent to the FSP

 

 

And finally the client is (finally) reporting an error code to the FSP, -2147220863.

 

Any help would be greatly appreciated!

 

-Jake Cohen


==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/smslist/

 



DISCLAIMER: This is a PRIVATE AND CONFIDENTIAL message for the ordinary user of this email address. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind 1E to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.


==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/smslist/


==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/smslist/

==============================================================================CONFIDENTIALITY NOTICE: This email contains information from the sender that may be CONFIDENTIAL, LEGALLY PRIVILEGED, PROPRIETARY or otherwise protected from disclosure. This email is intended for use only by the person or entity to whom it is addressed. If you are not the intended recipient, any use, disclosure, copying, distribution, printing, or any action taken in reliance on the contents of this email, is strictly prohibited. If you received this email in error, please contact the sending party by reply email, delete the email from your computer system and shred any paper copies. Note to Patients: There are a number of risks you should consider before using e-mail to communicate with us. See our Privacy Policy and Henry Ford My Health at www.henryford.com for more detailed information. If you do not believe that our policy gives you the privacy and security protection you need, do not send e-mail or Internet communications to us.==============================================================================


==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/smslist/

 


==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/smslist/

 


==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/smslist/


==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/smslist/

==============================================================================CONFIDENTIALITY NOTICE: This email contains information from the sender that may be CONFIDENTIAL, LEGALLY PRIVILEGED, PROPRIETARY or otherwise protected from disclosure. This email is intended for use only by the person or entity to whom it is addressed. If you are not the intended recipient, any use, disclosure, copying, distribution, printing, or any action taken in reliance on the contents of this email, is strictly prohibited. If you received this email in error, please contact the sending party by reply email, delete the email from your computer system and shred any paper copies. Note to Patients: There are a number of risks you should consider before using e-mail to communicate with us. See our Privacy Policy and Henry Ford My Health at www.henryford.com for more detailed information. If you do not believe that our policy gives you the privacy and security protection you need, do not send e-mail or Internet communications to us.==============================================================================


==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/smslist/

 


==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/smslist/


==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/smslist/

 


==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/smslist/


==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/smslist/

 


==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/smslist/

==============================================================================CONFIDENTIALITY NOTICE: This email contains information from the sender that may be CONFIDENTIAL, LEGALLY PRIVILEGED, PROPRIETARY or otherwise protected from disclosure. This email is intended for use only by the person or entity to whom it is addressed. If you are not the intended recipient, any use, disclosure, copying, distribution, printing, or any action taken in reliance on the contents of this email, is strictly prohibited. If you received this email in error, please contact the sending party by reply email, delete the email from your computer system and shred any paper copies. Note to Patients: There are a number of risks you should consider before using e-mail to communicate with us. See our Privacy Policy and Henry Ford My Health at www.henryford.com for more detailed information. If you do not believe that our policy gives you the privacy and security protection you need, do not send e-mail or Internet communications to us.==============================================================================


==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/smslist/


==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/smslist/


==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/smslist/


==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/smslist/


==============
Missed an email? Check out the list archive:
http://myitforum.com/cs2/blogs/smslist/

Published with BlogMailr



Trackbacks

No Trackbacks

Comments

No Comments