After installing an Administrative node of FAST Search Server 2010, additional Non-Administrative FAST Search Server 2010 nodes cannot communicate with the Admin node. Subsequently, the non-admin nodes to fail download the deployment.xml, and as such, fail to finish configuration successfully.
When running the psconfig.ps1 script on the non-admin nodes via PowerShell, you may see a failure similar to the following:
Please wait while Windows configures FAST Search Server for SharePoint. Configuration may take several minutes...
An error occurred while configuring IPSec - Could not connect to the admin node.
This may be because of,
1. Invalid admin node name
2. Invalid baseport. Baseport of admin node and non-admin node must be same
3. Admin node is not up and running
4. Missing IPSec rules on admin node. If you added this host to the deployment.xml after running this script on the admin node, you need to rerun the IPSec cmdlet on the admin node
See C:\Install\FAST\log\fast-install.log for more details.
This is also evident if you simply attempt to run the Set-FASTSearchIPSec PowerShell cmdlet:
2010-07-15 04:03:19.170Z Verbose  SetIPSec - no.fast.middleware.SystemException: Unable to connect to the remote server ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 220.127.116.11:13390
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Int32 timeout, Exception& exception)
--- End of inner exception stack trace ---
at no.fast.middleware.ConnectionManager.ExecuteMethod(HttpWebRequest request, MemoryStream dataStream)
at no.fast.dsinterfaces.nameservice.NameserverStub.Resolve(String Name, String InterfaceType, String Version)
at Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Common.Middleware.MiddlewareOperations.DownloadDeploymentConfig(String localhost, String nameserverhost, String middleware_port, String fileName)
at Microsoft.SharePoint.Search.Extended.Installer.Mahasen.Cmdlets.SetIPSecCommand.CreateNonAdminRules(IHostConfig hostConfig)
The non-admin node(s) attempt to communicate to the admin node via port 13390, which is secured via IPSEC. If the Kerberos session encounters a failure, the IPSEC connection is never established, and the socket will not be opened.
1. In these scenarios, we use the “Microsoft IPSEC Diagnostic Tool” (from http://support.microsoft.com/kb/943862) to gather additional diagnostic data specific to the IPSEC failures.
2. Once the data has been collected, open the wfpdiag.txt file, search for “ERROR_IPSEC_IKE_AUTH_FAIL,” and then you should see data similar to the following:
01C0.15D4::07/15/2010-16:38:22.626 [user] |18.104.22.168|Peer failed with Windows error 13801(ERROR_IPSEC_IKE_AUTH_FAIL)
01C0.15D4::07/15/2010-16:38:22.626 [ikeext] 1137|22.214.171.124|ProcessNotifyData: mmSa 0000000002F14600 cookie 71ddc30c state 2 messId 0
01C0.15D4::07/15/2010-16:38:22.643 [ikeext] 1137|126.96.36.199|IKE diagnostic event:
Local address field set
Remote address field set
IP version field set
IP version: IPv4
IP protocol: 0
Local address: 188.8.131.52
Remote address: 184.108.40.206
Local Port: 0
Remote Port: 0
User SID: <invalid>
Failure type: IKE/Authip Main Mode Failure
Type specific info:
Failure error code:0x000035e9
IKE authentication credentials are unacceptable
Failure point: Remote
Multiple MM failures present
Keying module type: Authip
MM State: Second roundtrip (SSPI) packet sent
MM SA role: Responder
MM auth method: Unknown
MM ID: 0x0000000000000471
MM Filter ID: 0x000000000004bfc3
01C0.15D4::07/15/2010-16:38:22.644 [ikeext] 1137|220.127.116.11|IKE diagnostic event:
Failure error code:0x000035ec
General processing error
Failure point: Local
MM auth method: Kerberos
01C0.15D4::07/15/2010-16:38:22.644 [ikeext] 1137|18.104.22.168|Cleaning up mmSa: 0000000002F14600. Error 13801(ERROR_IPSEC_IKE_AUTH_FAIL)
After reviewing the data above, we can clearly see a breakdown in the IPSEC conversation. This is primarily caused by one (or both) of the following tweaks:
· A Group Policy setting that forces the Kerberos conversation to take place entirely over UDP (“MaxPacketSize”)
· A Group Policy setting that restricts the Maximum Token Size (“MaxTokenSize”)
To verify this, open an Administrative Command Prompt, and run “GPRESULT -V” (no quotes), and you should see an entry similar to the following:
GPO: Default Domain Policy
Value: 160, 134, 1, 0
This indicates that the Default Domain Policy is modifying the default settings for the MaxTokenSize, and subsequently is interfering with our ability to successfully establish a connection via IPSEC.
You may pursue the following options to resolve this issue:
· Exclude the FAST Search Server 2010 machines from having this setting applied to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxTokenSize
· The FAST Server Administrators may potentially override the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxTokenSize setting manually in the Registry (to a value of 0x0000FFFF), and subsequently lock it down such that future Group Policy applications do not overwrite this setting
Please refer to http://support.microsoft.com/kb/327825, “New resolution for problems with Kerberos authentication when users belong to many groups” for further information regarding the MaxTokenSize registry value.