PowerShell

Introduction

Almost a year ago, I wrote an article on this topic. Since it appeared in my search results for the same question again (that’s why I am blogging - not enough, to be honest), I took the opportunity to review the article and post an updated version with an improved script.

It’ll still update installed modules and remove older version in the C:\Users\<username>\Documents\PowerShell\Modules folder, but in a more userfriendly way :-)

Introduction

From time-to-time I am updating all installed PowerShell modules on my dev-machines. This can lead to a large amount of used disk space, as old versions are kept on the drive. In this post, I want to share the scripts for the two tasks. After updating modules, I noticed a large amount of data is stored in my C:\Users\<username>\Documents\PowerShell\Modules folder. To be specific, the folder eats up 3.1GB of space. Therefore I needed a cleanup script as well :-)

Set-AzureWebsite : No default subscription has been designated. Use Select-AzureSubscription -Default to set the default subscription.

*doh* Again I’ve used PowerShell comandlets for Azure classic instead of Resource Manager 🙁

Reminder: Always check for the magic “Rm” chars in the command, if a resource cannot be found.

A Runbook schedule can be triggered every hour. If you need a smaller interval, like every minute, you can use the Azure Scheduler to do so.
So I went to the Azure Portal, created an Azure Schedule instance (with a job collection tier of at least basic, to be able to create schedules that are triggered every minute) and called a Runbook via webhook.

The Runbook contains a cmdlet that results in an error 🙁
Get-AzureRmMetric : The term 'Get-AzureRmMetric' is not recognized as the name of a cmdlet, function, script file, or<br /> operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try<br /> again.
Azure cmdlets can be made available through the Automation Account the Runbook is using. The “Browse Gallery” link will let you find and choose the necessary cmdlets.

The error message above appears, because a) the cmdlet was not installed and b) the referenced version of AzureRM.profile was to old. Fortunately the problem can be resolved easily by upgrading the Azure modules.

After all modules are up to date, I could add the desired module and my runbook wasn’t complaining anymore 🙂

To be able to connect to a secure Service Fabric Cluster via PowerShell, you need to import the certificate specified into your personal certificate store. Otherwise an Exception will be thrown. Unfortunately the Exception does not point into the right direction 🙁

So in case you get an Exception like this

Connect-ServiceFabricCluster : An error occurred during this operation. Please check the trace logs for more details.
At line:1 char:1
+ Connect-ServiceFabricCluster -ConnectionEndpoint xyz-sf-de …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Connect-ServiceFabricCluster], FabricException
+ FullyQualifiedErrorId : CreateClusterConnectionErrorId,Microsoft.ServiceFabric.Powershell.ConnectCluster

Often, you’ll need some users with data like picture and manager in your new development environment. Since you usually recycle your dev AD, this doesn’t happen frequently. But if you have to set up a new domain, you’ll want testusers with data.

I don’t want to search again, because I found a great resource for creating users here: http://mrhodes.net/2011/10/25/adding-285-contoso-users-with-pictures-to-your-development-environment-active-directory/

Have fun with PowerShell

If your site is missing the three default groups “Visitors”, “Members” and “Owners”, you can create them easily with PowerShell or the Object Model.

Add-PSSnapin Microsoft.SharePoint.PowerShell

$web = Get-SPWeb https://your.site.url
if ($web.AssociatedVisitorGroup -eq $null) {
    Write-Host 'The Visitor Group does not exist. It will be created...' -ForegroundColor DarkYellow
    $currentLogin = $web.CurrentUser.LoginName

    if ($web.CurrentUser.IsSiteAdmin -eq $false){
        Write-Host ('The user '+$currentLogin+' needs to be a SiteCollection administrator, to create the default groups.') -ForegroundColor Red
        return
    }

    $web.CreateDefaultAssociatedGroups($currentLogin, $currentLogin, [System.String].Empty)
    Write-Host 'The default Groups have been created.' -ForegroundColor Green
} else {
    Write-Host 'The Visitor Group already exists.' -ForegroundColor Green
}

 

A new version is out. If brings some great new extensions (two of them are from me 🙂 )

v5.0.4.6440 (2015-04-04)

• New: All extensions added: Blocked file extensions, content type hub, custom crawl connector, features, logging configuration, managed metadata, re-ghost, search schema, secure store, site structure, CSOM extensions for files and 2013 workflows
• Updated: SharePointVersions.xml
• Updated: Typos in comments fixed and some code clean-up
• First release based on GitHub repository

Grab your version from http://spsd.codeplex.com

Deploying Solutions can be a …. (fill in as you wish).

The SharePoint Solution Deployer offers a great opportunity to writing your own scripts. The existing functionality should match your needs to deploy SharePoint Solutions. If not, the “framework” can be extended with custom Extensions or simple PowerShell code.

I’ve written two Extensions, which let you enable and disable features upon deployments and reset files to their site definitions (aka ReGhost).

Time for some PowerShell!

Almost every PowerShell script need some configuration parameters. With this post I want to show one way, there are others ;-), to parse a config file in XML format and use the values later.

The solution I’m going to show to you contains three files. A PowerShell script, a XML configuration file and a helper PowerShell file that contains a function to parse the config file.