PowerShell | Starting running scripts

By -
For first steps,
- Install / make sure PS is installed
- Run PS command-line with admin privileges
- Run "Set-ExecutionPolicy Unrestricted" to enable the system to run scripts

"By default, PowerShell has scripting support disabled. If you try and run a PowerShell script, you will be greeted with an error stating that the execution of scripts is disabled on your system."
http://www.tech-recipes.com/rx/2513/powershell_enable_script_support/

Update:
This is usually needed when running scripts for the first time. System presents us with errors such as:
File C:\Common\Scripts\hello.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about_signing" for more details.

Update: Output of "help set-executionpolicy -detail" command

SYNOPSIS
    Changes the user preference for the Windows PowerShell execution policy.


SYNTAX
    Set-ExecutionPolicy [-ExecutionPolicy] {Unrestricted | RemoteSigned | AllSigned | Restricted | Default | Bypass | Undefined} [[-Scope] {Process | CurrentUser | LocalMachine | UserPolicy | MachinePolicy}] [-Force] [-Confirm] [-WhatIf] []

DESCRIPTION
    The Set-ExecutionPolicy changes the user preference for the Windows PowerShell execution policy.

    To run this command on Windows Vista, Windows Server 2008, and later versions of Windows, you must start Windows PowerShell with the "Run as administrator" option, even if you are a member of the Administrators group on the computer.

    The execution policy is part of the security strategy of Windows PowerShell. It determines whether you can load configuration files (including your Windows PowerShell profile) and run scripts, and it determines which scripts, if any, must be digitally signed before they will run.

    For more information, see about_Execution_Policies.


PARAMETERS
    -ExecutionPolicy Specifies a new execution policy for the shell. The parameter name ("Name") is optional.

        Valid values are:

        -- Restricted: Does not load configuration files or run scripts. "Restricted" is the default.

        -- AllSigned: Requires that all scripts and configuration files be signed by a trusted publisher, including scripts that you write on the local computer.

        -- RemoteSigned: Requires that all scripts and configuration files downloaded from the Internet be signed by a trusted publisher.

        -- Unrestricted: Loads all configuration files and runs all scripts. If you run an unsigned script that was downloaded from the Internet, you are prompted for permission before it runs.

        -- Bypass: Nothing is blocked and there are no warnings or prompts.

        -- Undefined: Removes the currently assigned execution policy from the current scope. This parameter will not remove an execution policy that is set in a Group Policy scope.

    -Force []
        Suppresses all prompts. By default, Set-ExecutionPolicy displays a warning whenever you change the execution policy.

    -Scope
        Specifies the scope of the execution policy. The default is LocalMachine.

        Valid values are:

        -- Process: The execution policy affects only the current Windows PowerShell process.
        -- CurrentUser: The execution policy affects only the current user.
        -- LocalMachine: The execution policy affects all users of the computer.

        To remove an execution policy from a particular scope, set the execution policy for that scope to Undefined.

    -Confirm []
        Prompts you for confirmation before executing the command.

    -WhatIf []
        Describes what would happen if you executed the command without actually executing the command.

   
        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer and OutVariable. For more information, type,
        "get-help about_commonparameters".

Comments

Post a Comment

Popular posts from this blog

Breaking down document locking in SharePoint

By -
Image
This is a topic I've been meaning to discuss in a while. We open, change and close documents almost every day, and sometimes we collaborate with other people at the same time on those documents. SharePoint brings all co-authoring features we need, straight out-of-the-box, but sometimes, there are problems. While things are starting to look better on the cloud side, the concept of document locking is still very much up-to-date and understanding how it works and what to do when things go wrong is crucial. In an article that has since disappeared the Microsoft Knowledge Base (but still available here ), Microsoft explains it best: When a document is opened by a client program, Windows SharePoint Services puts a write lock on the document on the server. The write lock times out after 10 minutes. Users cannot modify the document during the time when the document is locked. In a scenario where the program that opens the document unexpectedly quits or crashes and you try to open the do
Read more

Working around X-Frame-Options for iframes

By -
Image
The problem: One of the first things we noticed after migrating to SharePoint 2013 was that our iframes have stopped working, giving the error: "Refused to display 'http://contoso/pages/home.aspx' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'." Quickly we could see that this is in fact a security mechanism to prevent click-jacking and others: "The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a frame or iframe. Sites can use this to avoid Clickjacking attacks, by ensuring that their content is not embedded into other sites." Soon we realized that, starting SharePoint 2013, an HTTP Module is adding the header " X-Frame-Options " by default, with the value " SAMEORIGIN ". This is effectively preventing the rendering of pages outside the scope of the current web application. The (attempted) solution: So what to do?
Read more

Document ID not being generated

By -
Image
Problem In a scenario where we have many document Content Types, we may want to enable Document ID - aka "Permanent Links" - which is a feature in SharePoint that assigns a specific ID for each document. That ID never changes even if the document is renamed or moved to another location. In this scenario, the Document ID field was being generated for some libraries/content types, but not others, which is a surprisingly common problem. Background There are several stages we need to go through to enable use this mechanism. Stage 1 We enable the feature in the Site Collection Features. Stage 2 Under Site Collection Administration > Document ID Settings, we need to enable the assignment and pick a prefix. The IDs use the format: PREFIX-LISTID-LISTITEMID ( ref ) Where: PREFIX: the preconfigured prefix for the site collection, which can be any set of numbers and letters between 4-12 characters LISTID: the property docid_msft_hier_listid of the list
Read more