PowerShell

Import SharePoint MetaData from CSV along with their Guids, Deprecate-State and Custom Ordering

Piyush SharePoint Managed Metadata , , , , , , , , , , , ,

This is the final of the two-series blog. Before proceeding further, here’s the link to the 1st part, https://realmpksharepoint.wordpress.com/2015/06/19/export-sharepoint-metadata-to-csv-along-with-their-guids/. The objectivity of the entire series has been already defined there so I won’t be re-iterating the same. However, I must re-visit some of the items relevant to the current context. So following are the objectives of this script:

  • Import Terms to SharePoint only when they don’t already exist. The search will be done using the Term Name only.
  • Can create a Term with the given Guid i.e., Guids can be retained across the servers. This is optional. If you don’t want to use this option, then keep this column blank and the TermSet will be created using a brand new Guid assigned by the SP.
  • Deprecate/Un-Deprecate an existing or a new Term. If you want to change this option on a number of pre-existing TermSets or you even want to create the TermSets with the deprecate value on, then simply update the corresponding column in the exported CSV and then run the import script.
  • Modify the availability for Tagging option. If you have to change this option on a number of pre-existing or new TermSets then simply update the given CSV accordingly and then run the import script.
  • Most importantly, it applies custom sorting to the TermSets. So the TermSet and their child terms will exactly appear in the same order as has been listed in the processing CSV file.

Input

There are three parameters that needs to be set before executing the script. They are:

  • $fileName: Full path of the csv file to be imported.
  • $termStoreGroupName: Term group name. Please note that the script does not create a term group. Hence do ensure first that the group already exist at SharePoint even if its blank.
  • $MMSStore: Name of the managed metadata service.

Continue reading →

Export SharePoint MetaData to CSV along with their Guids

Piyush SharePoint Managed Metadata , , , , , , , , , , , , ,

This is a two series blog in which I will try to cover lots of SharePoint TermSet Metadata operations. The idea is to achieve the following:

Export Terms to CSV

  • Existing Terms along with their child Terms,
  • Current Guid,
  • Available for Tagging option, &
  • Deprecate state.

Import Terms from CSV

  • Import Terms which will create Terms only when they don’t already exist. The search will be done using the Term Name.
  • Can create the Term with the given Guid. This is optional. If you don’t want to use this option, then keep this column blank and the Term will be created using a brand new Guid.
  • Deprecate/Un-Deprecate an existing or a new Term. If you have to change this option on a number of pre-existing TermSets then simply update the exported CSV accordingly and then run the import script.
  • Modify the availability for Tagging option. If you have to change this option on a number of pre-existing TermSets then simply update the given CSV accordingly and then run the import script.
  • Most importantly, it also applies custom sorting. So the Terms and their child terms will exactly appear in the same order as has been mentioned in the processing CSV.

In this post, I’ll only be showing the export operation. The import operation has been defined here, https://realmpksharepoint.wordpress.com/2015/09/23/import-sharepoint-metadata-from-csv-along-with-their-guids-deprecate-state-and-custom-ordering/. Please note that since the generated output will be in CSV format, we’re converting any comma (,) that might be included in the Term name to “,” otherwise the format will get distorted.

Input

The script expects two parameters that needs to be set before executing it. They are:

  • $termGrpNm: The name of the TermGroup whose all TermSets will be exported to CSV files respectively.
  • $svLoc: File System location where all the CSVs will be dumped.

Here’s the script preview. Download link for the same has been provided in the later segment.

Continue reading →

Changing the value of Existing ListItems Old Managed MetaData Value with a New One

Piyush SharePoint Managed Metadata , , , ,

I had this requirement where there was a need to rename some of the existing Managed MetaData Terms, [Old Parent, Old1, Old2, & Old3] to a single new Term [New Term].

Usually, renaming a single term is no big deal. However, this was a Many => One relationship and you cannot have 2 or more Terms with identical names at the same level of hierarchy. So renaming was not an option here. We had to make sure that for all the existing ListItems, the GUIDs of every old term should get replaced with the New Term GUID. Following is the PowerShell script I came up with to do this job.
Continue reading →

Update Custom MetaData Property in SharePoint UserProfile

Piyush SharePoint UserProfile , , , , , ,

We’re gonna use, Microsoft.Office.Server.UserProfiles.UserProfileManager class to get a given Microsoft.Office.Server.UserProfiles.UserProfile and update some of its values. Say, there are two custom properties defined in the SharePoint Central Admin which are mapped to some TermStores. They are:

  1. CpSingle [Single metaData value is allowed. Mapped to say Continent/Region].
  2. CpMulti [This metaData field can have multiple values. Mapped to say Countries.].

Our objective is to update these metadata fields using a powerShell script. Before we delve into that, there are few things that needs to be clarified here.

  • Indexing a userProfile object, say, $userProfile[“CpSingle”], will return an object of Microsoft.Office.Server.UserProfiles.UserProfileValueCollection.
  • So we can add multiple values to this object using its Add(Object o) function.
  • Similarly, existing items can be removed by calling its Clear() function.
  • If only a single property has to be set then, we can use it’s Value property to do the same. It gets or sets the value of the profile property.

So here’s the script snippet.


[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")

#Get any site 
$site = Get-SPSite -Limit 1 
$context = Get-SPServiceContext($site)
$profileManager = New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager($context)
$userProfile = $profileManager.GetUserProfile("domain\UserName")

#Some default properties can be accessed using the dot operator. 
Write-Host ("Changing custom properties for " + $userProfile.DisplayName)

#valid region value 
$userProfile["CpSingle"].Value = "Asia"

#First clear any existing item for multi property. Then add our values. $userProfile["CpMulti"].Clear() 
$userProfile["CpMulti"].Add("India")
$userProfile["CpMulti"].Add("Bhutan")
$userProfile["CpMulti"].Add("Sri Lanka")

#Finally save all the changes.
$userProfile.Commit()

This script is good for modifying the custom metadata properties of a single user. But if we want to make these changes or some other changes uniform to all the existing UserProfiles, then we need to enumerate through all the userProfiles instead of fetching a single value. Same script to update the above mentioned custom properties with the same value for all the UserProfiles is mentioned below.


$profiles = $profileManager.GetEnumerator()
while ($profiles.MoveNext()) {
     
     #Get the current profile
     $userProfile = $profiles.Current     
     Write-Host ("Changing custom properties for " + $userProfile.DisplayName)

     #valid region value 
     $userProfile["CpSingle"].Value = "Asia"

     #First clear any existing item. Then add our values. 
     $userProfile["CpMulti"].Clear()
     $userProfile["CpMulti"].Add("India")
     $userProfile["CpMulti"].Add("Bhutan")
     $userProfile["CpMulti"].Add("Sri Lanka")


     #Finally save all the changes.
     $userProfile.Commit()
}

Create a read-only user in Office365

Piyush SharePoint Online , , , , , , , , ,

This is the first of the 2 series blog. In this, I’ll explain how to do create a read-only Office365 User, directly from the client PowerShell. And then there’s a complete code snippet to achieve the same from a C# Console App in the 2nd part of this blog[Coming soon]. Before delving deep, I would like to highlight the fact, that you’ll NOT be charged for this User a/c by Microsoft. We’ll be barely creating a User, not assigning any license to it.

The entire process can be broadly classified into 4 major steps:

  1. Authenticate using existing administrator’s userID & password
  2. Create a new User with a randomly generated password
  3. Assign the role, “Service Support Administrator“
  4. Assign the RoleGroupMember, “View-Only Organization Management” [Exchange]

PowerShell

Requirement:

SharePoint Online Management Shell with all its dependencies.

Authenticate using existing administrator’s userID & password

Open Windows PowerShell and enter the cmdlet,

"Connect-MsolService".

A dialogue will pop-up seeking the userId & password.

Provide an administrators credential here. Note, you’ll not be notified for wrong userID or password. In the event of providing wrong credential, the following cmdlets will refuse to run. So, make sure, that the credential is correct.

Create a new User with a randomly generated password

Once, the authentication is done, we’ll then create a new Office365 user. We’ll be providing basic user details, like FirstName, LastName, LoginID [or, UserPrincipal(compulsory)]. But, we’ll never set the password. The password will be returned back to us, once the user has been created. Another important thing to note here is the password policy we’re enforcing here. First, we’re setting, “ForceChangePassword” to false. This implies that when the User will login for the very first time, he/she will not be prompted to change it. Next, we’re setting “PasswordNeverExpires“, to true which, is pretty much self-explanatory.

New-MSolUser -DisplayName “PK” -UserPrincipalName “pk@company.onmicrosoft.com” -FirstName “Piyush” -LastName “Singh” -ForceChangePassword $false -PasswordNeverExpires $true

Once the User has been created, its basic details like, UserPrincipalName, newly created Password, etc, will be displayed in the Shell. One can also specify their preferred password also by adding, “-Password “Password123” at the end of the above cmdlet.

Note: There can be multiple Users with identical DisplayName but not UserPrincipalName. It has to be unique.
 

Assign the role, “Service Support Administrator”

This is simple. We’ll be assigning the “Service Support Administrator” role to this newly created User.

Add-MSOLRoleMember –RoleName “Service Support Administrator” –RoleMemberEmailAddress pk@company.onmicrosoft.com

Assign the RoleGroupMember, “View-Only Organization Management”

This role group is specific to Exchange. The objective is to assign only view permission to this user. To accomplish this, we’ll execute the cmdlet, “Add-RoleGroupMember“. One problem, this cmdlet is not a part of SharePoint Online Management Shell. So we cannot directly run it. We have to, first, establish a remote connection to the Exchange Server, and temporarily import it’s commands to the local PowerShell session. Only then, we can execute the cmdlet, “Add-RoleGroupMember“. Once the job’s done, we should also remove this session. To know more about this, plz visit the site, http://technet.microsoft.com/en-us/library/dd335083(v=exchg.150).aspx

Since, here, we’ll be executing a series of commands, I have put it all down in a script file. Here’s the content,

$Cred = Get-Credential
$s = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -Authentication Basic –AllowRedirection
Import-PSSession $s
$memberLoginName = Read-Host ‘LoginID’
Add-RoleGroupMember -identity ‘View-Only Organization Management’ -member $memberLoginName
Remove-PSSession $s

Say, we saved the file in D drive, with the name, addExchngViewRole.ps1. So to execute the same, just run from powershell, D:/addExchngViewRole.ps1. A dialog box will be prompted (same as above). Here again, you need to specify the admin’s credential. Once validated, it will import the Exchange commands.

Next, you’ll be asked to provide the PrincipalID or LoginName of the User who will be assigned to the RoleGroup, View-Only Organization Management [in this case, pk@company.onmicrosoft.com]. After that the user will be added to the given group and the current session will be removed from your machine, as per Microsoft’s guideline.

Note: ConnectionUri has been fixed to https://ps.outlook.com/powershell. This is valid for Exchange Online only. If you’re using on-premise, plz replace the url with this one, http:///PowerShell/.

Get Available PowerShell Commands for SharePoint on Client-Side

Piyush SharePoint Online , , , , , ,
Needless to say, that on Client Side, we get a limited scope of running various SharePoint commands. As a result there aren’t much cmdlets for the Client Side. So how do you know what are the available commands that might come handy while executing cmdlets remotely? Simply run the following command in PowerShell or SharePoint Online Management Shell.
get-command | Where-Object { $_.ModuleName -eq "Microsoft.Online.SharePoint.PowerShell" }

A sample list of available cmdlets are displayed in the following screenShot.