https://blogs.msdn.com/b/windowsazure/archive/2012/03/10/summary-of-windows-azure-service-disruption-on-feb-29th-2012.aspx

A factual, actionable, and humble article... Makes me feel proud to work at Microsoft.

-Michiel

When SQL Server Agent starts SQLPS.EXE, it does not do this through the console (there is no console attached).

The $Host variable will indicate what host is attached to your runtime. When running SQLPS.EXE on a console this will be your host:

PS C:\Users\mwories> $Host

Name             : ConsoleHost
Version          : 2.0
InstanceId       : 40b6135d-0f89-4b12-b44e-d3d70a729343
UI               : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture   : en-US
CurrentUICulture : en-US
PrivateData      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace

However print the host variable in an Agent Job and you will see this:

Name             : Default Host
Version          : 2.0
InstanceId       : 9cf1e259-93b1-476f-8c3f-6fe9cf935aab
UI               : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture   : en-US
CurrentUICulture : en-US
PrivateData      :
IsRunspacePushed :
Runspace         :

The article How PowerShell Works explains well how the runspace interacts with the host.

The Host implement PSHostUserInterface and PSHostRawUserInterface that form the display interface. These may not implement certain methods for the Default Host. And indeed, for the Default Host (the host an Agent Job receives, as there is no console), the method that implements Write-Host is not available, and it will fail with the following message:

Executed as user: REDMOND\mwories. A job step received an error at line 3 in a PowerShell script. The corresponding line is 'write-host 'foobar''. Correct the script and reschedule the job. The error information returned by PowerShell is: 'Cannot invoke this function because the current host does not implement it.  '.  Process Exit Code -1.  The step failed.

Now what to do when you want to create your scripts to run in a console but also hosts that may not have a console, and may not implement any host output interface?

This will work.

if ($host.Name -eq "ConsoleHost")
{
 write-host 'foobar'
}

Of course you can find ways to simplify your scripts by wrapping this in a function that only writes output when a console is attached.

If there is any output that you like to be logged, it will not appear in the SQL Agent output. It is therefore better to use Write-Output if you want to provide some kind of output that shows up in SQL Agent output or history.

Hope this helps to understand the PowerShell subsystem in SQL Server Agent a bit better.

https://sqlblog.com/blogs/allen_white/archive/2009/06/08/handling-errors-in-powershell.aspx

There is an addtional method to get more information available. I found myself sending this little code snippet in email to many, and almost always I get the response that it saved that person with a ton of work, as new users to PowerShell are often left bewildered by the sparse error information; I had colleagues grabbing for the debugger to find the more detailed error messages...

An example; let's generate a simple error (recreate master will not work on most systems):

$db = new Microsoft.SqlServer.Management.Smo.Database
$db.Name = "master"
$db.Parent = get-item .
$db.Create()
Exception calling "Create" with "0" argument(s): "Create failed for Database 'master'. "
At line:1 char:11
+ $db.Create( <<<< )

Not very helpful is it?

Here is where this little gem comes in:

$error[0]|format-list -force

Now let's take a look at the details this emits:

Exception      : System.Management.Automation.MethodInvocationException:
                        Exception calling "Create" with "0" argument(s): "Crea
                        te failed for Database 'master'. " ---> Microsoft.SqlSe
                        rver.Management.Smo.FailedOperationException: Create fa
                        iled for Database 'master'.  ---> Microsoft.SqlServer.M
                        anagement.Common.ExecutionFailureException: An exceptio
                        n occurred while executing a Transact-SQL statement or
                        batch. ---> System.Data.SqlClient.SqlException: Databas
                        e 'master' already exists. Choose a different database
                        name.
                           at System.Data.SqlClient.SqlConnection.OnError(SqlEx
<cutting middle part out>
TargetObject          :
CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
FullyQualifiedErrorId : DotNetMethodTargetInvocation
ErrorDetails          :
InvocationInfo        : System.Management.Automation.InvocationInfo

Well, now THAT's more like it!

As you can see the -force flag does a couple of nice things.

1. It concatenates the error messages into a somewhat understandable result.
2. It dumps stack information + all other error information avalable.

Generally it's a time saver as you have this command readily available for you at the command line.

Do you have any tips on error handling? I'd love to hear about it.

-Michiel

If you want to learn more about SQL Server Powershell download the podcast here : https://www.runasradio.com/default.aspx?showNum=75

If you listened to it then please post your feedback here.

Happy listening!

We did provide some basic cmdlets to start you off with. We know that DBA's willl have tons of T-SQL scripts that they will not abandon immediately in favor of Powershell. These scripts can be integrated with Invoke-Sqlcmd. We also provided a cmdlet to evaluate Policies, something that will come in handy if you have a lot of servers to manage (see one of my previous posts that contains a reference to an excellent blog entry from Lara on this subject).

Right now you will find that you can navigate to four different object models:

• SQL Server Relational Managenent Objects (SMO)
• Policy Based Management Objects (DMF)
• Data Collection (DC)
• Server Registration

An interesting fact is that the SQL Provider that provides access to these models is almost totally agnostic about these models. It does navigation, and serves these objects to the Powershell host, but without any code that is aware of each of these models. It's made pretty generic and the plan is to start covering all other services (Analysis Server's AMO, RS, etc.) in the same fashion.

Now, back to 'where are the cmdlet's'.

We do plan to provider various common cmdlets for common tasks, such as backup, restore, transfer, adding logins and users (pending customer research). But with the provider serving up objects you have almost instant access to any adminstrative commands you need. Let me illustrate this with an example:

Another thing to point out is that if you take a look at SMO, DMF, DC, RS, AMO, and the other object models you will find there are hundreds of different of objects and literally thousands of operations you can perform. Strictly speaking, if you were to provider full coverage you would end up with hundreds (maybe over a thousand) cmdlets. This makes discoverability quite cumbersome (let alone it is a huge investment to unlock something that is inherently available). And the complexity of some of the cmdlets would make it not practical. Take for example the Transact-SQL statement to create a table. This is a very hard thing to encapsulate in a cmdlet (or new-item). Go try to think up the cmdlet to support all of CREATE TABLE. This is where the provider will be your friend. Issue a Get-Item to grab the parent. Instantiate a new SMO object and modify it to your liking. Then parent it with the reference you received from the Provider and create it. This is how this looks like:

 https://blogs.msdn.com/powershell/archive/2008/06/23/sql-minishells.aspx

 Jeffrey is Powershell's Architect, well respected in the Powershell community, and it's good to read about his perspective on this.

https://sqlblog.com/blogs/lara_rubbelke/archive/2008/06/19/evaluating-policies-on-demand-through-powershell.aspx

-          SQLPS – a minishell that gives you a complete pre-configured Powershell with all of SQL Server’s extensions preloaded.

-          SQL Server Agent integration – A new job subsystem for Powershell

-          SQL Server Management Studio Integration – context menus on every applicable node in Object Explorer (with connection context reuse. Including SQL security!)

-          Four new Providers! – new providers for SQL Server relational engine, Registered Servers, Data Collection, and SQL Server Policy Management

-          SQLCMD integration – SQLCMD compatible script execution within Powershell (reuses the SQL Server connection context, and even database context of the provider!)

-          SQL Server Policy Management integration – Allows evaluation of any Policy

-          Various other cmdlets – support the provider, such as conversion of a SMO Urn to a Powershell path, encoding and decoding of SQL identifiers.

-          SQL Server Powershell redist – allows you to install SQL Server Powershell with your application or on any machine you need to have it on (this still being built so with the caveat it may be shipped later, or being cut altogether – don’t flame me yet).

As always with every release, a lot of things were left on the cutting floor, such as Powershell editor integration & execution within SSMS (with grid output), Powershell script generation from any SSMS menu, SMO objects generating Powershell script, more cmdlets that address common user scenarios, Analysis Server support. And this doesn’t include a long list of ideas that for the sake of brevity will not discuss here.

The excitement about this release is palpable, and there is no shortness of ideas for the next releases. I think you’ll be pleased with this first release.

---

From recent posts and email I know there is some explanation needed why we ship ‘pre-packaged’ SQLPS functionality. Let me address that here as well.

SQLPS is slated to be replacing SQLCMD and other tools that people now use to do ad-hoc management and management task automation. It’s more than that, we want uniformity of management across ALL of SQL Server services, whether it is Analysis Server, SQL Server, Integration Services, Reporting Services etc.

SQLPS.exe is a Minishell (also called “custom shell”). It is a form of pre-packaging of Powershell functionality, and it is available to anyone who wants to do this (make-shell). It is regular Powershell, albeit with limitations that the Powershell team decided to impose on it – it is a ‘closed’ shell, which doesn’t allow adding other snapins.

We are shipping SQLPS to make life of our DBA’s a whole lot easier. If they need to have quick access to the SQL providers, assemblies, cmdlets, default security settings, everything is there. We could have possibly done this through a startup script but not everything can be accomplished this way. We are changing the default security settings, without affecting the settings for overall Powershell. Minishells have their own settings.

We also use SQLPS to execute SQL Agent jobs. We pipe the data into SQLPS, as we cannot pass it on the cmdline. From that perspective it serves our purpose very well. This is somewhat harder (if not impossible) to accomplish using the startup script approach.

That said, in the next release we will look into it to ship a SQPS that is more flexible. Listening to the feedback, we should have a form of packaging that allows users to add cmdlets/providers.

We are however not stopping anyone to create their own startup scripts that include the cmdlets and/or providers for SQL Server, Exchange, IIS etc. etc.  To get you started on this, here is a script that exactly does that:

#
# Initialize-SqlpsEnvironment.ps1
#
# Loads the SQL Server provider extensions
#
# Usage: Powershell -NoExit -Command "& '.\Initialize-SqlPsEnvironment.ps1'"
#
# Change log:
# June 14, 2008: Michiel Wories
#   Initial Version
# June 17, 2008: Michiel Wories
#   Fixed issue with path that did not allow for snapin\provider:: prefix of path
#   Fixed issue with provider variables. Provider does not handle case yet
#   that these variables do not exist (bug has been filed)

$ErrorActionPreference = "Stop"

$sqlpsreg="HKLM:\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.SqlServer.Management.PowerShell.sqlps"

if (Get-ChildItem $sqlpsreg -ErrorAction "SilentlyContinue")
{
    throw "SQL Server Powershell is not installed."
}
else
{
    $item = Get-ItemProperty $sqlpsreg
    $sqlpsPath = [System.IO.Path]::GetDirectoryName($item.Path)
}

There are a couple of things you need to know.

• SQL Server does not need a reboot when the password is modified. We (SQL Server Team) spent quite a bit of time ensuring you do not suffer any unnecessary downtime when performing an operation that has to happen regularly, when password are expiring. Everyone likes a ‘no reboot’ clause, right?
• When changing the account and password, the service does need a reboot, but the WMI Provider does this for you. In fact, if the service is not started it will be brought up for a short moment. If it already running it will be restarted. The reasons are as follows:
• The service master key needs to be re-encrypted
• Various other security settings are done
• Because the WMI Provider performs various operations besides changing the service account, other account change methods like ‘sc’ or the standard service control panel are not supported. You may see that the service will not start in some cases.
• Changing the password only tells the service that the password has changed. If you want to change the account’s password, use a command like NET USER. You need to run that first.

The following scripts allow you to change the service account + password, or only the password:

setaccount.vbs:

‘ Set the account and password

set svr = GetObject("WINMGMTS:\\.\root\Microsoft\SqlServer\ComputerManagement:SqlService.ServiceName='MSSQL$YUKON',SQLServiceType=1")

svr.SetServiceAccount ".\TestUser", "NewPassword!!"

setpwd.vbs:

‘ Set the password

set svr = GetObject("WINMGMTS:\\.\root\Microsoft\SqlServer\ComputerManagement:SqlService.ServiceName='MSSQL$YUKON',SQLServiceType=1")

svr.SetServiceAccountPassword "", "NewPassword2!!"

You need to change 'MSSQL$YUKON' to match your instance name (replace ‘YUKON’ with the instance name, or the entire string with MSSQLSERVER for the default instance). Of course the account and password need to be changed as well.

Try this on a test server first before running this on a production server.

I hope this is helpful,

Michiel