Just can across a couple of great articles on how to script the creation and modification of the User Profile Properties. For those who are into repeatable process, this allows you to map out what properties you want in your environment and how you want users to interact with them. Then you can run the script through all your environments (assuming your AD/LDAP attributes are the same in all environments ;)) to configure all your farms accurately.
This one describes how to add new property mappings. ie. If you want a property called Pets that you want users to be able to fill in.
http://blogs.msdn.com/b/tehnoonr/archive/2010/11/22/mapping-user-profile-properties-in-sharepoint-2010-to-ldap-attributes.aspx
This one modifies existing ones (including new ones you create I guess) and allows you to set the other options around each property, like whether its alias, who can edit etc
http://www.c-sharpcorner.com/uploadfile/anavijai/modify-user-profile-properties-in-sharepoint-2010-using-powershell/
Reference material on SharePoint property constants that are used
http://msdn.microsoft.com/en-us/library/microsoft.office.server.userprofiles.propertyconstants_members.aspx
brett's blog
Tech notes from the field
Thursday, April 18, 2013
Thursday, February 7, 2013
Good SharePoint Blog
Karine Bosch has a great little blog that shows you how to create SharePoint-like Application Pages using the OOTB control templates and also has a great piece of source that wraps the Content Query WP's Select Site/List/Item dialog (LaunchPickerTreeDialog). Very handy.
http://karinebosch.wordpress.com/
http://karinebosch.wordpress.com/
Wednesday, April 25, 2012
Removing Columns for Content Types
Creating a new custom content type? Have to inherit from something but you don't want to include all the fields/columns from the parent?
Simple (in most cases). Use the following powershell script to remove (note does not delete the column which doesn't belong to you to delete anyway :))
$ver = $host | select version
if ($ver.Version.Major -gt 1) {$host.Runspace.ThreadOptions = "ReuseThread"}
if ((Get-PSSnapin "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue) -eq $null)
{
Add-PSSnapin "Microsoft.SharePoint.PowerShell"
}
#Attach to the web and content type
$web = Get-SPWeb http://intranet.contoso.com/
$ct = $web.ContentTypes["Content Type"]
#Insert name of column to remove from Content Type
$columnName = "Comments"
#Get link to the columnn from the web
$spFieldLink = $ct.FieldLinks[$columnName]
#Recently I tried to use this script and this line failed, I replaced it with the one above and its fine.
#$spFieldLink = New-Object Microsoft.SharePoint.SPFieldLink($web.Fields[$columnName])
#Remove the column from the content type and update
$ct.FieldLinks.Delete($spFieldLink.Id)
$ct.Update()
#Test that the column was successfully removed from the Content Type
if ($ct.Fields[$columnName])
{
Write-Host "$columnName was not removed"
}
else
{
Write-Host "$columnName was removed"
}
Note: Only issue I have found so far is that I still cannot remove all fields that I want removed. In my case I wanted to remove the "Comments" field from a content type but for some reason it won't remove.
EDIT: Figured out how to delete/remove the Comments field from my content type.
First make it hidden (you can do this through the UI or in a script) then the above script can be used to remove it. Weird by it works
Simple (in most cases). Use the following powershell script to remove (note does not delete the column which doesn't belong to you to delete anyway :))
$ver = $host | select version
if ($ver.Version.Major -gt 1) {$host.Runspace.ThreadOptions = "ReuseThread"}
if ((Get-PSSnapin "Microsoft.SharePoint.PowerShell" -ErrorAction SilentlyContinue) -eq $null)
{
Add-PSSnapin "Microsoft.SharePoint.PowerShell"
}
#Attach to the web and content type
$web = Get-SPWeb http://intranet.contoso.com/
$ct = $web.ContentTypes["Content Type"]
#Insert name of column to remove from Content Type
$columnName = "Comments"
#Get link to the columnn from the web
$spFieldLink = $ct.FieldLinks[$columnName]
#Recently I tried to use this script and this line failed, I replaced it with the one above and its fine.
#$spFieldLink = New-Object Microsoft.SharePoint.SPFieldLink($web.Fields[$columnName])
#Remove the column from the content type and update
$ct.FieldLinks.Delete($spFieldLink.Id)
$ct.Update()
#Test that the column was successfully removed from the Content Type
if ($ct.Fields[$columnName])
{
Write-Host "$columnName was not removed"
}
else
{
Write-Host "$columnName was removed"
}
Note: Only issue I have found so far is that I still cannot remove all fields that I want removed. In my case I wanted to remove the "Comments" field from a content type but for some reason it won't remove.
EDIT: Figured out how to delete/remove the Comments field from my content type.
First make it hidden (you can do this through the UI or in a script) then the above script can be used to remove it. Weird by it works
Labels:
Content Types,
Poweshell,
SharePoint 2010
SharePoint Permissions Tip: Leave the Style Resource Readers group alone
I've spent quite a bit of time tracking down issues that all relate to permissions for the Style Resource Readers group. My number 1 permissions tip: Don't change anything to do with this group!!!
There are several ramifications when this group's permissions change, users may start reporting that they have 'Access Denied' errors trying to edit or create pages. Or if you have a structure where you want users to only be able to access a sub site and you don't give any permissions to the Root site, then they will get 'Access Denied' everywhere.
It's a weird error to try and track down because the user will report that they still have access to create/edit items in a list, they can still see Site Settings, they still seem to have enough privelages to do it, but get an outright 'access denied' error.
Just ensure that the Master Page Gallery (Style Library) has the Style Resource Readers group as having restricted read permission on the library.
There are several ramifications when this group's permissions change, users may start reporting that they have 'Access Denied' errors trying to edit or create pages. Or if you have a structure where you want users to only be able to access a sub site and you don't give any permissions to the Root site, then they will get 'Access Denied' everywhere.
Create / Edit publishing pages
What that meant was, because SharePoint was trying to render the masterpage and page layout on either the page they wanted to edit or a new page, it couldn't because they didn't have access to them, regardless of the fact they had access to the page library.It's a weird error to try and track down because the user will report that they still have access to create/edit items in a list, they can still see Site Settings, they still seem to have enough privelages to do it, but get an outright 'access denied' error.
Access Denied to sub sites
I had created a group just for a sub site to have view only permissions however users were reporting that they got 'Access Denied' messages. Again it turns out that although the Style Resource Readers group existing in the Root site with all authenticated users it didn't have any permissions on the Style Library document library itself, hence why access didn't work in the sub site.Just ensure that the Master Page Gallery (Style Library) has the Style Resource Readers group as having restricted read permission on the library.
Labels:
Master Page Gallery,
Permissions,
SharePoint 2010
SharePoint 2010 Web Services and Anonymous Access
Looks like SharePoint 2010 still has issues with Anonymous Access and its web services.
There are a fwe articles out there pointing at this issue in 2007 but I'm afraid its no better in 2010 (SharePoint 15?).
This article (Trinkit HQ) is short and sweet, and gets right to the point. Basically if your Web Application has Anonymous Access turned on, you will experience the 'Attempted to perform an unauthorized operation' error.
There are a few ways to deal with it, extend another web app, muck around with IIS (not recommended) but the bottom line is:
Anonymous Access = No Web Services
There are a fwe articles out there pointing at this issue in 2007 but I'm afraid its no better in 2010 (SharePoint 15?).
This article (Trinkit HQ) is short and sweet, and gets right to the point. Basically if your Web Application has Anonymous Access turned on, you will experience the 'Attempted to perform an unauthorized operation' error.
There are a few ways to deal with it, extend another web app, muck around with IIS (not recommended) but the bottom line is:
Anonymous Access = No Web Services
Labels:
Anonymous Access,
Search,
SharePoint 2010,
Web Services
Subscribe to:
Posts (Atom)