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

"Alert Me" feature and SharePoint 2013

by Robi 31. October 2013 13:58
In the previous few projects we had some issues involving alerts after upgrading or migrating to SharePoint 2013, so I wanted to explain how you can help yourself out when troubleshooting alerts in SP2013. I described here a few most common issues we were faced with. 1. The "Alert Me" Feature is not available If you happen to be in the documents library, and you do not find the command "Alert Me", the most likely problem is that you have not set up "Outgoing Email Settings" in Central Administration. Outgoing Email can be found in the category System Settings Configure Outgoing E-Mail Settings or at the URL: http://[CA_URL],/_admin/globalemailconfig.aspx. Another option to set the Alerts is of course the use of PowerShell. Script with which you can set up alerts is as follows:  # == == == == == = Set variables == == == == == $SMTPServer = "devmail" $emailAddress = "SP2013@dev.local" $replyToEmail = "robi@dev.local"    # == == == == == = Outgoing Email = == == == == == $loadasm =[System.Reflection.Assembly]::LoadWithPartialName ("Microsoft SharePoint.") $spGlobalAdmin = New-Object To Microsoft SharePoint. SPGlobalAdmin Administration. .. $spGlobalAdmin.UpdateMailSettings ($SMTPServer, $emailAddress, $replyToEmail, 65001)    The result of our setting is then visible to the Central Administration and on the Ribbon in lists or libraries where the Alert Me button appears: 2. You are not able to create alerts for domain Email enabled security groups or distribution groups In SharePoint 2013, we came across a very interesting example, where through the user interface you are not able to subscribe a domain security group to alerts. In the document library or list, click the alert me button, the dialog box opens, where you can enter the user you would like to subscribe to alerts. In previous versions of SharePoint names of distribution groups or email enabled security groups get resolved, while in the new version domain groups do not work. You get a "No matching results". If you want to create alerts for your domain groups, you must use PowerShell:    <# ================================================    Options, setting EventType    SPEventType [Add, Modify, Delete, Discussion, All]    Setting options in the alert frequency the case of the daily, weekly, it is necessary to also set alert hour    SPAlertFrequency [Immediate, Daily, And Weekly]    ================================================ #>    $web=Get-SPWeb "http://2013portal" $list=$web.Lists.TryGetList("Documents") $user = $web.EnsureUser('DEV\skupinaemail') $newAlert = $user.Alerts.Add() $newAlert.Title = $list.Title $newAlert.AlertType=[Microsoft.SharePoint.SPAlertType]::List $newAlert.List = $list $newAlert.DeliveryChannels = [Microsoft.SharePoint.SPAlertDeliveryChannels]::Email $newAlert.EventType = [Microsoft.SharePoint.SPEventType]::All $newAlert.AlertFrequency = [Microsoft.SharePoint.SPAlertFrequency]::Daily $newAlert.AlertTime="12:00" $newAlert.Update()    In order to verify whether they have successfully set up alerts, open the Site Settings / User alerts For the purposes of testing and the display of alerts, I created another alert for the same group, the only difference is that in this case, I use the "Frequency" Immediate Alert. 3. The user has set Alert on item adding in document library, but an immediate alert is not sent For this example, it is necessary to understanding how alerts work. SharePoint Content databases has a table, which is called the EventCache. This is the table where SharePoint writes events that are important to search service application, alerts, ..., in short, the table serves as a temporary repository of current events, which is then used for subsequent operations. In the case of alerts, all subsequent operations for Immediate alerts are taken care of by the Timer job, which can be found in the Central Administration and is called Immediate Alerts or you can list all Timer jobs by simple PowerShell query: Get-SPTimerJob | ? {$_.name -like "alert"}    As we can see from the results of the command, the Timer Job triggers every 5 minutes. The timer job queries the content databases and table EventCache. In the event that the table contains records for sending alerts, alert email is sent and record gets deleted from the event cache table. Warning! Running a query directly to the SharePoint database is not supported. To see what EventCache table contains, you can run this SQL Query against your Content DB: select * from [SP13_Content_2013Portal].[dbo].[EventCache] (nolock)order by [TimeLastModified] desc    So, if I make a change on the document in the document library and perform a query, I get as a result of the following record: Query result can be also the first verification that alerts work properly. For the purpose of subsequent verifications of Alerts, we have to use ULS Log Viewer and set up Verbose logging in Central Administration for alerts. Alerts logging can be found in the SharePoint Foundation category. In the ULS Log Viewer, you have the option of filtering ULS logs. The easiest way to get all records related to the alerts, is to set the filter, as shown in the image: If you want to see the records in the ULS logs and do not want to wait for 5 minutes, you must manually trigger Immediate Alerts Timer Job. In my case, I'm exploring what's happening with alerts to which user Uroš is subscribed to. In the document library I uploaded a new document and started the Immediate alerts timer job with the use of PowerShell: Get-SPTimerJob | ? {$_.name -like "*alert*"} |Start-SPTimerJob    In ULS logs you can now see records of Alerts operations: In this case, I see that alerts work as expected. But what happens if we have a library with feature "Require documents to be checked out before they can be edited«? Repeat the process, upload the document to a document library, in the ULS LOGS watch what's going on with alerts. Following entries appear: Voila, I can see that the alerts are being processed correctly, however, because loading the document into the document library is a 2 step process, upload and entering metadata, it can be concluded that when uploading a document, document is treated as checked out. Record is written to EventCache table where state of document is registered as Checked out. With that being said, we can now conclude that when the feature "Require documents to be checked out before they can be edited« on document libraries is enabled and user is subscribed to alerts on document added, alerts are not going to be sent out, as SharePoint treats this documents as checked out, or as the first minor version.  In this article I tried to describe some typical errors which may occur in the SharePoint 2013, in conjunction with the Alert Me feature and what's more important, I tried to demonstrate how we can debug and solve errors. After the troubleshooting, don't forget to set the logging level for the Alerts back to the default settings.    Robi VončinaSharePoint Server MVP

Tags:

SharePoint 2013 | SharePoint 2010 | SharePoint - Administration

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

Calendar

<<  May 2017  >>
MonTueWedThuFriSatSun
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234

View posts in large calendar

Page List

Month List