Post reply

Cumulative Update 9 and PowerShell...

  • June 5, 2017 at 8:36 am

    #402135

    FYI.. After I installed CU9 on my 2012 SP3 instances, the path for the SQLPS module was apparently removed from the path. 

    Import-Module SQLPS

    I had to add that back to get my PowerShell scripts to run:

    $env: PSModulePath = $env: PSModulePath + ";C:\Program Files (x86)\Microsoft SQL Server\110\Tools\PowerShell\Modules"

    That was what I experienced, anyway..

  • June 5, 2017 at 8:54 am

    #1945419

    If may want to add a registry entry to make the module path permanent:

    $CurrentValue = [Environment]::GetEnvironmentVariable("PSModulePath", "Machine")

    [Environment]::SetEnvironmentVariable("PSModulePath", $CurrentValue + ";C:\Program Files (x86)\Microsoft SQL Server\110\Tools\PowerShell\Modules", "Machine")

  • June 7, 2017 at 2:00 pm

    #1945895

    What version of SSMS are you using?
    The module SqlServer is the replacement for SQLPS and that gets installed with the newer versions of SSMS - since July 2016. I have read that there are some issues with running both modules so maybe something with that happened. But it looks like SQLServer module would be preferred over the SQLPS module.
    You may want to check and see if you have the directory for the SQLServer module - Program Files\WindowsPowerShell\Modules\SqlServer
    There is some more information on the change in the modules in these links:
    SQL PowerShell: July 2016 update
    The PowerShell Module Formerly Known as SQLPS

    Sue

  • June 7, 2017 at 8:08 pm

    #1945923

    bartedgerton - Monday, June 5, 2017 8:36 AM

    FYI.. After I installed CU9 on my 2012 SP3 instances, the path for the SQLPS module was apparently removed from the path. 

    Import-Module SQLPS

    I had to add that back to get my PowerShell scripts to run:

    $env: PSModulePath = $env: PSModulePath + ";C:\Program Files (x86)\Microsoft SQL Server\110\Tools\PowerShell\Modules"

    That was what I experienced, anyway..

    Thanks for the tip.  We're getting ready to install CU9 ourselves.

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".
    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • June 8, 2017 at 2:50 pm

    #1946074

    The version of SSMS is the samve version as SQL Server 2012 SP3/CU9:  11.0.6598
    The PowerShell dlls are version 11.0.6020
    I don't have any files at C:\Program Files\WindowsPowerShell\Modules, nor in the x86 directory..

    select @@version

    Microsoft SQL Server 2012 (SP3-CU9) (KB4016762) - 11.0.6598.0 (X64)
     Apr 18 2017 17:03:30
     Copyright (c) Microsoft Corporation
     Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

    I have not tried the 2016 standalone SSMS install, that might fix the issue as well.

  • June 8, 2017 at 3:42 pm

    #1946077

    bartedgerton - Thursday, June 8, 2017 2:50 PM

    The version of SSMS is the samve version as SQL Server 2012 SP3/CU9:  11.0.6598
    The PowerShell dlls are version 11.0.6020
    I don't have any files at C:\Program Files\WindowsPowerShell\Modules, nor in the x86 directory..

    select @@version

    Microsoft SQL Server 2012 (SP3-CU9) (KB4016762) - 11.0.6598.0 (X64)
     Apr 18 2017 17:03:30
     Copyright (c) Microsoft Corporation
     Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

    I have not tried the 2016 standalone SSMS install, that might fix the issue as well.

    Thanks for posting back the info.
    I doubt it would fix the issue if you started using the SSMS separate installs - version issues like these really irritate me. I've hit different ones with Powershell and am just trying to personally get a better understanding of how and when things like this break.
    It doesn't look like it should have changed from SQL Server 2012 install - mine didn't with that or SQL Server 2014. I thought maybe it could have changed if you were using the separate SSMS installs. But I've also had things in my Powershell module directory for for at least a couple of years so we have some differences for whatever reasons.
    If nothing else, at least you know about the switch to the SQLServer module from the SQLPS module. The SQLServer module has more functionality and kept the original cmdlets from SQLPS so it seems to be a good change. SQLServer module is what is instantiated when you invoke Powershell from within the stand alone version of SSMS.
    Hopefully Jeff will check on the env Module path and see if it changes when he applies the update.

    Sue

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply