Script for creating SharePoint 2013 Search service application

by Robi 23. September 2015 12:07
Since a lot of people are asking me what is the best way to create seach service application in SharePoint 2013, I decided to share the script I use to create one.   The folowing script is used for the following Search Infrastructure: Server name Type Components WFE 1 Web front end Admin component Query processing component Index component WFE 2 Web front end Admin component Query processing component Index component Index server Application server Crawl component Content processing Admin component Analytics component   You can of course modify the script as needed. Add-PSSnapin Microsoft.SharePoint.PowerShell --EA 0   ## Change these per your environment ## $databaseServerName="dbserver"   ################ search servers in farm ################ $wfe1 = "wfe-1" $wfe2 = "wfe-2" $searchServerName = "index-1" ##########################################################     ################ Search information ################   $saAppPoolName = "Search_AppPool" $appPoolUserName = "" #Enter search service app pool $IndexLocation = "" #Enter location for search Index e.g. I:\Search $usagaDatabaseName="SP2013_SA_Usage" #Modify database name as needed $searchDatabaseName="SP2013_SA_Search" #Modify database name as needed $contactEmail="" #Enter Search contact email $defaultContenAccessAccount="" #Enter content access account $defaultContenAccessAccountPassword=ConvertTo-SecureString -AsPlainText -Force '' #Enter content access account password $windowsService=Get-SPManagedAccount "" #Enter managed account for search services account $windowsServicePassword=ConvertTo-SecureString -AsPlainText -Force '' #Enter password for search services account   ## Service Application Names ## ## Included Usage and Health, as it does get provisioned and if you want to define DB name ## ## Also Usage Proxy Status is stopped which cause Search Application Topology to not find Admin Service ## $searchSAName = "Search_SA" #Modify Search service application name $usageSAName = "UsageHealth_SA" #Modify Usage service application name   ##########################################################     #region Create folders   #Ustvarimo mapo za search index if(!(test-path $IndexLocation)){ New-Item -Path $IndexLocation -ItemType directory } else{ Remove-Item $IndexLocation -Recurse New-Item -Path $IndexLocation -ItemType directory }   #endregion     #region Application pool #Application pool objekt $saAppPool = Get-SPServiceApplicationPool -Identity $saAppPoolName -EA 0 if($saAppPool -eq $null) { Write-Host "Creating Service Application Pool..."   $appPoolAccount = Get-SPManagedAccount -Identity $appPoolUserName -EA 0 if($appPoolAccount -eq $null) { Write-Host "Please supply the password for the Service Account..." $appPoolCred = Get-Credential $appPoolUserName $appPoolAccount = New-SPManagedAccount -Credential $appPoolCred -EA 0 }   $appPoolAccount = Get-SPManagedAccount -Identity $appPoolUserName -EA 0   if($appPoolAccount -eq $null) { Write-Host "Cannot create or find the managed account $appPoolUserName, please ensure the account exists." Exit -1 }   New-SPServiceApplicationPool -Name $saAppPoolName -Account $appPoolAccount -EA 0 > $null      }   #endregion   # region Usage service application Write-Host "Creating Usage Service and Proxy..."   $serviceInstance = Get-SPUsageService   New-SPUsageApplication -Name $usageSAName -DatabaseServer $databaseServerName -DatabaseName $usagaDatabaseName -UsageService $serviceInstance > $null   $usa = Get-SPServiceApplicationProxy | where {$_.TypeName -like "Usage*"} $usa.Provision()   #endregion     #region Start services Create search service application   Write-Host "Creating Search Service and Proxy..."   Write-Host " Starting Services..."   Write-Host "Starting service on wfe1" -ForegroundColor Yellow Start-SPEnterpriseSearchServiceInstance $wfe1 Start-SPEnterpriseSearchQueryAndSiteSettingsServiceInstance $wfe1   Write-Host "Service on wfe1 started" -ForegroundColor green   Write-Host "Starting service on wfe2" -ForegroundColor Yellow Start-SPEnterpriseSearchServiceInstance $wfe2 Start-SPEnterpriseSearchQueryAndSiteSettingsServiceInstance $wfe2 Write-Host "Service on wfe2 started" -ForegroundColor green   Write-Host "Starting service on index server" -ForegroundColor Yellow Start-SPEnterpriseSearchServiceInstance $searchServerName Start-SPEnterpriseSearchQueryAndSiteSettingsServiceInstance $searchServerName Write-Host "Service on index started" -ForegroundColor green   Write-Host " Creating Search Application..." $searchApp = New-SPEnterpriseSearchServiceApplication -Name $searchSAName -ApplicationPool $saAppPoolName -DatabaseServer $databaseServerName -DatabaseName $searchDatabaseName Write-Host "Search Service Application Created"   #endregion   #region Get Initial topology and create clone   $searchInstancewfe1 = Get-SPEnterpriseSearchServiceInstance $wfe1 $searchInstancewfe2 = Get-SPEnterpriseSearchServiceInstance $wfe2 $searchInstanceIndex = Get-SPEnterpriseSearchServiceInstance $searchServerName   write-host "Getting initial topology" $InitialSearchTopology = $searchApp | Get-SPEnterpriseSearchTopology -Active   $ssa = Get-SPEnterpriseSearchServiceApplication   #gets the active search topology from search service application $ssa.ActiveTopology   Write-Host $ssa.ActiveTopology   #To clone the active topology   $clone = $ssa.ActiveTopology.Clone()   #endregion     #region Modify default topology and activate   ############################### Index Server ##################################################################### Write-Host "Starting to configure indexing server" -ForegroundColor Yellow write-host "Creating Admin Component" -ForegroundColor Yellow New-SPEnterpriseSearchAdminComponent –SearchTopology $clone -SearchServiceInstance $searchInstanceIndex write-host -ForegroundColor Green "Admin Component Created"   write-host "Creating Content Processing component" -ForegroundColor Yellow New-SPEnterpriseSearchContentProcessingComponent –SearchTopology $clone -SearchServiceInstance $searchInstanceIndex write-host -ForegroundColor Green "Content Processing component Created"   write-host "Creating Analyticis Processing Component" -ForegroundColor Yellow New-SPEnterpriseSearchAnalyticsProcessingComponent –SearchTopology $clone -SearchServiceInstance $searchInstanceIndex write-host -ForegroundColor Green "Analyticis Processing Component Created"   write-host "Creating Crawl Component" -ForegroundColor Yellow New-SPEnterpriseSearchCrawlComponent –SearchTopology $clone -SearchServiceInstance $searchInstanceIndex write-host -ForegroundColor Green "Crawl Component Created" Write-Host "Index server configured ###################################################################" -ForegroundColor Green   #=============================== Index Server ===================================================================       ############################### WFE1 ############################################################################   Write-Host "Configuring WFE1" -ForegroundColor Yellow New-SPEnterpriseSearchAdminComponent –SearchTopology $clone -SearchServiceInstance $searchInstancewfe1 write-host -ForegroundColor Green "Admin Component Created on WFE1" write-host "Creating Index on WFE1 Component" -ForegroundColor Yellow New-SPEnterpriseSearchIndexComponent –SearchTopology $clone -SearchServiceInstance $searchInstancewfe1 -RootDirectory $IndexLocation write-host -ForegroundColor Green "Index Component on WFE1 Created"   write-host "Creating Query Processing Component on WFE1" -ForegroundColor Yellow New-SPEnterpriseSearchQueryProcessingComponent –SearchTopology $clone -SearchServiceInstance $searchInstancewfe1 write-host -ForegroundColor Green "Query Processing Component on wfe 1 Created"   Write-Host "Search components on WFE1 Configured ###################################################################" -ForegroundColor Green #============================== WFE1 ============================================================================         ############################### WFE2 ############################################################################   Write-Host "Configuring WFE2" -ForegroundColor Yellow New-SPEnterpriseSearchAdminComponent –SearchTopology $clone -SearchServiceInstance $searchInstancewfe2 write-host -ForegroundColor Green "Admin Component Created on WFE1" write-host "Creating Index on WFE2 Component" -ForegroundColor Yellow New-SPEnterpriseSearchIndexComponent –SearchTopology $clone -SearchServiceInstance $searchInstancewfe2 -RootDirectory $IndexLocation write-host -ForegroundColor Green "Index Component on WFE2 Created"   write-host "Creating Query Processing Component on WFE2" -ForegroundColor Yellow New-SPEnterpriseSearchQueryProcessingComponent –SearchTopology $clone -SearchServiceInstance $searchInstancewfe2 write-host -ForegroundColor Green "Query Processing Component on wfe 2 Created"   Write-Host "Search components on WFE2 Configured ###################################################################" -ForegroundColor Green #============================== WFE2 ============================================================================   $clone.Activate()   #endregion     #region Set Active admin component $ssa | get-SPEnterpriseSearchAdministrationComponent | set-SPEnterpriseSearchAdministrationComponent -SearchServiceInstance $searchInstanceIndex   #endregion       #region Create search service proxy Write-Host " Creating Proxy..." $searchAppProxy = New-SPEnterpriseSearchServiceApplicationProxy -Name "$searchSAName Proxy" -SearchApplication $searchSAName > $null #endregion     #region Set default content access account write-host " Setting default content access account..." Set-SPEnterpriseSearchServiceApplication -Identity $searchSAName -DefaultContentAccessAccountName $defaultContenAccessAccount -DefaultContentAccessAccountPassword $defaultContenAccessAccountPassword #endregion     #region Set Windows services account Write-Host " Setting windows service account..." Set-SPEnterpriseSearchService -Identity $searchSAName -ServiceAccount $windowsService.Username -ServicePassword $windowsServicePassword -ContactEmail $contactEmail #endregion   Write-Host " Search Service Application Provisioned" -ForegroundColor Green   #region Delete default inactive topology Write-Host "Getting inactive topology..." $inactive=Get-SPEnterpriseSearchTopology -SearchApplication Search_Sa |Where {$_.state -eq "Inactive"}     Write-Host "Removing Inactive topology..." Remove-SPEnterpriseSearchTopology -Identity $inactive -Confirm:$false #endregion     write-host -foregroundcolor green "################################################################### Search completed ###################################################################"     08. SearchServiceApplication(2).ps1 (10.76 kb)

Tags:

PowerShell | SharePoint | SharePoint 2013

The People picker and domain trusts

by Robi 30. January 2014 21:58
In the last couple of projects on SharePoint I was working with environments, where company was associated with couple of domains. Since SharePoint has to be configure to work in such environments, I decided to introduce the issue on two typical scenarios and explain in what way it is then necessary to set up a SharePoint site, to make it possible to resolve users in people picker from other domains. Scenario 1 – "Two way trust" The characteristic of "Two Way Trust" is that users from domain 1 have rights to access resources in domain 2 and vice versa. This means that users from a domain 1 can read data in the Active Directory of domain 2 and users from a domain 2 can read data from AD in domain 1. This is very important information, since configuration of SharePoint Server depends on these characteristic. Figure 1 shows the scenario where we have set up 2 way trust between the domain 1 and domain 2. In domain 1 SharePoint Server is placed, which can be used by users from domain 1 and domain 2. The Problem, which in this case refers to the People picker is that people picker by default search only in Active Directory domain in which the SharePoint Server is installed. So, if you want to add users from other domains, we need to fix some of the settings on the SharePoint Server. Settings that must be set in this case refers to the entire web application. Of course, these settings cannot be set in the user interface, so it is necessary in this case to open SharePoint 2013 Management Shell and enter a couple of lines of code. $wa = Get-SPWebApplication http://portal.domena1.loc  # List the current values for a web application $wa.PeoplePickerSettings.SearchActiveDirectoryDomains    <# ====================================  Portal web app  ===================================== #>        <####################################    Domain 1  ####################################> $newdomain1 = new-object Microsoft.SharePoint.Administration.SPPeoplePickerSearchActiveDirectoryDomain  ### #### ### Register FQDN ### ### ### $newdomain1.DomainName ='domena1.loc ';  ### #### ### Register netbios name ### ### ### $newdomain1.ShortDomainName ='domena1'; $wa.PeoplePickerSettings.SearchActiveDirectoryDomains.Add($newdomain1)  <####################################    Domain 2  ####################################> $newdomain2= new-object Microsoft.SharePoint.Administration.SPPeoplePickerSearchActiveDirectoryDomain    ### ### ### Register FQDN ### ### ### $newdomain2.DomainName ='domena2.loc';  ### #### ### Register netbios name ### ### ### $newdomain2.ShortDomainName ='domena2';  $wa.PeoplePickerSettings.SearchActiveDirectoryDomains.Add($newdomain2)    $wa.Update () For setting the "People Picker" control, first we need to save the web application object in a new variable. The current value of the variable can be listed with the following command $wa.PeoplePickerSettings. SearchActiveDirectoryDomains. In order to be able to add new values to search other domains, we have to make a new object of type Microsoft. SharePoint. Administration. SPPeoplePickerSearchActiveDirectoryDomain, and then set the value. The first value is the FQDN of the domain and the second value is the NetBIOS name, for a short domain name. The same procedure must be repeated for all the domains that you want to allow in the people picker. At the end we have to, of course, save the changes that are stored in the web application object. We have to repeat the procedure on all web applications on which we want to change the behavior of the people picker, including the Central Administration. Scenario 2 – "a One way trust" »One way trust" is a way of linking domains where one domain trusts another domain. For example, I used a one way trust between domain 1 and domain 2, where domain1 trusts domain 2, while domain 2 does not trust domain 1. To make it simple, we could say that the users from domain 2 can access data in the domain 1 while domain 1 users cannot access the data in the domain 2. Such a scenario is widely used among intranet and extranet environments, where users from the intranet domain can access extranet domain, while the reverse is not possible.    In a scenario where you use one way trust ", we can use the same script that we used in bidirectional trusts, with the difference that you need to provide some sort of access. These parameters are the username and password of the user who will be able to access resources in the domain 2.  <####################################  Creating a password app  ####################################>  Stsadm –o setapppassword –password 'Pa$$w0rd'  # ========================================================  $wa = Get-SPWebApplication http://portal.domena1.loc  # List the current values for a web application $wa.PeoplePickerSettings.SearchActiveDirectoryDomains    <# ====================================  Portal web app  ===================================== #>        <####################################      Domain 1                      ####################################> $newdomain1= new-object Microsoft.SharePoint.Administration.SPPeoplePickerSearchActiveDirectoryDomain  ### #### ### Register FQDN ### ### ### $newdomain1.DomainName ='domena1.loc';  ### #### ### Register netbios name ### ### ### $newdomain1.ShortDomainName ='domena1'; $wa.PeoplePickerSettings.SearchActiveDirectoryDomains.Add($newdomain1)  <####################################      Domain 2                      ####################################> $newdomain2 = new-object Microsoft.SharePoint.Administration.SPPeoplePickerSearchActiveDirectoryDomain  ### ### ### Accounta rights Settings ### ### ### $user="domena2\accountPravice" $pass=convertto-securestring 'Pa$$w0rd' –AsPlainText -Force $credentials=new-object –typename System.Management.Automation.PSCredential –argumentlist $user,$pass $newdomain1.LoginName=$credentials.UserName $newdomain1.SetPassword($credentials.Password)    ### ### ### Register FQDN ### ### ### $newdomain2.DomainName ='domena2.loc';  ### #### ### Register netbios name ### ### ### $newdomain2.ShortDomainName='domena2';  $wa.PeoplePickerSettings.SearchActiveDirectoryDomains.Add($newdomain2)    $wa.Update()  Because in this scenario, the application pool account does not have rights to access resources that are in a domain 2, we need to set the username and password for access to Active Directory objects in domain 2. The first step is to create the app password for storing credentials on all server in our farm. Command Stsadm –o setapppassword –password 'Pa$$w0rd' creates a registry key where app pool account can read credential key from. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0\Secure The next step is to create a connection for each domain specifically and also set up a user account for connecting to the specified domain. For these purpose, you can use the account that synchronize data between SharePoint Server and Active Directory, provided that we have a SharePoint Server and the User Profile Synchronization Service. Otherwise, you can create normal service account, which will be exclusively used for reading data from the specified domain. The last step is to set up application pool account permissions to read AppCredentialKey. AppCredentialKey registry key is limited to certain local server groups and if the permissions are not correctly set up, Event Logs are full of "Registry access is not allowed" errors and users are not getting resolved in the people picker. Users and groups that have access to registry key by default are: System Network Service WSS_Restricted_WPG_V4 Administrators In order to grant access for application pool to the AppCredentialKey, you can add service account to WSS_Restricted_WPG_V4 group. Accounts, which must be in this group are: Application pool account for the web application The Sandbox service account The service account of the Central Administration – provided that it is not in the Administrators group. SharePoint configuration can be quite challenging in some scenarios so I hope that this post will help SharePoint admins ease their work and enhance their understanding of SharePoint. This configuration also applies for SharePoint 2010.  Rob Vončina SharePoint Server MVP

Tags:

SharePoint 2010 | SharePoint 2013 | SharePoint - Administration | PowerShell

Upgrade Video

by Robi 27. August 2013 10:34
For the Ukrainian SharePoint Conference I recorded this video to present it at my session. I decided to make it public now so please, sit back, relax and enjoy it.    Upgrading to SharePoint 2013 Video

Tags:

SharePoint | PowerShell | SharePoint 2013 | SharePoint 2010

Upgrading to SharePoint 2013

by Robi 8. August 2013 09:44
Upgrading from SharePoint 2007 to SharePoint 2010 has been significantly improved and there were no major issues like with upgrading from SharePoint 2003 to SharePoint 2007. Upgrade to SharePoint 2013 has also been vastly improved but it also brings some new stuff that I would like to point out. Figure 1: 5 major steps in upgrade process Every SharePoint upgrade project should consist of the 5 major steps, but I'm not going to discuss what every step of every upgrade project should be. I'm going to concentrate on what is new and how can you actually perform an upgrade. Upgrade methods that are available in SharePoint 2013 upgrade process are or should I say is database attach method. There is no other supported upgrade method in the version to version upgrades. What this means is that you need to establish a side to side farm with your existing SharePoint 2010 environment, as earlier versions of SharePoint are not supported for direct upgrade to SharePoint 2013. If you have an earlier version of SharePoint and you do not want to make additional upgrade steps to SharePoint 2010, you can use 3rd part migration tools as Metalogix, Idera, AvePoint,… Database attach method means backing up you SharePoint 2010 databases, restoring them to you SQL Server for SharePoint 2013 and mounting those to your SharePoint environment. But not every database supports db atttach upgrade from previous version of SharePoint. Support database attach upgradeNot supporting database attach upgradeContent databasesConfiguration databaseProject databasesSearch Index databaseSearch admin databaseSync databaseSocial database Profile database Managed Metadata database Secure store database Firstly, to perform a database attach method for content database we need to create new web application in SharePoint 2013. As a best practice I would recommend removing newly created database, as we are going to attach one. If you have already restored content database to your SQL Server, you can then open SharePoint 2013 Management Shell and test the content database against the newly created web application: Test-SPContentDatabase -Name SP02_WSS_Content_Upgrade -WebApplication http://2013upgrade/ In your PowerShell window you will get a result from your test back. Figure 2: Test-SPContentDatabase You should be aware of upgrade blocking category as if this is set to true, your upgrade process won't be able to complete. If you test your content database to a web application that has a different authentication provider set than your content db, you would get an error like the following: Figure 3: Test-SPContentDatabase against Claims Web Application This may happen if your SharePoint 2010 environment was configured with Classic mode authentication and you created Claims web application in SharePoint 2013, which is the default authentication method. To create classic mode web application in SharePoint 2013 you need to do it in PowerShell using a command similar to this: New-SPWebApplication -Name SP2013_Upgrade -ApplicationPool SP2013Upgrade_AppPool -ApplicationPoolAccount dev\sp2013_app_pool -HostHeader 2013Upgrade -Port 80 -Url http://2013upgrade -DatabaseName SP2013_Content_2013Upgrade -Verbose Once all issues from your test are resolved you can start an upgrade process by using the following command Mount-SPContentDatabase -Name SP02_WSS_Content_Upgrade -WebApplication http://2013upgrade/ -Verbose When command completes, you are notified about the success of you upgrade process. In my case there were some errors thrown because of missing features for Report Server: Figure 4: Mount-SPContenDatabase You can always check progress of your upgrade process in Central administration. So if you go to central admin, Upgrade and Migration, Check upgrade status you will see status of all your previous upgrade sessions with some basic data. Figure 5: Central Admin Check Upgrade Status One of the most important information you can get is where your upgrade log is located. If you go to your logs folder, you will find not only one but 2 log files. One is whole upgrade log file and the other one is just error log file. One of the new things that I must mention here is that log files are now in ULS format, this means that they are easily readable and easier for review. Sample of ULS log is shown here: Figure 6: Upgrade Error Log With database upgrade completed, SharePoint upgrade is not completed yet. In SharePoint 2010 after an upgrade we had to do a so called Visual Upgrade which upgrades visual experience. In SharePoint 2013, we do not have visual upgrade, but we need to do the Deferred Site Collection upgrade. What this means is that site collection upgrades are separated from database upgrades and that every site collection admin can now control when he or she would like their site collection to be upgraded. Before site collection upgrade you actually use SharePoint 2010 binaries and in effect cannot use any new features SharePoint 2013 has to offer. Figure 7: Site collection after database upgrade  After upgrade and when connecting to your upgraded sites you can see that you are still in SharePoint 2010 mode. The only difference you can notice is that there is a red notification bar on top of portal. To be able to use all SharePoint 2013 features you need to do a deferred site collection upgrade, which as mentioned before is a new concept. With that said, there are also two more new concepts    introduced for site collection upgrades which are called Upgrade evaluation site collection and Site Collection Health Checker. Figure 9: Links for Health checks and site collection upgrade Site collection health checks should be run before you try to upgrade site collection. This tool will provide you information about any potential issues and that you can then address before you start upgrading your site collection. Figure 10: Health check results  Figure 11: Upgrade site collection or create evaluation site collection Before you actually run site collection upgrade, you can use one more option to test if everything works as expected. This is called evaluation site collection, which essentially is a read only copy of your existing site collection, which you can use to review the new interface and new functionalities. Evaluation sites are automatically expired and deleted after certain amount of time, which by default is set to 30 days. Finally we are about to start the site collection upgrade. As mentioned before you can do this by clicking Upgrade this site collection button as seen on figure 9. The second option is of course using PowerShell. Upgrade-SPSite -Identity http://2013upgrade -VersionUpgrade  Figure 12: Maintanance logs After upgrade process is completed you can also check logs to see if there are any issues that need to be resolved. This log files are located at http://2013upgrade/_catalogs/MaintenanceLogs. If everything went smoothly you are now able to enjoy all new features that SharePoint 2013 has to offer. There are of course some other details that need to be discussed, especially in large environments where there are plenty of site collections but this is out of scope of this article.

Tags:

SharePoint 2010 | SharePoint 2013 | SharePoint - Administration | PowerShell

SBSC – 2012.04 – PowerShell

by joze 10. April 2012 13:51
I was presenting at SBSC on 10th of April. Attached to this post is my presentation. In it you can hopefully find some useful resources that will help you do the things you do a little faster. SBSC - 2012.04 - PowerShell

Tags:

Administration | Windows Server | Windows 7 | PowerShell

Calendar

<<  December 2017  >>
MonTueWedThuFriSatSun
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567

View posts in large calendar

Page List

Month List