Query in installing client using NLB MP in Native mode
I have a two nodes NLB cluster(cluster name : nlb.vlan575.com), and I configured it as default mp.
I have used two ways to install client.
1, command
Ccmsetup.exe /mp:nlb.vlan575.com /native SMSSITECODE=575 SMSNOWINSLOOKUP=TRUE or SMSDIRECTORYLOOKUP=NOWINS
But it failed in ccmsetup.log, the client can’t be installed at all.
2,push install
There are no errors in ccmsetup.log, but client can’t register. They are two error logs on client.
While when I change default mp to a normal remote mp , the client can get policy successfully.
I have searched the problem online with finding only one useful page.
I have went through kb931351. But I don’t know how to do the steps.
- Moved byStan WhiteMSFT, ModeratorMonday, June 29, 2009 2:39 PM (From:Configuration Manager General)
Answers
If your management point server is also your site server, then yes, this .inf file will work. Because you're using an enterprise CA, your .inf file can actually be simpler than this because it will use values defined in the certificate template. Let's say the intranet FQDN of the NLB management point is "nlbmp.contoso.com" and your first management point server has the intranet FQDN of "mp.contoso.com" - try this:
[NewRequest]
Subject = "CN=mp.contoso.com"
KeyLength = 1024
MachineKeySet = True
RequestType = CMC
[RequestAttributes]
CertificateTemplate = WebServer
SAN="dns=nlbmp.contoso.com&dns=mp.contoso.com"
Request the certificate, and then use the Certificates MMC snap-in to confirm that the two FQDNs are listed for the Subject Alternative Name in the certificate details (the value in the Subject is actually ignored by Configuration Manager when a value is defined for the SAN). Then bind this certificate in IIS.
- Carol
This posting is provided “AS IS” with no warranties and confers no rights- Marked As Answer byCarol BaileyMSFT, ModeratorWednesday, July 08, 2009 12:32 PM
- Good to hear that this is now working - thanks for the update!
I can see why your certificate request file works, and that it's convenient to use the same SAN value in the file for both servers, changing just the Subject name to make the certificate unique. However, I wouldn't personally add both FQDNs of the management point into the SAN. It needs only the cluster FQDN and the server FQDN.
So on server nlb01.vlan575.com the line would read SAN="dns=nlb.vlan575.com&dns=nlb01.vlan575.com" and on server nlb02.vlan575.com the line would read SAN="dns=nlb.vlan575.com&dns=nlb02.vlan575.com".
It's not technically wrong to have a name in the certificate that you don't need, but it's probably not a best practice. If you do want to change this even though it's working, it should be quite easy to modify the existing .inf files to remove the other server name, request a new certificate, and then change the binding to use this new certificate in IIS. If for some reason it no longer works with the new certificate, you still have the previously installed certificate and can rebind that in IIS.
- Carol
This posting is provided “AS IS” with no warranties and confers no rights- Marked As Answer byCarol BaileyMSFT, ModeratorWednesday, July 08, 2009 12:32 PM
All Replies
I need to install client using nlb mp in native mode. The client can't get policy.
I found NLB architecture doesn't need register SPN in Native Mode.
There are no errors in
MPSetup.log
MPcontrol.log
MP_GetAuth.log
On client there are errors in ccmexec.log
Cached CCM (user, session) is: (S-1-5-21-3305082152-3599221362-3171188685-500,1). CCMEXEC 2009/6/25 1:24:06 3864 (0x0F18)
Cached CCM (user, session) is: (S-1-5-21-3305082152-3599221362-3171188685-500,1). CCMEXEC 2009/6/25 1:24:06 3864 (0x0F18)
Raising event:instance of CCM_ServiceHost_CertRetrieval_Status
{
DateTime = "20090625082411.298000+000";
HRESULT = "0x00000000";
ProcessID = 3416;
ThreadID = 2960;
};
CCMEXEC 2009/6/25 1:24:11 2960 (0x0B90)
[CCMHTTP] AsyncCallback(): ----------------------------------------------------------------- CCMEXEC 2009/6/25 1:24:14 2960 (0x0B90)
[CCMHTTP] AsyncCallback(): WINHTTP_CALLBACK_STATUS_SECURE_FAILURE Encountered CCMEXEC 2009/6/25 1:24:14 2960 (0x0B90)
[CCMHTTP] : dwStatusInformationLength is 4
CCMEXEC 2009/6/25 1:24:14 2960 (0x0B90)
[CCMHTTP] : *lpvStatusInformation is 0x10
CCMEXEC 2009/6/25 1:24:14 2960 (0x0B90)
[CCMHTTP] : WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID is set
CCMEXEC 2009/6/25 1:24:14 2960 (0x0B90)
[CCMHTTP] AsyncCallback(): ----------------------------------------------------------------- CCMEXEC 2009/6/25 1:24:14 2960 (0x0B90)- Merged byJohn MarcumMVPFriday, June 26, 2009 2:48 PMduplicate post
- "WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID is set" indicates a certificate misconfiguration.
The certificate with server authentication capability on each of the management points in the NLB must have both of these values in the certificate SAN:
1. The intranet FQDN of the management point NLB - that matches the value defined for the Private DNS in the General tab of the Management Point Component properties
2. The intranet FQDN of the site system server - that matches the value defined for the Intranet FQDN in the General tab of the site system properties.
If the certificates do not have these values, the native mode NLB management point will not work.
Specifically, what steps are you having problems with in kb931351? For example, do you need help creating the .inf file to request the certificate with Certreq?
- Carol
This posting is provided “AS IS” with no warranties and confers no rights - Thanks for your reply! I am going to use Certreq.exe utility to create and submit a certificate request that includes a SAN in kb931351. I use enterprise CA.
[Version]
Signature="$Windows NT$
[NewRequest]
Subject = "CN=corpdc1.fabrikam.com" ; must be the FQDN of domain controller
EncipherOnly = FALSE
Exportable = FALSE ; TRUE = Private key is exportable
KeyLength = 1024 ; Common key sizes: 512, 1024, 2048,
; 4096, 8192, 16384
KeySpec = 1 ; Key Exchange
KeyUsage = 0xA0 ; Digital Signature, Key Encipherment
MachineKeySet = True
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = CMC
[RequestAttributes]
CertificateTemplate = WebServer ;Omit line if CA is a stand-alone CA
SAN="dns=siteservername&dns=nlbclustername"
I should add my site server name and nlb cluster name to SAN , shouldn't I? And then I use this certificate to bind to https in iis.
I wonder to know if there are wrong steps. If your management point server is also your site server, then yes, this .inf file will work. Because you're using an enterprise CA, your .inf file can actually be simpler than this because it will use values defined in the certificate template. Let's say the intranet FQDN of the NLB management point is "nlbmp.contoso.com" and your first management point server has the intranet FQDN of "mp.contoso.com" - try this:
[NewRequest]
Subject = "CN=mp.contoso.com"
KeyLength = 1024
MachineKeySet = True
RequestType = CMC
[RequestAttributes]
CertificateTemplate = WebServer
SAN="dns=nlbmp.contoso.com&dns=mp.contoso.com"
Request the certificate, and then use the Certificates MMC snap-in to confirm that the two FQDNs are listed for the Subject Alternative Name in the certificate details (the value in the Subject is actually ignored by Configuration Manager when a value is defined for the SAN). Then bind this certificate in IIS.
- Carol
This posting is provided “AS IS” with no warranties and confers no rights- Marked As Answer byCarol BaileyMSFT, ModeratorWednesday, July 08, 2009 12:32 PM
- Thanks for your help!
Now nlb mp works in native mode.
My nlb cluster has two mps, nlb01.vlan575.com and nlb02.vlan575.com.
nlb.vlan575.com is the name of my nlb cluster.
On two nodes I require the certificate using the cert.inf.
[NewRequest]
Subject = "CN=<cluster node name>"
KeyLength = 1024
MachineKeySet = True
RequestType = CMC
[RequestAttributes]
CertificateTemplate = WebServer
SAN="dns=nlb.vlan575.com&dns=nlb01.vlan575.com&dns=nlb02.vlan575.com" - Good to hear that this is now working - thanks for the update!
I can see why your certificate request file works, and that it's convenient to use the same SAN value in the file for both servers, changing just the Subject name to make the certificate unique. However, I wouldn't personally add both FQDNs of the management point into the SAN. It needs only the cluster FQDN and the server FQDN.
So on server nlb01.vlan575.com the line would read SAN="dns=nlb.vlan575.com&dns=nlb01.vlan575.com" and on server nlb02.vlan575.com the line would read SAN="dns=nlb.vlan575.com&dns=nlb02.vlan575.com".
It's not technically wrong to have a name in the certificate that you don't need, but it's probably not a best practice. If you do want to change this even though it's working, it should be quite easy to modify the existing .inf files to remove the other server name, request a new certificate, and then change the binding to use this new certificate in IIS. If for some reason it no longer works with the new certificate, you still have the previously installed certificate and can rebind that in IIS.
- Carol
This posting is provided “AS IS” with no warranties and confers no rights- Marked As Answer byCarol BaileyMSFT, ModeratorWednesday, July 08, 2009 12:32 PM
