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:

When you receive this error

Unable to connect to the specified address. Verify the URL you entered and contact the service administrator for more details.

…and you have done the exchange of farm certificates than you forgot this step:

$consumingFarmID=<Farm GUID of the consuming farm>

$security=Get-SPTopologyServiceApplication | Get-SPServiceApplicationSecurity

$claimprovider=(Get-SPClaimProvider System).ClaimProvider

$principal=New-SPClaimsPrincipal -ClaimType "http://schemas.microsoft.com/sharepoint/2009/08/claims/farmid" -ClaimProvider $claimprovider -ClaimValue $consumingFarmID

Grant-SPObjectSecurity -Identity $security -Principal $principal -Rights "Full Control"

Get-SPTopologyServiceApplication | Set-SPServiceApplicationSecurity -ObjectSecurity $security

(Technet: http://technet.microsoft.com/en-us/library/ff700211.aspx)

See the first line of the script:

$consumingFarmID=<Farm GUID of the consuming farm>

→ Here you need to execute this PowerShell code snippet and insert the resulting GUID in the script above:

(Get-SPFarm).Id 

If you want to install windows features by script you have to use one of the tool OCSETUP oder DISM.

E.g.
start /w ocsetup <component_name>
or
dism /online /enable-feature:<component_name>

BUT: What are the “component names” for the Windows features? First of all: These “component names” are technical names, not the “display names” you will find in Control Panel -> Turn Windows features on or off

You can get a list of the available features if DISM tool is available:

dism /online /get-features

BTW: The component names are case-sensitive!!! – E.g. the component name “NetFx3” (for “Microsoft .Net Framework 3.x”) is not the same as “netfx3”.

But sometimes the technical feature names are very diffrent from the display names. For example: “IIS-LegacySnapIn” is the name for this “IIS 6 Management Console”



Here you’ll find complete lists for the mapping of display name and technical component name

I tried to create a new SharePoint Server 2010 farm by using PowerShell cmdlet “New-SPConfigurationDatabase” in one of the first steps.

I got this error:

This is my script:

After debugging I found the following:

When I write the value of variable “$sppassphrase” the the console (with cmdlet write-host) I get:
GOY%3YTdS&
instead of
GOY$sV3SthlkyN%3YTdS&

The problem is: The part “$sV3SthlkyN” will be interpreted as variable name!!!

You have to use escape sequences at least for the “$” character:

$sppassphrase=“GOY`$sV3SthlkyN%3YTdS&”

UPDATE!

Use ‘ instead of ” and you will not have a problem at all!

You’ll get what you’ve expected: The correct password string including “$”… (But the solution above also works!)