Errror "There are other servers specified as farm members in"

Aug 2, 2012 at 7:13 PM

Hi

I just configured and ran the script for the first time.  The script ran for a few seconds and then displayed the following error.  I was planning on running this on each farm member to create them one at a time so I dont know why the error is happening.  Has anyone seen this before or have any ideas?  thanks.

- There are other servers specified as farm members in:
- D:\Software\AutoSPInstaller\SP2010\AutoSPInstaller\AutoSPInstallerInput.xml
- but <RemoteInstall> is not set to "true" - nothing else to do
- Completed!

Coordinator
Aug 3, 2012 at 10:56 PM

What does your planned farm topology look like, and which server (role) is the error above being displayed on? I'd check if the server that's displaying this message has been specified in the AutoSPInstallerInput.xml file - it appears it hasn't.

Brian

Aug 13, 2012 at 7:02 AM

Hi Brian,

I have also experienced this same error recently using the latest version of the scripts.  I have spoke with two other folks who claim the same issue, I will be helping one of them troubleshoot this Friday and will add this information to that which I have collected so far.

 

Topologies seem to vary from what I can determine, although in my most recent case, I had 3 wfe and 3 app.  Pretty standard/default search topo, query services on wfes, and crawl component on apps.

 

Having used the scripts for a while and being leary of UNC and remote installs, I opt for the one-file-per-server approach.  This yielded the same error mentioned by the OP. 

In my case the script ran fine on APP01, and APP02 and failed on APP03.  Also, it ran fine on WFE01, but failed on WFE02 and WFE03.    I literally only renamed the file from WFE01 to WFE02 with no other changes, and it failed while running on WFE02.  Same story w/ WFE03 and APP03.

 

I noodled w/ the script a bit and found that get-FarmServers() returns the servers names in the cases that it works.  In the cases where I get this error its returning null from that function.  I believe that there is a conditional that throws us into the remote-install function as a result, and since we clearly haven't set it up as a remote install it gets grumpy and hence our error message.

 

I flattened the boxes and ran a version of the scripts I had from.. I want to say February time frame... they ran fine on all servers.

Additionally I just helped a customer through a full on production install with an older set of scripts and didn't have any trouble at all.

 

In conversations I'm having this is not quite an isolated occurrence it seems.  Again, I'll be helping a colleague's customer install an environment with this script this Friday because they're having troubles that sound similar to these.  I'll be happy to collect information for you on that gig as well if its helpful.  Is there anything specifically you'd like me to capture?  I'd be happy to try.  These scripts do rock, and they're so good I just totally trashed my own set and went to using these exclusively.  I'd love to help in any way I can.

 

-Martin

Sep 2, 2012 at 9:32 PM

Not sure if this helps but when I experienced this problem in my Development environment (running v3.0.3 of the script)  I modified the Input file to change the instances of Provision="True" to a specific Server Name e.g. <ExcelServices Provision="Server1">

This seemed to get me past the problem and installation continued normally.

Sep 16, 2012 at 1:36 PM

I just experienced the same problem with a customer. Hinting it down, I found that this was triggered because the configuration file wasn't being parsed correctly. In my case, it was because one of my service accounts was using the "<" character in its password. I had escaped it, but not properly.... I had neglected to add the semicolon in &lt;

Hope it helps

Sep 18, 2012 at 11:36 PM

I had the same issue and after reading this discussion was able to do the same as R5D4 above.  I modified the Provision= on one of my entries (though I was running all locally) to specifically refer to the server name of the server from which I was running the script.  This worked like a charm.

I have indeed run this script before without this problem that I remember, but something in the newest code seems to force reference to the server it's running on else it returns null for the list of Farm Servers (I verified this by manually running the get-FarmServers like the user above).  Perhaps this is a good change but it would have saved me a couple of hours of scratching my head if I had know it was documented somewhere as a requirement.

So, to install on the rest of my servers I am going to see if it needs the server name listed at least once in the AutoSPInstallerInput--MachineName.xml file . . .

Mar 12, 2013 at 12:34 PM
Hello Brian,
I have just tried using the latest changeset (99077). I'm using a vm image where I use all your scripts and they work fine untill this changeset. when I try running the script it says:
There are other servers specified as farm members in:
  • D:\Software\AutoSPInstaller\SP2010\AutoSPInstaller\AutoSPInstallerInput.xml
  • but <RemoteInstall> is not set to "true" - nothing else to do
  • Completed!
I've tried setting things up like in this threat (eq provision="true" set to provision="nameserver") or checking the passwords, but none worked. When I try running another changeset of the latest public autospinstaller setup it works like a champ!

Any ideas?
Mar 12, 2013 at 3:41 PM
I also experienced the same results with changeset 98528 a few days ago
Apr 22, 2013 at 12:47 AM
Having the same problem using 3.86 version of the script. Ran fine on the 1st App server. The error occurred on the WFE.
Apr 22, 2013 at 11:16 AM
I had the same issue as well because l was configuring two farms - search farm and content farm. Since my WFEs in content farm were purely WFE servers and no query role assigned to them. There is nowhere on the script where you can add WFE servers and the script will be looking for the servername on the autospinstallerinput.xml thats why the error does not come on app servers because you might add them to host central admin within the script.

Are your WFEs going to be used as quesry servers as well? The way l managed to run the script on my content farm was to add the WFEs servers as quesy servers even though there was no search service application configured in content farm so that role will not be added on the WFEs but if search service application is configured within the farm and you do not want these WFEs to have query role then my work around will not work.

The other option maybe will be to add these WFEs as query servers and if you do not want them to have query role assigned to them you will have to stop the search service application on all the WFEs.
Apr 24, 2013 at 12:21 AM
For my case, the WFEs will not run the query component, and therefore they don't appear anywhere in the XML input. The script therefore does not recognise them as a SharePoint server.

I worked around this by adding my own custom config file and overriding the Get-FarmServers function to get the server names from the default config file, plus my custom config file.
Apr 24, 2013 at 12:48 AM

I am interested in learning more about your customization. Do you mind sharing?

Apr 24, 2013 at 1:17 AM
My custom configuration file looks like below. Place this file in the same folder as the default XML input file.
<AdditionalConfigurations>
    <DedicatedWFEServers>
        <!-- List name of all dedicated WFEs here -->
        <Server>server1</Server>
    </DedicatedWFEServers>
</AdditionalConfigurations>
I then copy the Get-FarmServers function into the AutoSPInstallerFunctionsCustom.ps1 file. Toward the end of this cloned function, just before "Return $farmServers", I added the lines below:
$wfeServers = GetDedicatedWFEServers
$farmServers = $farmServers, $wfeServers
The GetDedicatedWFEServers is a custom function in AutoSPInstallerFunctionsCustom.ps1, and it looks like this:
Function GetDedicatedWFEServers
{
    $additionalConfigurationsInputFileName = GetAdditionalConfigurationsInputFileName
    [xml]$additionalConfigurationsXmlInput = Get-Content $additionalConfigurationsInputFileName

    $wfeServers = $additionalConfigurationsXmlInput.AdditionalConfigurations.DedicatedWFEServers.Server
    $wfeServers = $wfeServers | where {$_ -ne $null -and $_ -ne ""} | select -Unique

    return $wfeServers
}

Function GetAdditionalConfigurationsInputFileName()
{
    ##Determine the additional input file to use base on the current domain
    $currentPath = Split-Path -Parent $PSCommandPath
    $fileNamePrefix = "AdditionalConfigurations"

    ##First try computer specific
    $additionalConfigurationsInputFileName = ($currentPath + "\$fileNamePrefix-$env:COMPUTERNAME.xml")
    
    $fileExists = Get-Item $additionalConfigurationsInputFileName -ErrorAction SilentlyContinue
    If ($fileExists -eq $null)
    {
        ##Now try domain specific
        $additionalConfigurationsInputFileName = ($currentPath + "\$fileNamePrefix-$env:USERDOMAIN.xml")

        $fileExists = Get-Item $additionalConfigurationsInputFileName -ErrorAction SilentlyContinue
        If ($fileExists -eq $null)
        {
            ##Just give generic file as all other specific options do not exist
            $additionalConfigurationsInputFileName = ($currentPath + "\$fileNamePrefix")
        }
    }
    return $additionalConfigurationsInputFileName
}
Hope this helps.
Coordinator
Jun 3, 2013 at 6:12 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Jun 4, 2013 at 3:31 PM
Hi guys,

What I generally do to avoid this issue is provision Central Administration on all of the WFEs. This approach is the best practice in any case, http://sharepoint.microsoft.com/Blogs/fromthefield/Lists/Posts/Post.aspx?ID=60


Thanks,
Ivan
Jun 4, 2013 at 3:37 PM
Best practice to run CA on more than 1 front-end? Never heard of that...in fact, I have heard the opposite...


Rick Allford | (832) 794-7613




Jun 4, 2013 at 3:53 PM
rickallford wrote:
Best practice to run CA on more than 1 front-end? Never heard of that...in fact, I have heard the opposite... Rick Allford | (832) 794-7613 SharePoint Blog | LinkedIn
http://www.harbar.net/articles/spca.aspx
"Running Central Administration on more than one server in the farm is 100% supported, and indeed a recommended best practice."

Where have you heard otherwise?
Jun 4, 2013 at 4:21 PM
Well... first, the articles you are referring to are 5.5 years old...and was not written by the MS SharePoint team. Best Practices, to my knowledge are published by the manufacturer to support designed services/features.

My point is that by deploying multiple CA's, you could potentially run into a scenario where multiple admins are applying changes to the same services at the same time...sending the farm into an unknown state..

I am not stating that 1 CA instance is best practice, I am just saying that I have spoken with a few Masters who have brought up that fact.

Sorry for the contention


Rick Allford | (832) 794-7613




Jun 4, 2013 at 4:37 PM
I am always up for a good debate :)

While I agree the articles are old, fundamentally SharePoint has not changed.

Your point on multiple admins being able to apply changes doesn't apply. As this scenario can and does occur with a single CA Instance. This can also occur while using custom solutions or PowerShell. SharePoint has built in protection for this scenario, we have all see the error "An update conflict has occurred, and you must re-try this action".

Thanks,
Ivan
Jun 4, 2013 at 7:13 PM
Hey guys,

Rick's right on this score. We used to tell folks to put CA on at least more than one server, but we stopped advising that shortly after 2010 rtm.

These days in PFE we advise customers to provision CA on a single server in most cases because its a 10 minute process to provision it on a new server if you lose the original.

That's based on three years in the field as a PFE. We can of course debate in the relative (and miniscule) pros and cons if either, but the original question was around "best practices" / recommendations from MSFT ... And in that much at least I can clarify.

Ultimately it just doesn't matter that much from anything beyond a manageability perspective. If the extra app pool used up the last if your free memory you had bigger problems to start with :).

Martin Ballard
MSFT PFE

Sent from my Windows Phone

From: [email removed]
Sent: ‎6/‎4/‎2013 9:21 AM
To: [email removed]
Subject: Re: Errror "There are other servers specified as farm members in" [autospinstaller:390039]

From: rickallford

Well... first, the articles you are referring to are 5.5 years old...and was not written by the MS SharePoint team. Best Practices, to my knowledge are published by the manufacturer to support designed services/features.

My point is that by deploying multiple CA's, you could potentially run into a scenario where multiple admins are applying changes to the same services at the same time...sending the farm into an unknown state..

I am not stating that 1 CA instance is best practice, I am just saying that I have spoken with a few Masters who have brought up that fact.

Sorry for the contention


Rick Allford | (832) 794-7613




Jun 19, 2014 at 11:41 AM
Hello,

I just got this error. I fixed it copying psexe.exe in the AutoSPInstaller folder.

Nicolas
Oct 15, 2014 at 10:42 PM
I also want to chime in on what cerbair said, that I also fixed it by copying and pasting psexec.exe into the AutoSPIstaller folder, but I also had to "Unblock" the file so that it could be ran.
Feb 14, 2015 at 3:03 AM
I got this error when trying to use a poorly adapted config.xml file, the block of xml with services in it had "true" instead of "localhost", once I changed it over to localhost it worked fine:
<Services>
            <SandboxedCodeService Start="false" />
            <!-- The UpdateAccount attribute will set the Claims To Windows Token Service (C2WTS) to run under an account other than the default Local System (the general spservice account), and thus avoid a Health Analyzer warning. However it might break things like PowerPivot and Excel Services so best bet is to leave it "false". -->
            <ClaimsToWindowsTokenService Start="false" UpdateAccount="false" />
            <SMTP Install="false" />
            <OutgoingEmail Configure="true">
                <SMTPServer></SMTPServer>
                <EmailAddress></EmailAddress>
                <ReplyToEmail></ReplyToEmail>
            </OutgoingEmail>
            <IncomingEmail Start="localhost" /> <!-- These had "true" values -->
            <!-- DistributedCache (SharePoint 2013 only) - Start should never be set to "false", only either "true" for ALL servers (usually not recommended either), or a comma-delimited list of specific servers (maximum 4 cache host servers per farm). -->
            <DistributedCache Start="localhost" /> <!-- These had "true" values -->
            <!-- As a general rule WorkflowTimer - Start should never be set to "false", only either "true" for all servers, or a comma-delimited list of specific servers.
                 Normally you would specify the same servers to provision WorkflowTimer as you would FoundationWebApplication below. -->
            <WorkflowTimer Start="localhost" /> <!-- These had "true" values -->
            <!-- As a general rule FoundationWebApplication - Start should never be set to "false", only either "true" for all servers, or a comma-delimited list of specific WFE servers.
                 *Note* if you want to remotely install dedicated WFEs in your farm (i.e. RemoteInstall Enable="true") you should name the servers here, in a comma separated list - e.g. Start="WFE1,WFE2,WFEx" -->
            <FoundationWebApplication Start="localhost" /> <!-- These had "true" values -->
        </Services>