WARNING: Unable to resolve package source 'https://www.powershellgallery.com/api/v2/'.

Hi everybody,

recently I tried to download PowerShell modules inside my development-image in VirtualBox by using the save-module-cmdlet which leads to this errormessage:


PS C:\Windows\system32> save-module microsoftteams -path c:\temp
WARNING: Unable to resolve package source 'https://www.powershellgallery.com/api/v2/'.
PackageManagement\Save-Package : No match was found for the specified search criteria and module name
'microsoftteams'. Try Get-PSRepository to see all available registered module repositories.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1561 char:21
+             $null = PackageManagement\Save-Package @PSBoundParameters
+                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Microsoft.Power...ets.SavePackage:SavePackage) [Save-Package], Exceptio
   n
    + FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.SavePackage


Trying to connect to the displayed https-url also failed while opening it in browser succeded:


PS C:\Windows\system32> invoke-webrequest https://www.powershellgallery.com/api/v2/
invoke-webrequest : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS
secure channel.


So after hours of checking all possible proxy/certificate/ssl-settings, I found the solution in powershell itself:

Because of reasons I had added the SharePoint-Powershell SnapIn to c:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1 which afterwards broke something so that all connections to https broke.

After commenting out the Add-PSSnapin "Microsoft.SharePoint.PowerShell" everything works like a charm.

If you encounter something similar, try this. And if you try to save changes to profile.ps1 ensure that you opened the file in your editor as administrator. You can test the successful save by adding a write-host-output to the screen. Finally don't forget to close the current and reopen a new PowerShell.

Restore deleted Form-WebParts (NewForm.aspx, EditForm.aspx, DispForm.aspx)

If a clever user hits on the idea to delete the form webpart from NewForm.aspx, EditForm.aspx or DispForm.aspx, this can be restored easily with PowerShell. No need to open SharePoint Designer.

Basically a new ListFormWebPart-object must be instanciated, connected with the list and added to the webpartzone of the page. That's it.

Have a look at the following code:

$site = New-Object Microsoft.SharePoint.SPSite -ArgumentList http://sitecollection/sites/site1
$web = $site.OpenWeb()

$list = $web.Lists["My Library"] #title of the regarding list

$webpart = new-object Microsoft.SharePoint.WebPartPages.ListFormWebPart

# assign list to webpart
$webpart.ListId = $list.ID

# possible pagetypes are PAGE_DISPLAYFORM, PAGE_EDITFORM, or PAGE_NEWFORM
# see: https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.webpartpages.listformwebpart.pagetype.aspx
$webpart.PageType = "PAGE_EDITFORM"

# use the absolute link to the form-aspx
$wpm = $web.GetLimitedWebPartManager("http://sitecollection/sites/site1/myLibrary/Forms/EditForm.aspx", [System.Web.UI.WebControls.WebParts.PersonalizationScope]::Shared)

$wpm.AddWebPart($webpart, "Main", 1)

# dispose spweb-object in webpartmanager to avoid memory leaks
$wpm.Web.Dispose()

$web.Dispose()
$site.Dispose() 


Get current versions for activated features (not feature definitions) in a web or site collection

Recently I wrote a PowerShell-Script which writes the current version-numbers of web-features specified by a name-filter into a file. These versions are not from the feature-definition but from the feature activated in a web.

An example for this could be the following:
On a SharePoint-server a feature named custom_feature_1 was installed which has a version of 3.0.0.0 because it's been updated a few times during the lifecycle of the appication.
Because the rootweb was created first, the feature's version is 1.0.0.0 there. A newer subweb below has been created after the feature was updated and there the feature's version is 2.0.0.0. Now, after the third update, another web will be created where the feature now has a version of 3.0.0.0.

So how can you easily get the version of the feature activated in one of these webs?

You can use this PowerShell-script to get all information about your features:

get-spweb http://customsitecollection/customweb |% {$_.Features} | where-object {$_.Definition -ne $null} | where-object {$_.Definition.DisplayName.StartsWith("custom")} |% {new-object psobject -Property @{Id = $_.DefinitionId; Version = $_.Version; DisplayName = ($_ | select -ExpandProperty Definition).DisplayName; Scope = ($_ | select -ExpandProperty Definition).Scope; }} | format-table -Property * -Autosize | Out-String -Width 120 | out-file custom_web_features.txt


Just copy these lines and replace the bold-marked parts by your own needs:
http://customsite/customweb - The full path to the web you want the feature-versions from
custom - The name that the features starts with in SharePoint-Root features-folder
custom_web_features.txt - The name of the file that's created with information

The content of the file should look like this:

You can reuse the script for site-scoped features too. Just replace get-spweb by get-spsite and a valid URL to a sitecollection.

New SharePoint 2013 / 15 cmdlets for Powershell you shouldn't use...

I just browse the web for new things that come with SharePoint 2013 / 15. Now I'm landed on the technet-page for all new Powershell-Cmdlets:

http://technet.microsoft.com/library/ff678226%28office.15%29.aspx

A funny thing are a few new cmdlets you explicitely should avoid to use but the funniest imo are Add-SPSocialAppPermissions and Remove-SPSocialAppPermissions.

So if you belong to the 1% of people with a completely working user profile synchronization service without any issues and you are bored of all the perfectly working sharepoint environment, you should definitively run this cmdlet, because "The use of the Add-SPSocialAppPermissions cmdlet can result in profile synchronization connections that are unusable and non-editable".

More cmdlets you called upon not to use are:

- New-SPBECWebServiceApplicationProxy
- Remove-SPSocialAppPermissions
- New-SPBECWebServiceApplicationProxy

If you have any idea, why Microsoft creates such cmdlets not intended to use by people, please leave a comment :-D

Central administration 2010: Solution store, where did you go?

With no applications- or operations-tab no more, SharePoint's Central Administration looks a little more cleaned up... and messy too. Where the heck did the solutions store from Operations > Solution Management go to? In CA 2010 you'll find it in System Settings > Manage farm solutions or Manage user solutions (for sandboxed solutions):

Alternatively you can get a list of installed farm solutions by using the SharePoint Management Shell Commandlet Get-SPSolution or for user solutions by Get-SPUserSolution.