I used sitecore powershell last year to migration heaps of items.
I installed the latest one and I don't see "Initialization script" field under Console/All Users item.
I had used this field to intialize all my custom scripts like below so that I can access from PSE.
Execute-Script -Item (Get-Item -ID "{0B0E50B9-CD3C-4FE7-BB6D-D2A9AAEB7568}" -Path master:\)
Any help will be good.
This was removed in SPE 3.1 due to the unpredictable nature.
https://github.com/SitecorePowerShell/Console/issues/365
If you could post a new issue on what your custom script does, perhaps we can provide you with an alternate solution.
Related
start "odopen://sync/?siteId=$siteid17&webId=$webid17&listId=$listid17&userEmail=$upn&webUrl=$URL17&webtitle=$webtitle17&listtitle=$listtitle17"
How is it possible to run the following command inside Powershell without an appearing popup window or any userinteraction? I've tried adding /ArgumentList "/S", "/Background". Also tried with -WindowStyle Hidden at the end. Appreciate some help :)
Your command as-is basically says "Start the program that opens odopen:// (OneDrive) links" and can't really be given any silent style instructions. The proper way to configure this kind of thing is through OneDrive Group Policies, but we can cheat and set registry keys.
The link above goes into detail about how to configure group policy, but also tells us that the specific group policy setting to "Configure team site libraries to sync automatically" sets this registry key:
[HKCU\Software\Policies\Microsoft\OneDrive\TenantAutoMount]"LibraryName"="LibraryID"
And that your LibraryID is in this format, which looks familiar:
tenantId=xxx&siteId=xxx&webId=xxx&listId=xxx&webUrl=httpsxxx&version=1
So to put it in a script, I would use something like this, adapted from Nicola Suter's blog post here:
$tenantAutoMountRegKey = "HKLM:\SOFTWARE\Policies\Microsoft\OneDrive\TenantAutoMount"
$autoMountTeamSitesList= #{
#Enter your SharePoint libraries to configure here as key/value pairs
MySharePoint="odopen://sync/?siteId=$siteid17&webId=$webid17&listId=$listid17&userEmail=$upn&webUrl=$URL17&webtitle=$webtitle17&listtitle=$listtitle17"
}
# Check if the key exists and create if missing:
if (-not (Test-Path $tenantAutoMountRegKey)){ New-Item -Path $tenantAutoMountRegKey -Force }
# Add the sites for automatic mounting
$autoMountTeamSitesList | Set-ItemProperty -Path $tenantAutoMountRegKey -Name $_.Key -Value $_.Value
This generally takes effect the next time a user signs into OneDrive, though Microsoft warns it may take up to 8 hours to start syncing (Keeps hundreds of users from syncing the same library at the same time)
TL;DR: You cannot.
Using odopen will always show sign-in window (as stated here: https://learn.microsoft.com/en-us/onedrive/deploy-on-windows#help-users-sign-in), what you can do is only populate it with data, which is what you are already doing.
If you want to do it silently, there is documentation about it: https://learn.microsoft.com/en-us/onedrive/use-silent-account-configuration
So this may be an odd request and maybe I'm going about this all wrong but I also have a unique situation. I have servers that are sometimes cloned and I need to run a script that I created on the clones servers. Due to the nature of the clones they cannot be connected to a network.
Currently I am manually putting the generic script on each server before cloning and then running the script on the clone server.
What I would like to do is have a script that runs and gathers all the information, say installed programs as an example, and generate a custom version of my current script on the servers before they are cloned.
I have both the powershell script that gets the server information and the generic one that makes the changes to the clone but I have not found a way to merge the two or any documentation so I don't know if i am hitting a limitation with this one.
Edit for more explanation and examples. I'm doing this from my phone atm so I dont have an example I can post.
Current I have a script that has a set number of applications to uninstall, registry keys to remove, services to stop ect. In another application I have a list of all the software that we have for each server and I can pull that data for each server. What I need to do is pull the data for each server, and have a script placed on each server that will uninstall just the programs for that server.
Currently the script has to run through every potential software and try to uninstall it and then check the other application to see if there are any additional programs that need to be uninstalled.
Hope this extra info helps.
Thanks.
Stop thinking of it as code.
Use script 1 to export blocks of text into a new file. for example, you might have a configuration that says all Dell servers must have this line of code run:
Set-DELL -attribute1 unmanaged
where on HP, the script would have been
Set-HP -attribute1 unmanaged
on web servers, you want:
set-web -active yes
where if not a web server, you want nothing.. so, your parent script code would look like:
$Dell = "Set-DELL -attribute1 unmanaged"
$HP = "Set-HP -attribute1 unmanaged"
$web = "set-web -active yes"
if (Get-servermake -eq "Dell")
{
$dell | out-file Child.ps1 -append
}
if (Get-servermake -eq "HP")
{
$HP | out-file Child.ps1 -append
}
if (Get-webserver -eq $true)
{
$web | out-file Child.ps1 -append
}
The result is a customized script for the specific server, child.ps1.
Now, you can take this and run with it. You could say add functionality to the child script like "Is it an AD controller", etc.
However, you might be better off having all of this in a single script, and just block off sections that don't apply in an if statement for example.
I'm still not totally sure I understand what your asking. If I've missed the mark, tell me how, and I'll tell you how to tweak this better. (And hopefully obvious is that the Get-whatever is sample code. I don't expect that to be what your using to determine a computer make/model/etc)
I have this large application that I am using Windows RM 3.0 to deploy Databases, SSIS packages, and other things to multiple different servers and it is working just fine. It was requested that branding changes to a Business Intelligence SharePoint site be added to this process as well. So I create a custom build script to do so, and set Win RM to run this command from PowerShell on Sharepoint server
Install-SPSolution –Identity Payload\SharepointDeploy.wsp –WebApplication http://localhost/ -GACDeployment
when I run that, I get the following error
Install-SPSolution : Microsoft SharePoint is not supported with version 4.0.30319.18444 of the Microsoft .Net Runtime.
Reading around, it seems its a PowerShell 3.0 issue and when running in 2.0 it works fine. However, my existing process requires PowerShell 3.0 to work properly. Is there anyway to get this working with 3.0? Or can I spin up a 2.0 instance using an Invoke-Command or something? I can provide more details if needed.
You can build a custom endpoint which will run the required version of PowerShell. That way you won't have to mess with the default endpoint which you probably want to keep with its defaults
This would require you to connect to the new endpoint with something like
new-pssession -computername "SharePoint01" -configurationName "psv2".
You build and endpoint with the following cmdlet:
New-PSSessionConfigurationFile -Path "psv2session.pssc"
And then register an endpoint using that config with this cmdlet:
Register-PSSessionConfiguration -Name psv2 -Path psv2session.pssc –ShowSecurityDescriptorUI
It's fairly easy to do, and this link provides a good introduction to the setup:
http://blogs.technet.com/b/heyscriptingguy/archive/2014/04/02/build-constrained-powershell-endpoint-using-configuration-file.aspx (although the blog deals with constrained endpoints, the teqnique is essentially the same for what you need to do)
I was facing the same issue with console application, I decreased the framework version from 4.5 to 3.5 from the project properties page and I works perfect!
I'm following the instructions from here:
http://scottmuc.com/blog/development/pester-bdd-for-the-system-administrator/
I'm finding that having installed and imported the module I still can't run Create-Fixture.
Has anyone come across this?
Turns out Create-Fixture isn't a cmdlet any more. I had a look here:
https://github.com/mwrock/Chocolatey-Packages/blob/master/pester/Pester.psm1
and realised the name of the cmdlet has been changed. It's now called New-Fixture.
If you run New-Fixture it even references Create-Fixture:
PS D:\edsource\Powershell> New-Fixture
invalid usage, please specify (path, name)
eg: .\Create-Fixture -Path Foo -Name Bar
creates .\Foo\Bar.ps1 and .\Foo.Bar.Tests.ps1
After reading several other blog posts and articles (references found below) there appear to be several ways to run PowerShell on .NET 4.0 but few are sufficient for our purposes. Due to how we deploy our software we cannot update the registry or change add an application. This leaves us with two options, create our own shell by using ConsoleShell or override PSHost. We would like to be able to use the first option, ConsoleShell, due to it's simplicity but would like to know what issues we may encounter and whether doing so is recommended.
Reference
Based on other questions I have seen that you can use the following methods to run PowerShell as .NET 4.0. None of these methods appear to be officially sanction by Microsoft but the first shown below is included as a work around in this Microsoft connect issue.
The options to run PowerShell in .NET 4.0 appear to include:
Update the app.config to include .NET 4.0 as supported
Add a registry setting to switch the version
Use ConsoleShell to host your own PowerShell Console
Implement your own PowerShell host, PSHost , as done by PoshConsole or Nuget
As far as it is not officially approved (to my knowledge), then nobody can approve it but you. If your scenario works and passes reasonable tests, approve and use it.
I use PowerShell on .NET 4.0 but with the option 4, and used to use the option 1, too (I do not like the option 2, personally). Thus, I approved it, production or not, I use it a lot and it works. I still use PowerShell on .NET 2.0 for two reasons: 1) PowerShell.exe starts faster (especially x64); 2) to be sure that part of my PowerShell development is compatible with .NET 2.
Another thought. If something does not work properly in PowerShell on .NET 2.0 (there are some issues, indeed, see Connect) then the fact "it is approved for production" itself does not help much. One has to overcome existing issues, .NET 2 or .NET 4 does not matter.
P.S. I should have mentioned that I tried the option 3 as well. I did not find use cases suitable for using it in my scenarios. But I did not find any issues in using ConsoleShell either.
P.P.S Yet another option. Make a copy of PowerShell.exe, rename it into MyConsoleShell.exe, use it together with MyConsoleShell.exe.config configured for .NET 4. As far as you are going to use a separate application anyway, then why not to consider this?
I'm a bit of a powershell N00b, but I threw this together as a way of forcing an arbitrary script to use .NET 4.0 in my script:
# Place this at the top of your script, and it will run as a .NET 4 ps script.
# #############################################################################
if ($PSVersionTable.CLRVersion.Major -lt 4) { try {
$cfgPath = $Env:TEMP | Join-Path -ChildPath ([Guid]::NewGuid())
mkdir $cfgPath | Out-Null
"<configuration><startup useLegacyV2RuntimeActivationPolicy='true'><supportedRuntime version='v4.0'/></startup></configuration>" | Set-Content -Path $cfgPath\powershell.exe.activation_config -Encoding UTF8
$darkMagic = 'COMPLUS_ApplicationMigrationRuntimeActivationConfigPath'
$old = [Environment]::GetEnvironmentVariable($darkMagic)
[Environment]::SetEnvironmentVariable($darkMagic, $cfgPath)
& powershell.exe $MyInvocation.MyCommand.Definition $args
} finally {
[Environment]::SetEnvironmentVariable($darkMagic, $old)
$cfgPath | Remove-Item -Recurse
return
}}
# ##############################################################################
# My script starts here:
echo "Your arguments are: $args "
echo "The CLR Major Version is : $($PSVersionTable.CLRVersion.Major)"
It places a check in the beginning of the script, and if it's not .NET 4.0 it creates a configuration file, sets an environment variable and re-runs the powershell script so that it runs under .NET 4.0.
it does incur a bit of a startup time penalty of about a second or so on my pc, but at least it works :)