Recently I stumbled in a new challenge I haven’t had for a long time. One of my customers wants to migrate users from Active Directory Domain A to Active Directory Domain B. The problem was that all the previously edited documents should get mapped to the new users.
Hide fields from list forms using PowerShell
Since SharePoint 2010 was introduced there are much more ways to customize forms for list and document libraries. In most cases there is only the simple requirement to hide fields or have better control over them on lists and content types. SharePoint 2010 is the same way limited for hiding fields like it was in MOSS 2007. For advance control it was always necessary to code those fields. So first let’s take a look at how you can controls fields on the list using the normal settings dialog. The base setup in this test is a custom list called “List” with a new column called “NewColumn” which is of type single line of text.
There are no settings available where you can control where the fields should be appearing. The options to hide a field form certain forms are even not available in SharePoint. So the only way to remove the fields from NewFormDialog for example will be to set up a custom list form. No not at this stage.
When the management of content type is enabled to the list using some advance settings will come up to the fields. This can be done in the list settings:
- “Advanced settings”
- “Allow management of content types”
- “Yes”
Behind ever list and library there is a content type assigned. For my custom lists this is the “Item” content type. After selecting this content type there is the “NewColumn” I created available too. On the column the following view options can be selected.
Required optional or hidden is good but won’t help in most cases. So what now? Create a custom list form? No, this is not needed.
SharePoint developer might find SPField Object from the server object model. So if a developer creates a custom content type the following options can be selected in CAML Definitions or as properties using object model.
- ShowInDisplayForm
- ShowInEditForm
- ShowInListSettings
- ShowInNewForm
- ShowInVersionHistory
- ShowInViewForms
I think the names of those properties are self-explaining. Is there coding needed to use those properties? Yes it is but not as a WSP. This field can set using PowerShell the following example demonstrates how to set those properties by a simple script which only opens the list using object model and sets the values, which are basically Boolean values. I use simply 0 and 1 values to set.
0 enables this property
1 disable this property
So for hiding our column in the new form dialog we just simply need to set the value of ShowInNewForm to false or 0.
# First load SharePoint Core Assembly [System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”) $url = "http://myserver:Port"; $list = "List"; $fieldname = "NewColumn"; #Setting up context $contextSite = New-Object Microsoft.SharePoint.SPSite($url); $contextWeb = $contextSite.OpenWeb(); $list = $contextWeb.Lists.TryGetList($list); $field = $list.Fields[$fieldname]; # Controls Field in Edit Form $field.ShowInEditForm = 1; # Controls Field in New Form $field.ShowInNewForm = 0; # Controls Field in New Form $field.ShowInDisplayForm = 1; # Hides fields from list settings $field.ShowInListSettings = 1; # Hides fields from version history $field.ShowInVersionHistory = 1; # Hides fields form selection in views $field.ShowInViewForms = 1; # Don't forget to update this field $field.Update(); # And finally dispose everything. $contextWeb.Dispose(); $contextSite.Dispose();
So how does it look after executing the script:
NewColumn is hidden on NewForm but still avaliable on EditForm.
Conclusion:
I actually can’t say what the reason is behind those properties are available using object model but not be available using the interface or SharePoint Designer. Those properties will give power user better control over their fields and will not require custom list forms using SharePoint Designer or InfoPath Forms for every simple field hiding. Those properties are not new they were still available in Moss 2007. Might this will be supported by SharePoint 2013 or 2014.
Clean up SharePoint User Profile Store using PowerShell
Today i had a problem in my development environment for my SharePoint Projects regarding User Profile Store. My user profile was a messed up and was not available for editing in central administration. When i searched for my profile it still there but not shown for administration. This was a really strange behavior because a couple of days it worked well. I added various new profile properties to my user profile service application. So the recreation of User Profile Service Application was not an option. Deletion of orphan or corrupted user profiles is not possible using Central Administration or even using avaliable PowerShell commands.
But there is a solution using PowerShell without compiled code. Using PowerShell everything what is avaliable in the server object model is avaliable. First of all two assemblies must be referenced.
These assemblies are:
- Microsoft.Office.Server (Core SharePoint Server Assembly)
- Microsoft.Office.Server.UserProfiles (UserProfile Assembly)
Those assemblies could be referenced using System.Reflection and the rest of the script is quite simple SharePoint Development. So get a context object, open profile service application get all use and delete them.
# Load required Assemblies for SharePoint Server and User Profile [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server") [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Server.UserProfiles") # Central Adminstration URL or any Web Application $url = "http://mainframe:48248" # Create a new Context Object $contextWeb = New-Object Microsoft.SharePoint.SPSite("http://mainframe"); # Get the right Service Context $ServerContext = [Microsoft.Office.Server.ServerContext]::GetContext($contextWeb); # create a new connection to the UserProfileManager $UserProfileManager = New-Object Microsoft.Office.Server.UserProfiles.UserProfileManager($ServerContext); # Ger all User Profiles $Profiles = $UserProfileManager.GetEnumerator(); # Loop through user profile foreach ($oUser in $Profiles ) { # Remove Profile $UserProfileManager.RemoveUserProfile($oUser.item("AccountName")); }
This script can be extended to delete only specific users from user profile information. At the end I was able to solve my problem. My User Profile was deleted and recreated on first access and due profile import. Everything worked fine.
In the old days you had to write some custom command line tool to address those batch update and deletion task. With the introduction of PowerShell to SharePoint any possible administrative task could be accomplished by just use scripting.