I’ve created a custom control for SharePoint 2010. This control let you connect two lookup fields so that the second lookup field contains only a subset of all values depending on the selected value of the first lookup field.

The control can handle both rendering methods of SharePoint for lookup fields: If there are more then 20 items in a lookup dropdown it will be rendered alternatively as input text box and not as input dropdown…

But… It’s alpha!!!

See: http://spconditionallookup.codeplex.com

Some Screenshots…

This is the demo list where you start using the demo.

Add a new item. You see two input controls. Both are empty.

Now you open the dropdown list of the first field:

There are values in – Leave it on “(none)” for now.

Open the dropdown of the second field:

Its empty

Now select the value “List1-Value1” in the first dropdown.

Now open the second dropdown. Now there are values in there :

The second dropdown was filled with values depending on the selected value of the first dropdown.

Lets have a look behind the scene.

Open the List “This list defines the value dependencies between the main list and the conditional list”:

This list defines the values for the second dropdown depending on the values of the first dropdown.

For value “List1-Value1” you’ll find there 4 values:

Lets have a look into the project:

The Test project has 4 SharePoint List definitions… “List 1” is the “main list” and “List 3” is the “conditional list”. “List 2” will contain the items you create. “RefList” contains the dependencies between “List 1” and “List 3”.

“List 2” contains to custom list forms:

“New2” is used to create new items, “Edit2” is used to edit items.

Lets have a look into “New2”. There are only a few customizations for using the Conditional Lookup control.

This references to the input fields “ff1” and “ff2”:

1:                             <tr> 

2:                                 <td> 

3:                                     <table  border="0"  cellspacing="0"  width="100%"> 

4:                                         <tr> 

5:                                             <td  width="190px"  valign="top"  class="ms-formlabel"> 

6:                                                 <h3  class="ms-standardheader"> 

7:                                                     <nobr> Reference (lookup) to the main list </nobr> 

8:                                                 </h3> 

9:                                             </td> 

10:                                             <td  width="400px"  valign="top"  class="ms-formbody"> 

11:                                                 <SharePoint:FormField  runat="server"  ID="ff1"  ControlMode="New"  FieldName="List2RefToList1FieldA"  /> 

12:                                                 <SharePoint:FieldDescription  runat="server"  ID="ff1description"  FieldName="List2RefToList1FieldA" 

13:                                                     ControlMode="New"  /> 

14:                                             </td> 

15:                                         </tr> 

16:                                         <tr> 

17:                                             <td  width="190px"  valign="top"  class="ms-formlabel"> 

18:                                                 <h3  class="ms-standardheader"> 

19:                                                     <nobr> Reference (lookup) to the conditional list</nobr> 

20:                                                 </h3> 

21:                                             </td> 

22:                                             <td  width="400px"  valign="top"  class="ms-formbody"> 

23:                                                 <SharePoint:FormField  runat="server"  ID="ff2"  ControlMode="New"  FieldName="List2RefToList3FieldA"/> 

24:                                                 <SharePoint:FieldDescription  runat="server"  ID="ff2description"  FieldName="List2RefToList3FieldA" 

25:                                                     ControlMode="New"  /> 

26:                                             </td> 

27:                                         </tr> 

28:                                         <tr  id="idAttachmentsRow"> 

29:                                             <td  nowrap="true"  valign="top"  class="ms-formlabel"  width="20%"> 

30:                                                 <SharePoint:FieldLabel  ControlMode="New"  FieldName="Attachments"  runat="server"  /> 

31:                                             </td> 

32:                                             <td  valign="top"  class="ms-formbody"  width="80%"> 

33:                                                 <SharePoint:FormField   runat="server"  ID="AttachmentsField"  ControlMode="New"  FieldName="Attachments"/> 

34:                                             </td> 

35:                                         </tr> 

36:                                     </table> 

37:                                 </td> 

38:                             </tr> 

39: 

40: 

I needed to change some properties of user profiles of my SharePoint 2010 farm.

Of cource I wanted to do this with PowerShell!

Before you can execute the following script, be sure that your user account is “Admin” on your “User Profile Service Application” and has “Full Control” permissions on the same Service App! – You may get this error: New-Object : Exception calling ".ctor" with "1" argument(s): "No User Profile Application available to service the request. Contact your farm administrator." – You can verify or change this settings in the Central Administration –> Manage Service Applications –> (select User Profile Service Application) –> than:

1. Click “Administrators” –> Add the user that will execute the PowerShell script –> Set “Full Control” for this user –> Click “OK”
2. Click “Permissions” –> Add the user that will execute the PowerShell script –> Set “Full Control” for this user –> Click “OK”

So…

Here is the Script for reading properties from the profile system:

#region Check x64 host
if( [System.IntPtr]::Size -ne 8) {
  Write-Error "Please use a x64 PowerShell host!"
  return
}
#endregion

#region Load SharePoint SnapIn and DLL
  Remove-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
  Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
  
  [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") | out-null    
  
  #Check available SharePoint Cmdlets
  if( (Get-Command -Noun SPWeb*) -eq $null ) {
    Write-Error "SharePoint SnapIn not loaded. SharePoint cmdlets missing!"
    return
  }
#endregion

#User must be set as Full Control *Admin* and with Full Control *Permission* on Central Admin->Manager Service Application->User Profiler Service App!!

$site=(Get-SPSite "http://sharepoint.local")
$sc = [Microsoft.Office.Server.ServerContext]::GetContext($site)

$upm = New-Object "Microsoft.Office.Server.UserProfiles.UserProfileManager" -ArgumentList ($sc)
$enumerator = $upm.GetEnumerator()
$enumerator.Reset()
while( $enumerator.MoveNext() -eq $true ) {
  $currentUserProfile = $enumerator.Current
  $propertiesCollection = $currentUserProfile.ProfileManager.PropertiesWithSection
  if( $currentUserProfile -ne $null -and $propertiesCollection -ne $null ) {
    foreach($p in $propertiesCollection) {
      Write-Output $p.Name $currentUserProfile[$p.Name].Value
    }
    
    #write to a property:
    #$currentUserProfile["FirstName"].Value="Test"
    #$currentUserProfile.Commit()
  }
}

If you need to write property values than uncomment the two lines on the bottom of the script and change them.

BE VERY CAREFULLY!!!!

You can damage your profile system if you do things wrong! – Be sure that your script will only change one property for one user. If you uncomment the script lines above this script would set the property “FirstName”  of every user  to value “Test”!!! – BE VERY, VERY CAREFULLY!!!

Sometimes you may need to create instances of generic classes in PowerShell.

Like this (in C#):

 using  System;

 using  System.Text;

 namespace  tmp1

 {

     class  Program 

     {

         static  void  Main(string [] args)

         {

             System.Collections.Generic.List<string> t = new  System.Collections.Generic.List<string>();

         }

     }

 }

There is a generic class used in the code above: System.Collection.Generic.List.

If you want to create an instance of this class in PowerShell you can not use this:

New-Object "System.Collections.Generic.List<string>"

You’ll receive an error!

Here is the solution: You can use the System.Type that represents other .NET types.

Use this PowerShell code snipped to create an instance of System.Collections.Generic.List<string>

$type = ("System.Collections.Generic.List"+'`'+"1") -as "Type"
$type = $type.MakeGenericType("system.string" -as "Type")
$o = [Activator]::CreateInstance($type)

“$o” will contain the created instance.

You can use this method for all other generic classes.

You may need to change the following details.

1. In the first line of the snipped there is ‘`‘+"1" This is the amount of parameters for the generic class.
2. In the second line you have to specify the parameter types for the generic class. Separate them with “,” and cast them to System.Type by using -as “Type”.
3. In the third line you may need to specify the constructor parameters for creating an instance of the generic class.

Here is another example:

$type = ("System.Collections.Generic.SortedList"+'`'+"2") -as "Type"
$type = $type.MakeGenericType( @( ("System.Int32" -as "Type"), ("system.string" -as "Type") ) )
$o = [Activator]::CreateInstance($type, 100)
$o.Add(1, "test")
$o

This creates an instance of System.Collections.Generic.SortedList<System.Int32, String> with a starting capacity of 10 (line 3: the second parameter of CreateInstance).

For the execution of SharePoint PowerShell scripts I need to check the execution environment of my PowerShell session to be sure that PowerShell runs as x64 application.

This was a problem because PowerShell does not provide this information itself.

BUT PowerShell is a .NET Application.

There you can check for x86 or x64 by using this static method (in C# or VB.NET):

System.IntPtr.Size

In PowerShell syntax:

This results in “4” for x86 and “8” for x64. (Without question marks of cource. The result type is int.)

So you can use this in your PowerShell script.

Here I started 2 PowerShell sessions: one x86 and one x64. See the result of the command above:

(In the window title you see “Windows PowerShell (x86)” –> That’s the x86 session. The x64 session has no special window title.)

Here is a corresponding PowerShell code snipped:

#region Check x64 host
if( [System.IntPtr]::Size -ne 8) {
  Write-Error "Please use a x64 PowerShell host!"
  return
}
#endregion

I have had the problem to set the SharePoint Sevice Account of "SharePoint Server Search" to a special user account during a automatic setup.

In other words: I want to automate this step:

Central Administration -> Security -> Configure Service Accounts

There is no PowerShell command as far as I can see.

You can use this script for this job: