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

SharePoint 2013 Display AD Group Members

by Robi 7. September 2015 14:55
SharePoint 2013 Display AD Group Members This project is an upgrade project to this: Display members of AD group in SharePoint 2010 - Homehttps://sp2010adgroupmembers.codeplex.com/ Intended use This web part is inteded to be used for displaying site users in a web part on a web part page. It enables you to display the members of Active Directory security groups,  Improvements This version of web part has several improvements: Treeview control does not load all members on page load, only first level of site users is loaded. On expand, calls are made to AD and members are loaded in treeview control. This enables faster page loading and loading members of specific AD group on demand. Expand all and collapse all options were added to web part Custom branding is enabled Email and phone number of a user can be displayed in web part Sending emails with email client is possible directly from web part if email address is displayed Better error handling Errors are loaded in ULS logs Namespace of the web part was changed Option to display Lync status  Installation procedure To install this solution in your farm, please follow these instructions: On your c: drive create a folder named "Temp" Open your SharePoint 2013 Management Shell with elevated privileges Enter the following PowerShell code: Add-SPSolution -LiteralPath "C:\Temp\ADGroupMembersWebPart.wsp" -Verbose   Once solution has been added to the farm solutions store you can run the following PowerShell code to install the solution in your farm: Install-SPSolution -Identity ADGroupMembersWebPart.wsp -GACDeployment -AllWebApplications -Verbose Solution has a web application scope feature, so in this step you may also choose to which web applications you wish to install this solution to.     Activation procedure To activate feature containing the web part, you have to activate feature at a site collection level. To activate this feature go to Site settings and in the Site collection administration section click on Site collection features. Find Display AD group members Web Part Activate the feature by clicking the Activate button:    Add web part to a page  To add web part to a page, open a web part page and on the ribbon On the insert tab on the ribbon click on Web Part In the categories, select KompasXnet and in the parts section select Xnet Display Group Members: Once web part has been added, you will see empty web part as on the picture bellow: Web part settings To set web part propertis, you need to open Web part tool pane. Once Tool pane is displayed there are several settings and options: Enter FQDN of your domain You must enter FQDN of you domain to the text box. This property is used to query Acitve Directory. Display site users Display site users option display users and groups that have permissions on current web. It queries current web context and display users with permissions. IF current user does not have permissions to view SharePoint group members, these will not be displayed in the web part.     Display users and groups from specific OU When selection "Display users and groups from specific OU" it is recommended to enter AD Organizational Unit from where you want to display members. If you do not specify OU filter, it will query whole domain. Use custom CSS file for branding Use this option if you want to specify different CSS file than the one that is used by default. Default file is deployed to style library in the "AdGroupMembersWebPart" folder. All web part elements have their unique classes added so you can use those CSS classes to brand your web part as needed. Display user data in web part (email and phone) If selected, this option enables you to display user data which is pulled out of Active Directory. Currently, only user email and telephone number are displayed in the web part. When option is enabled, user data is displayed in the web part: Email address is formated as mail to hyperlink, so you can send email directly from the web part: Display Lync status This option enables you to display Lync status. You can choose to use UPN for SIP address or you can select email address as you SIP address. When enabled, users can see Lync status of users displayed in web part. Display errors (debug mode) When enabled, if there are any errors, they are going to be displayed in the web part. For debugging this web part you can also check ULS logs. Logging was added to this version of web part and you can check any web part errors in ULS.  Download

Tags:

SharePoint 2013

Create site collection in target content database

by Robi 23. August 2014 11:02
I get a lot of question from my customers how to create site collection in specific content database. In Central Administration you do not have an option OOTB to create site collection and specify in which content database you would like to create it in. This is the reason I created script that opens a form where you can select Web application, Managed Path, Content database, language and Template for a site collection. You must enter data as seen on this screen shot. Mandatory field are: managed path content database primary site collection admin site collection title site collection URL - note that this is just url after managed path language web template - it load templates based on language, compatibility level and not hidden. ***Note This script supports creating site collection only with wildcard managed paths. You can download a script here:   And I published the script to Office downloads and scripts as well.   Hope you like it. CreateSiteCollectionInContentDb.ps1 (16.02 kb)

Tags:

SharePoint 2010 | 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

Export – import alerts

by Robi 9. November 2013 18:23
In my previous blog post I have explained how you can troubleshoot alerts. In this one, I'm just going to post scripts I used for exporting and importing all alerts in a site collection. Here is the script for exporting all alerts in a site collection to a csv file: $site = Get-SPSite "http://2013portal" $alertResultsCollection = @() foreach ($web in $site.AllWebs) { foreach ($alert in $web.Alerts){ $alertURL = $web.URL + "/" + $alert.ListUrl $alertResult = New-Object PSObject $alertResult |Add-Member -type NoteProperty -name "WebUrl" -Value $web.Url $alertResult | Add-Member -type NoteProperty -name "ListURL" -value $alertURL $alertResult | Add-Member -type NoteProperty -name "AlertTitle" -value $alert.Title $alertResult | Add-Member -type NoteProperty -name "ListUrl" -value $alert.ListUrl $alertResult | Add-Member -type NoteProperty -name "List" -value $alert.List $alertResult | Add-Member -type NoteProperty -name "DeliveryChannel" -value $alert.DeliveryChannels $alertResult | Add-Member -type NoteProperty -name "AlertType" -value $alert.AlertType $alertResult | Add-Member -type NoteProperty -name "EventType" -value $alert.EventType $alertResult | Add-Member -type NoteProperty -name "Frequency" -value $alert.AlertFrequency $alertResult | Add-Member -type NoteProperty -name "AlertTime" -value $alert.AlertTime $alertResult | Add-Member -type NoteProperty -name "SubscribedUser" -value $alert.User $alertResultsCollection += $alertResult } } $site.Dispose() $alertResultsCollection  #Export to CSV $alertResultsCollection | Export-CSV C:\Users\sp2013_farm_admin\Desktop\Alerts.csv  And here is the script you can use to import all alerts in one site collection from csv file:  Import-Csv C:\Users\sp2013_farm_admin\Desktop\Alerts.csv |ForEach-Object{ $webUrl=$_.WebUrl $listTitle=$_.List $alertTitle=$_.AlertTitle $subscribedUser=$_.SubscribedUser $alertType=$_.AlertType $deliveryChannel=$_.DeliveryChannel $eventType=$_.EventType $frequency=$_.Frequency   $web=Get-SPWeb $webUrl $list=$web.Lists.TryGetList($listTitle) $user = $web.EnsureUser($subscribedUser) $newAlert = $user.Alerts.Add() $newAlert.Title = $alertTitle $newAlert.AlertType=[Microsoft.SharePoint.SPAlertType]::$alertType $newAlert.List = $list $newAlert.DeliveryChannels = [Microsoft.SharePoint.SPAlertDeliveryChannels]::$deliveryChannel $newAlert.EventType = [Microsoft.SharePoint.SPEventType]::$eventType $newAlert.AlertFrequency = [Microsoft.SharePoint.SPAlertFrequency]::$frequency if($frequency -ne "Immediate"){ $AlertTime=$_.AlertTime $newAlert.AlertTime=$AlertTime } $newAlert.Update() }    Hope it helps. Robi Vončina

Tags:

SharePoint | SharePoint 2010 | SharePoint 2013

Calendar

<<  November 2017  >>
MonTueWedThuFriSatSun
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

View posts in large calendar

Page List

Month List