Quantcast
Channel: AutoSPInstaller
Viewing all 2279 articles
Browse latest View live

New Post: Re-Using AutoSPInstaller capabilities

$
0
0
I found that I could very easily re-use the internal capabilities of ASPI by using the following process using the following to perform service creation of the Service Creation functions included in ASPI.

I keep copies of all of the XML files used for ASPI in the same location with ASPI Scripts

Create a PowerShell script like below:
$CN =  $env:COMPUTERNAME

$path="\\MyServerSource\sp\AutoSPInstaller"
[xml] $xmlinput = (Get-Content " $path\AutoSPInstallerInput- $cn.xml") -replace ("localhost",  $cn)

#Region Source External Functions
. " $path\AutoSPInstallerFunctions.ps1"
. " $path\AutoSPInstallerFunctionsCustom.ps1"
#EndRegion

#Insert a command like the following below
ConfigureSandboxedCodeService $xmlinput
Run the PowerShell script and it will build the service exactly as configured in the XML File. If database specified in the XML input file already exists it will attach the database to the service when it creates it.

If you need to create a second instance of a service, you would need a copy of the XML input file and make appropriate changes to the script to read the secondary input file.

This compels me to keep the XML up to date with my configuration. It will still only create/Configure the services if it is specified to be installed in the input XML file.

Brian, what are your thoughts about this?

New Post: Re-Using AutoSPInstaller capabilities

New Post: Running AutoSPInstaller multiple times

$
0
0
So I am still trying to get things to work (new install of Sharepoint 2013 and first time using the AutoSPInstaller). Mostly I am finding I have entered things wrong and thus break things. This last time I hit a message stating that the sp_services account could not be found.

One part I am wondering is if the script is able to be run a second time to make the configuration changes or if I need to delete everything (databases) and then try it again? I am running into the message "New-SPManagedAccount : Account kcs.com\SP_Services has already been registered."

All that said. I really like this program/scripts. As I can see it being really nice to test out the install and then try out SharePoint 2013 until we are comfortable with it and then blow it all away and start over.

New Post: Running AutoSPInstaller multiple times

$
0
0
Hi,

AutoSPInstaller can be re-ran as many times as you like. Depending on the mistake you might have to delete the object that was created incorrectly then re-run the script. If you're unsure what when wrong, you can disconnect the farm using psconfig and delete the databases, then re-run the script.


Have a good one,
Ivan

New Post: Running AutoSPInstaller multiple times

$
0
0
Ivan, Thanks for the response. I am surprised that AutoSPInstaller can be re-run multiple times and I am running into these issues. I don't know what would be different on my system then what other people have. Just to set the stage a bit better: I am trying to install SharePoint 2013 on Server 2012 R2 with SQL 2014 also on Server 2012

When I try to rerun the scripts I get the following message:


  • Adding Managed Accounts...
    • Account "kcs.com\SP_Services:
    • Creating local profile for kcs.com\SP_Services...
    • Adding to local Admins (temporarily)...Done.
    • Removing from local Admins...Done.
    • Done.
    • Registering managed account kcs.com\SP_Services...
      New-SPManagedAccount : Account kcs.com\SP_Services has already been registered.
      At \kcs.com\it\installs\Sharepoint\SP2013\AutoSPInstaller\SP\AutoSPInstaller\AutoSPInstallerFunctions.ps1:2076 char:17
  • New-SPManagedAccount -Credential $credAccount | Out-Null
  • ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    • CategoryInfo : InvalidData: (Microsoft.Share...wManagedAccount:SPCmdletNewManagedAccount) [New-SPManage
      dAccount], InvalidOperationException
    • FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletNewManagedAccount

  • Script halted!
Exception : System.Management.Automation.RuntimeException: - Failed to create managed account
TargetObject : - Failed to create managed account
CategoryInfo : OperationStopped: ( - Failed to create managed account:String) [], RuntimeException
FullyQualifiedErrorId : - Failed to create managed account
ErrorDetails :
InvocationInfo : System.Management.Automation.InvocationInfo
ScriptStackTrace : at AddManagedAccounts, \kcs.com\it\installs\Sharepoint\SP2013\AutoSPInstaller\SP\AutoSPInstall
                    er\AutoSPInstallerFunctions.ps1: line 2077
                    at Setup-Farm, \\kcs.com\it\installs\Sharepoint\SP2013\AutoSPInstaller\SP\AutoSPInstaller\AutoS
                    PInstallerMain.ps1: line 203
                    at <ScriptBlock>, \\kcs.com\it\installs\Sharepoint\SP2013\AutoSPInstaller\SP\AutoSPInstaller\Au
                    toSPInstallerMain.ps1: line 403
                    at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {}
PSMessageDetails :

Where as when I roll back to a snapshot after sharepoint was installed and is waiting to be configured I can get to the provisioning of the Service Applications. Where I get this message:

  • Provisioning State Service Application...
  • Creating State Service Application Proxy...

- Done creating State Service Application.


  • Provisioning Managed Metadata Service Application
  • Managed Account kcs.com\SP_Services not found
    At \kcs.com\it\installs\Sharepoint\SP2013\AutoSPInstaller\SP\AutoSPInstaller\AutoSPInstallerFunctions.ps1:2108 char:41
  • If ($managedAccountGen -eq $null) { Throw " - Managed Account $($spservice.u ...
  • ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    • CategoryInfo : OperationStopped: ( - Managed Acco...vices not found:String) [], RuntimeException
    • FullyQualifiedErrorId : - Managed Account kcs.com\SP_Services not found

  • Script halted!
  • Error provisioning the Managed Metadata Service Application
I really don't get why it is coming up since the Managed Services Account does exist and was used/validated earlier in the process.

New Post: Running AutoSPInstaller multiple times

$
0
0
Ok to make life more fun. Now after the weekend the Managed MetaData Service App installs correctly. The only change I made was to reduce the password length from 20 characters to 12 characters.

New Post: Running AutoSPInstaller multiple times

$
0
0
Yet another interesting quirk.

using the account name domain.com\name works for most things but I was running into errors with the MetaData and UPS services but now that I changed it to domain\name it is installing those services without any issues.

New Post: Unable to retrieve topology component health states.

$
0
0
If you are assigning search roles/components to different servers, then you need to make sure that you provision the enterprise search to all of those servers (see bold below).

For example
<EnterpriseSearchService Provision="__LGLVSPP01-APP03,LGLVSPP01-IDX02,LGLVSPP01-APP03__" ContactEmail="" ConnectionTimeout="60" AcknowledgementTimeout="60" ProxyType="Default" IgnoreSSLWarnings="false" InternetIdentity="Mozilla/4.0 (compatible; MSIE 4.01; Windows NT; MS Search 6.0 Robot)" CustomIndexLocation="c:\SearchIndex" PerformanceLevel="PartlyReduced" ShareName="SearchIndex">
   
<EnterpriseSearchServiceApplication Name="Search Service Application"
    FailoverDatabaseServer=""
    Partitioned="false"
    Partitions="1"
    SearchServiceApplicationType="Regular"
    ContentAccessAccount="CRAWL-ACCOUNT-NAME"
    ContentAccessAccountPassword="CRAWL-ACCOUNT-PASSWORD">
    <Database>Removed for brevity</Database>
    <ApplicationPool Name="SharePoint Search Application Pool" />

    <CrawlComponent>
    <Server Name="LGLVSPP01-APP03" />
    </CrawlComponent>
    <QueryComponent>
    <Server Name="LGLVSPP01-IDX02" />
    </QueryComponent>
    <!-- You should specify all the servers you listed in QueryComponent in the SearchQueryAndSiteSettingsServers node below as well -->
    <SearchQueryAndSiteSettingsServers>
    <Server Name="LGLVSPP01-APP03" />
    <Server Name="LGLVSPP01-IDX02" />
    </SearchQueryAndSiteSettingsServers>
    <!-- You can only run the AdminComponent on one server per Search Service App in a SP2010 farm, so only list one server here unless you are installing SharePoint 2013 and need multiple Admin components. -->
    <AdminComponent>
    <Server Name="LGLVSPP01-APP03" />
    <ApplicationPool Name="SharePoint Search Application Pool" />
    </AdminComponent>
    <!-- IndexComponent is only required for SP2013 -->
    <IndexComponent>
    <Server Name="LGLVSPP01-IDX02" />
    </IndexComponent>
    <!-- ContentProcessingComponent is only required for SP2013 -->
    <ContentProcessingComponent>
    <Server Name="LGLVSPP01-APP03" />
    </ContentProcessingComponent>
    <!-- AnalyticsProcessingComponent is only required for SP2013 -->
    <AnalyticsProcessingComponent>
    <Server Name="LGLVSPP01-APP03" />
    </AnalyticsProcessingComponent>
    <Proxy Name="Search Service Application" Partitioned="false">
    <ProxyGroup Name="Default" />
    </Proxy>
    <!-- SearchCenterUrl is for SharePoint 2013 only and is used to set the global search center URL per http://autospinstaller.codeplex.com/workitem/18944. 
     The url you enter MUST end with /Pages or a localized variant of it (i.e. /Seiten in German, /Paginas in Dutch) in order for it to work correctly from MySites. 
     Do not add a trailing slash. i.e.: https://search.zomers.eu/Pages when your Search Center site collection is deployed as a host named site collection to https://search.zomers.eu -->
    <SearchCenterUrl>https://internal.company.com/SearchCenter/Pages</SearchCenterUrl>
</EnterpriseSearchServiceApplication>

New Post: Search Application Topology - Unable to retrieve topology component health states

$
0
0
If you are assigning search roles/components to different servers, then you need to make sure that you provision the enterprise search to all of those servers (see bold below).

For example
<EnterpriseSearchService Provision="__LGLVSPP01-APP03,LGLVSPP01-IDX02,LGLVSPP01-APP03__" ContactEmail="" ConnectionTimeout="60" AcknowledgementTimeout="60" ProxyType="Default" IgnoreSSLWarnings="false" InternetIdentity="Mozilla/4.0 (compatible; MSIE 4.01; Windows NT; MS Search 6.0 Robot)" CustomIndexLocation="c:\SearchIndex" PerformanceLevel="PartlyReduced" ShareName="SearchIndex">
   
<EnterpriseSearchServiceApplication Name="Search Service Application"
    FailoverDatabaseServer=""
    Partitioned="false"
    Partitions="1"
    SearchServiceApplicationType="Regular"
    ContentAccessAccount="CRAWL-ACCOUNT-NAME"
    ContentAccessAccountPassword="CRAWL-ACCOUNT-PASSWORD">
    <Database>Removed for brevity</Database>
    <ApplicationPool Name="SharePoint Search Application Pool" />

    <CrawlComponent>
    <Server Name="LGLVSPP01-APP03" />
    </CrawlComponent>
    <QueryComponent>
    <Server Name="LGLVSPP01-IDX02" />
    </QueryComponent>
    <!-- You should specify all the servers you listed in QueryComponent in the SearchQueryAndSiteSettingsServers node below as well -->
    <SearchQueryAndSiteSettingsServers>
    <Server Name="LGLVSPP01-APP03" />
    <Server Name="LGLVSPP01-IDX02" />
    </SearchQueryAndSiteSettingsServers>
    <!-- You can only run the AdminComponent on one server per Search Service App in a SP2010 farm, so only list one server here unless you are installing SharePoint 2013 and need multiple Admin components. -->
    <AdminComponent>
    <Server Name="LGLVSPP01-APP03" />
    <ApplicationPool Name="SharePoint Search Application Pool" />
    </AdminComponent>
    <!-- IndexComponent is only required for SP2013 -->
    <IndexComponent>
    <Server Name="LGLVSPP01-IDX02" />
    </IndexComponent>
    <!-- ContentProcessingComponent is only required for SP2013 -->
    <ContentProcessingComponent>
    <Server Name="LGLVSPP01-APP03" />
    </ContentProcessingComponent>
    <!-- AnalyticsProcessingComponent is only required for SP2013 -->
    <AnalyticsProcessingComponent>
    <Server Name="LGLVSPP01-APP03" />
    </AnalyticsProcessingComponent>
    <Proxy Name="Search Service Application" Partitioned="false">
    <ProxyGroup Name="Default" />
    </Proxy>
    <!-- SearchCenterUrl is for SharePoint 2013 only and is used to set the global search center URL per http://autospinstaller.codeplex.com/workitem/18944. 
     The url you enter MUST end with /Pages or a localized variant of it (i.e. /Seiten in German, /Paginas in Dutch) in order for it to work correctly from MySites. 
     Do not add a trailing slash. i.e.: https://search.zomers.eu/Pages when your Search Center site collection is deployed as a host named site collection to https://search.zomers.eu -->
    <SearchCenterUrl>https://internal.company.com/SearchCenter/Pages</SearchCenterUrl>
</EnterpriseSearchServiceApplication>

Commented Issue: STS#0 Template Not Creating Membership Groups with AutoSPInstaller [20605]

$
0
0
With my XML for AutoSPInstaller I create 6 Web Applications - 4 of these are created using the STS#0 template. Each has XML like this:

```
<WebApplication type="Other" name="Site Name" applicationPool="ConnectApplication Pool" url="https://SiteName.corp.company.com" port="443" UseHostHeader="true" AddURLToLocalIntranetZone="true" GrantCurrentUserFullControl="false" useClaims="true" useBasicAuthentication="false" useOnlineWebPartCatalog="false">
<Database>
<Name>Content_SiteName</Name>
<DBServer />
<DBAlias Create="false" DBInstance="SERVER\INSTANCE" DBPort="" />
</Database>
<ManagedPaths />
<SiteCollections>
<SiteCollection siteUrl="https://SiteName.corp.Company.com" HostNamedSiteCollection="false" Owner="Company\james" Name="SiteName" Description="Site Name" SearchUrl="https://portal.corp.company.com/search" CustomTemplate="false" Template="STS#0" LCID="1033" Locale="en-us" Time24="false" />
</SiteCollections>
</WebApplication>

```

I'll also Clarify and say that all 4 other sites are categorized as WebApplication type "Other" - not sure if that has any bearing.

Under Site Settings > People and Groups - None of the site Have the usual SharePoint security groups created for them.

* _SiteName_ Owners
* _SiteName_ Members
* _SiteName_ Visitors

Instead There is only one security group listed - __Excel Services Viewers__ - Why it picked this I have no idea

After AutoSPInstaller is done If I create a Site Collection manually using STS#0 (Team Site) It does get the security groups. Also, if I delete the site collection and recreate it, it gets the expected groups.

I can supply the complete XML config file if it helps.
Comments: ** Comment from web user: webguynj **

BTW, at a core level, I have solved this, but not sure how to address inside of ASPI.

SharePoint does not by default create SharePoint groups for a site. You need to do this explicitly.

```
$site = New-SPSite -Url $siteURL -OwnerAlias $ownerAlias -SecondaryOwner $env:USERDOMAIN\$env:USERNAME -ContentDatabase $siteDatabase -Description $siteCollectionName -Name $siteCollectionName -Language $LCID @templateSwitch @hostHeaderWebAppSwitch -ErrorAction Stop

#Add this code
$primaryUser = $site.RootWeb.EnsureUser($ownerAlias)
$secondaryUser = $site.RootWeb.EnsureUser($env:USERDOMAIN\$env:USERNAME)
$title = $site.RootWeb.title
$site.RootWeb.CreateDefaultAssociatedGroups($primaryUser, $secondaryUser, $title)
#End Add this Code
```
This should ensure that the Owners, Members and Visitors groups are created no matter what template is used to create the site collections

Created Unassigned: Problem with Provisioning Enterprise Search [21207]

$
0
0
I am using the extracted XML below to provision Enterprise Search on a server farm with 3 WFE and 9 Services server (4 are search).

At the end of the Day I wind up with two (2) Search topologies and only one has server components(and it is 'inactive'). On the two (2) Index and Content Query servers (08 & 09) the Search Host controller fails to start, and Services are never provisioned on these servers either. Yet ASPI never reports an error.

I'm still digging deeper, but I can see that the Search Service account has not been given and permissions to the DataDir either by file system permissions or Local Admin.

[TechNet Planning for Search says](http://technet.microsoft.com/en-us/library/cc263445(v=office.15).aspx)
* Full Control access to the index partitions on the query servers

ASPI doesn't explicitly grant this anywhere. Is this an Oversight?

```
<DataDir>D:\SharePointData</DataDir>

<ManagedAccount CommonName="SearchService">
<Username>domain.com\SVC_SP13PRDSrchSvc</Username>
<Password>P@ssword1</Password>
</ManagedAccount>

<EnterpriseSearchService Provision="TOTSPSVCPRD06,TOTSPSVCPRD07" ContactEmail="me@domain.com" ConnectionTimeout="60" AcknowledgementTimeout="60" ProxyType="Default" IgnoreSSLWarnings="false" InternetIdentity="Mozilla/4.0 (compatible; MSIE 4.01; Windows NT; MS Search 6.0 Robot)" CustomIndexLocation="" PerformanceLevel="PartlyReduced" ShareName="SearchIndex">
<EnterpriseSearchServiceApplications>
<EnterpriseSearchServiceApplication Name="Search Service Application" FailoverDatabaseServer="" Partitioned="false" Partitions="1" SearchServiceApplicationType="Regular" ContentAccessAccount="domain.com\SVC_SP13PRDSrchCnt" ContentAccessAccountPassword="P@ssword1">
<Database>
<Name>Search</Name>
<DBServer />
<DBAlias Create="false" DBInstance="localhost" DBPort="" />
</Database>
<ApplicationPool Name="SharePoint Search Application Pool" />
<CrawlComponent>
<Server Name="SERVER06" />
<Server Name="SERVER07" />
</CrawlComponent>
<QueryComponent>
<Server Name="SERVER08" />
<Server Name="SERVER09" />
</QueryComponent>
<SearchQueryAndSiteSettingsServers>
<Server Name="SERVER06" />
<Server Name="SERVER07" />
</SearchQueryAndSiteSettingsServers>
<AdminComponent>
<Server Name="SERVER06" />
<Server Name="SERVER07" />
<ApplicationPool Name="SharePoint Search Application Pool" />
</AdminComponent>
<IndexComponent>
<Server Name="SERVER08" />
<Server Name="SERVER09" />
</IndexComponent>
<ContentProcessingComponent>
<Server Name="SERVER06" />
<Server Name="SERVER07" />
</ContentProcessingComponent>
<AnalyticsProcessingComponent>
<Server Name="SERVER06" />
<Server Name="SERVER07" />
</AnalyticsProcessingComponent>
<Proxy Name="Search Service Application" Partitioned="false">
<ProxyGroup Name="Default" />
</Proxy>
<SearchCenterUrl>http://search.domain.com</SearchCenterUrl>
</EnterpriseSearchServiceApplication>
</EnterpriseSearchServiceApplications>
</EnterpriseSearchService>

```

Commented Unassigned: Problem with Provisioning Enterprise Search [21207]

$
0
0
I am using the extracted XML below to provision Enterprise Search on a farm with search topology split onto four (4) servers.

After running ASPO I wind up with two (2) Search topologies and only one has Search components (and it is 'inactive'). On the two (2) Index and Content Query servers (08 & 09) the Search Host controller fails to start, and Services are never provisioned on these servers either. Yet ASPI never reports an error.

I'm still digging deeper, but I can see that the Search Service account has not been given any permissions to the DataDir either by file system permissions or Local Admin.

[TechNet Planning for Search says](http://technet.microsoft.com/en-us/library/cc263445(v=office.15).aspx)
* Full Control access to the index partitions on the query servers

ASPI doesn't explicitly grant this anywhere. Is this an Oversight?

```
<DataDir>D:\SharePointData</DataDir>

<ManagedAccount CommonName="SearchService">
<Username>domain.com\SVC_SP13PRDSrchSvc</Username>
<Password>P@ssword1</Password>
</ManagedAccount>

<EnterpriseSearchService Provision="TOTSPSVCPRD06,TOTSPSVCPRD07" ContactEmail="me@domain.com" ConnectionTimeout="60" AcknowledgementTimeout="60" ProxyType="Default" IgnoreSSLWarnings="false" InternetIdentity="Mozilla/4.0 (compatible; MSIE 4.01; Windows NT; MS Search 6.0 Robot)" CustomIndexLocation="" PerformanceLevel="PartlyReduced" ShareName="SearchIndex">
<EnterpriseSearchServiceApplications>
<EnterpriseSearchServiceApplication Name="Search Service Application" FailoverDatabaseServer="" Partitioned="false" Partitions="1" SearchServiceApplicationType="Regular" ContentAccessAccount="domain.com\SVC_SP13PRDSrchCnt" ContentAccessAccountPassword="P@ssword1">
<Database>
<Name>Search</Name>
<DBServer />
<DBAlias Create="false" DBInstance="localhost" DBPort="" />
</Database>
<ApplicationPool Name="SharePoint Search Application Pool" />
<CrawlComponent>
<Server Name="SERVER06" />
<Server Name="SERVER07" />
</CrawlComponent>
<QueryComponent>
<Server Name="SERVER08" />
<Server Name="SERVER09" />
</QueryComponent>
<SearchQueryAndSiteSettingsServers>
<Server Name="SERVER06" />
<Server Name="SERVER07" />
</SearchQueryAndSiteSettingsServers>
<AdminComponent>
<Server Name="SERVER06" />
<Server Name="SERVER07" />
<ApplicationPool Name="SharePoint Search Application Pool" />
</AdminComponent>
<IndexComponent>
<Server Name="SERVER08" />
<Server Name="SERVER09" />
</IndexComponent>
<ContentProcessingComponent>
<Server Name="SERVER06" />
<Server Name="SERVER07" />
</ContentProcessingComponent>
<AnalyticsProcessingComponent>
<Server Name="SERVER06" />
<Server Name="SERVER07" />
</AnalyticsProcessingComponent>
<Proxy Name="Search Service Application" Partitioned="false">
<ProxyGroup Name="Default" />
</Proxy>
<SearchCenterUrl>http://search.domain.com</SearchCenterUrl>
</EnterpriseSearchServiceApplication>
</EnterpriseSearchServiceApplications>
</EnterpriseSearchService>

```
Comments: ** Comment from web user: IvanJosipovic **

Try this:
<EnterpriseSearchService Provision="Server6,Server7,Server8,Server9" ContactEmail="me@domain.com" ConnectionTimeout="60" AcknowledgementTimeout="60" ProxyType="Default" IgnoreSSLWarnings="false" InternetIdentity="Mozilla/4.0 (compatible; MSIE 4.01; Windows NT; MS Search 6.0 Robot)" CustomIndexLocation="" PerformanceLevel="PartlyReduced" ShareName="SearchIndex">

Ivan

Commented Unassigned: Problem with Provisioning Enterprise Search [21207]

$
0
0
I am using the extracted XML below to provision Enterprise Search on a farm with search topology split onto four (4) servers.

After running ASPO I wind up with two (2) Search topologies and only one has Search components (and it is 'inactive'). On the two (2) Index and Content Query servers (08 & 09) the Search Host controller fails to start, and Services are never provisioned on these servers either. Yet ASPI never reports an error.

I'm still digging deeper, but I can see that the Search Service account has not been given any permissions to the DataDir either by file system permissions or Local Admin.

[TechNet Planning for Search says](http://technet.microsoft.com/en-us/library/cc263445(v=office.15).aspx)
* Full Control access to the index partitions on the query servers

ASPI doesn't explicitly grant this anywhere. Is this an Oversight?

```
<DataDir>D:\SharePointData</DataDir>

<ManagedAccount CommonName="SearchService">
<Username>domain.com\SVC_SP13PRDSrchSvc</Username>
<Password>P@ssword1</Password>
</ManagedAccount>

<EnterpriseSearchService Provision="TOTSPSVCPRD06,TOTSPSVCPRD07" ContactEmail="me@domain.com" ConnectionTimeout="60" AcknowledgementTimeout="60" ProxyType="Default" IgnoreSSLWarnings="false" InternetIdentity="Mozilla/4.0 (compatible; MSIE 4.01; Windows NT; MS Search 6.0 Robot)" CustomIndexLocation="" PerformanceLevel="PartlyReduced" ShareName="SearchIndex">
<EnterpriseSearchServiceApplications>
<EnterpriseSearchServiceApplication Name="Search Service Application" FailoverDatabaseServer="" Partitioned="false" Partitions="1" SearchServiceApplicationType="Regular" ContentAccessAccount="domain.com\SVC_SP13PRDSrchCnt" ContentAccessAccountPassword="P@ssword1">
<Database>
<Name>Search</Name>
<DBServer />
<DBAlias Create="false" DBInstance="localhost" DBPort="" />
</Database>
<ApplicationPool Name="SharePoint Search Application Pool" />
<CrawlComponent>
<Server Name="SERVER06" />
<Server Name="SERVER07" />
</CrawlComponent>
<QueryComponent>
<Server Name="SERVER08" />
<Server Name="SERVER09" />
</QueryComponent>
<SearchQueryAndSiteSettingsServers>
<Server Name="SERVER06" />
<Server Name="SERVER07" />
</SearchQueryAndSiteSettingsServers>
<AdminComponent>
<Server Name="SERVER06" />
<Server Name="SERVER07" />
<ApplicationPool Name="SharePoint Search Application Pool" />
</AdminComponent>
<IndexComponent>
<Server Name="SERVER08" />
<Server Name="SERVER09" />
</IndexComponent>
<ContentProcessingComponent>
<Server Name="SERVER06" />
<Server Name="SERVER07" />
</ContentProcessingComponent>
<AnalyticsProcessingComponent>
<Server Name="SERVER06" />
<Server Name="SERVER07" />
</AnalyticsProcessingComponent>
<Proxy Name="Search Service Application" Partitioned="false">
<ProxyGroup Name="Default" />
</Proxy>
<SearchCenterUrl>http://search.domain.com</SearchCenterUrl>
</EnterpriseSearchServiceApplication>
</EnterpriseSearchServiceApplications>
</EnterpriseSearchService>

```
Comments: ** Comment from web user: webguynj **

Hmm. Will try first thing in the morning...

New Post: Add Users or Groups to Farm Administrators group within Central Admin.

$
0
0
I would find it helpful if the script would automatically add users and group into the Farm Administrators group within Central Admin.

New Post: Disable UAC, AutoLogon, Replicate Check, GenerateConfig - custom functions

$
0
0
These are nice. Which have been incorporated and which functions have not?

Commented Unassigned: After Installing SP2013 with SP1 Every so often Search fails due to the members of SPSearchDBAdmin being removed from the database role [21167]

$
0
0
After Installing SP2013 with SP1 Every so often Search fails due to the members of SPSearchDBAdmin being removed from the database role and not being added backin.

This happens about once a week.

Anybody any ideas.

I have seen a few blogs about this and all they say is add them back in when they go which is no good on a production system.

Thanks

Nigel
Comments: ** Comment from web user: brianlala **

Nigel, have you confirmed whether this bug still happens when *not* using AutoSPInstaller? Or do you suspect AutoSPInstaller to somehow be the cause?

Remember this forum is for AutoSPInstaller-specific issues :)

Brian

Commented Unassigned: After Installing SP2013 with AutoSPInstaller Set-SPEnterpriseSearchFileFormat fails with The processing of files of type 'pdf' is already supported by the parsing system [21166]

$
0
0
After Installing SP2013 with AutoSPInstaller Set-SPEnterpriseSearchFileFormat fails with The processing of files of type 'pdf' is already supported by the parsing system.

Anybody got any ideas why this is happening ?

Regards

Nigel
Comments: ** Comment from web user: brianlala **

Hey Nigel - are you reporting what you believe is an issue with AutoSPInstaller, or just looking to start a [discussion](http://autospinstaller.codeplex.com/discussions)?

Brian

Commented Unassigned: Syntax issue with "Installing SMTP Windows feature in a separate PowerShell window" command? [21161]

$
0
0
While reviewing the code [AutoSPInstallerMain.ps1, line 250] using NotePad++, the editor's syntax parser seems to have an issue with the "back quote / semi-colon" delimiter in the following statement:

Start-Process -FilePath "$PSHOME\powershell.exe" -Verb Runas -ArgumentList "-Command `". $env:dp0\AutoSPInstallerFunctions.ps1`; InstallSMTP (Get-Content $inputFile); Start-Sleep 5" -Wait

Adding another quote after the back quote characters makes NotePad++ happy:

...AutoSPInstallerFunctions.ps1`"; InstallSMTP...

But, I am unsure if adding that quote maintains the integrity of what the command was intended to do.
Comments: ** Comment from web user: brianlala **

Not sure I would trust NotePad++ over what I use (PowerGUI - which has no issue with the syntax). Anyhow, I just checked with my NotePad++ and it didn't seem to have a problem...

Going to close this issue unless it's actually deemed to cause a problem in execution (so far it hasn't) :)

Cheers
Brian

Closed Unassigned: Syntax issue with "Installing SMTP Windows feature in a separate PowerShell window" command? [21161]

$
0
0
While reviewing the code [AutoSPInstallerMain.ps1, line 250] using NotePad++, the editor's syntax parser seems to have an issue with the "back quote / semi-colon" delimiter in the following statement:

Start-Process -FilePath "$PSHOME\powershell.exe" -Verb Runas -ArgumentList "-Command `". $env:dp0\AutoSPInstallerFunctions.ps1`; InstallSMTP (Get-Content $inputFile); Start-Sleep 5" -Wait

Adding another quote after the back quote characters makes NotePad++ happy:

...AutoSPInstallerFunctions.ps1`"; InstallSMTP...

But, I am unsure if adding that quote maintains the integrity of what the command was intended to do.
Comments: Can't confirm issue.

Commented Feature: Distributed Cache starting (muli-server) [21155]

$
0
0
Hi,

I have noticed that whenever I use the script to create a multi-server farm the distributed cache service fails to start. The script returns a pass however the service does not actually start. Digging into it I have found that the windows firewall rule for ICMP incoming (under file and print sharing) must be enabled as AppFabric uses ICMP to check the state of servers before enabling the service.

Can the script be amended to enable these rules 1 for IPv4 and 1 for IPv6?
Comments: ** Comment from web user: brianlala **

Interesting... have never run into this problem, nor have I ever had to add Windows Firewall rules to get Distributed Cache working.

Do your network connections get properly detected as Domain networks? Or are they perhaps stuck on "Public"?

Brian

Viewing all 2279 articles
Browse latest View live


Latest Images

<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>