On-prem and on-cloud

Category archive


Powershell packages, repositories and GUI apps

in Powershell by

A common question which comes up around Microsoft Powershell is how to make use of the Powershell artifacts, including the following:

  1. functions
  2. snap-ins
  3. modules
  4. DSC Resources
  5. role capabilities
  6. scripts
  7. packages

In order to manage Powershell packages, the following Microsoft Powershell resource can be used as reference: https://docs.microsoft.com/en-us/powershell/module/packagemanagement/?view=powershell-6. The two cmdlets to run initially are the find-package and find-packageprovider cmdlets.

Also the Get-Help cmdlet should be run in order to download all script-related documentation for powershell packages.

Some of the most commonly used Powershell packages nuget, chocolatey and PowershellGet.

There are a lot of useful Powershell repositories in the public Internet. One good example is the Powershell Gallery. Setting up your own Powershell internal repository inside your organization is also easy (instead of setting up a full nuget server). Step-by-step instructions can be found at: https://kevinmarquette.github.io/2017-05-30-Powershell-your-first-PSScript-repository/ .

Now when it comes to putting all the above Powershell artifacts to work, from a practical point of view sometimes it is useful to create a GUI app without coding and at the same time wrap that GUI app into a standalone executable (.exe file) which can run on any Windows system. A solution for this can come from the combined use of the following free public services:

  1. PoshGUI. Using this service you can rapidly create the GUI elements of a Powershell script and copy the GUI-related code to further be populated with GUI control events and properties logic.
  2. PS2EXE. The output code from the PoshGUI service needs to be finalized with GUI control events and properties code as well as with additional business logic code as required. Then the final .ps1 file can be converted to .exe using this Ps2EXE service. The bundled download of PS2EXE includes a usage file with instructions on how to build an .exe from an existing .ps1 file. This service comes in two flavors:
    1. With GUI support.
    2. Without GUI support (original version).

SQL Server PowerShell Overview

in Powershell/SQL by

More details at http://technet.microsoft.com/en-us/library/cc281954%28v=sql.105%29.aspx

SQL Server 2008 introduces support for Windows PowerShell. Windows PowerShell is a powerful scripting shell that lets administrators and developers automate server administration and application deployment. The Windows PowerShell language supports more complex logic than Transact-SQL scripts, giving SQL Server administrators the ability to build robust administration scripts. Windows PowerShell scripts can also be used to administer other Microsoft server products. This gives administrators a common scripting language across servers.

SQL Server provides two Windows PowerShell snap-ins that implement:

  • A SQL Server provider, which enables a simple navigation mechanism similar to file system paths. You can build paths similar to file system paths, where the drive is associated with a SQL Server management object model, and the nodes are based on the object model classes. You can then use familiar commands such as cd and dirto navigate the paths similar to the way you navigate folders in a command prompt window. You can use other commands, such as ren or del, to perform actions on the nodes in the path.
  • A set of cmdlets, which are commands used in Windows PowerShell scripts to specify a SQL Server action. The SQL Server cmdlets support actions such as running a sqlcmd script containing Transact-SQL or XQuery statements.

PowerShell Deployment Toolkit

in Powershell by

PowerShell Deployment Toolkit

Source: https://blogs.technet.com/b/privatecloud/archive/2013/02/08/deployment-introducing-powershell-deployment-toolkit.aspx
Rob Willis (MSFT)

In this post, I want to provide an overview of the “PowerShell Deployment Toolkit”, or PDT. PDT is a set of scripts and knowledge that can be used to deploy… well, probably just about anything, but the samples we provide are for deployment of System Center 2012 SP1. There’s nothing to stop someone from modifying the XML files provided with PDT to deploy something else, but that’s not to say that would be the correct way to deploy other technologies.

Of course, System Center itself provides ways to deploy software or even complete services. Software distribution has been a core capability of Configuration Manager ever since I’ve been working with it – at least 17 years – and it’s certainly true that Configuration Manager has a very sophisticated and reliable way to distribute software to vast numbers of geographically distributed devices. Virtual Machine Manager includes a capability called Service Templates that allows for complete services to be deployed, including the virtualization resources to support those services. Service Templates also allow for servicing of those services.

PDT is absolutely not intended to replace any of those capabilities. Rather, PDT is intended to help solve the chicken and egg problem – I need System Center for all of those advanced software and service deployment capabilities, but without System Center already in place how do I deploy System Center? Internally at Microsoft, with every milestone during development – CTP, Beta, RC, RTM – we rebuild the SCDemo environment to allow our field to learn the new capabilities we are delivering. PDT is the automation we use to do those rebuilds very quickly – usually in 2-4 hours. Yes, just 2-4 hours to deploy all of System Center including SQL and all prerequisites in a highly available configuration including all of the automatable post-setup integration. We want to provide you with the same efficiency.

It is going to take a whole series of posts to explain all of the capabilities of PDT, so I’ll start in this post with a simple overview and sample deployment. PDT requires that the servers that System Center will be deployed to are already running, members of an Active Directory domain, and you have administrator permissions to those servers. They can be physical or virtual, and can even be on any virtualization platform – PDT doesn’t care. They just need to be running Windows Server – and in most cases, that can be either Windows Server 2012 or Windows Server 2008 R2. The only exceptions to this are that the server for the Virtual Machine Manager Management server must be Windows Server 2012, and the server for the Service Manager SharePoint Web Parts server must be Windows Server 2008 R2. You will also need all the software to be used in the deployment – System Center components, SQL Server, and prerequisite software – downloaded and available in a specific folder structure. Getting that part right is the subject of another post.

PDT is posted to the TechNet Gallery here.

PDT consists of 5 files:

  • Installer.ps1 is the PowerShell script that you run to actually perform the deployment. It should be run from a system that is not a target system for the deployment itself – it can even be run from a workstation.
  • Workflow.xml contains all the “knowledge” of how to deploy system center – we will look in more detail at the content of this file in later posts.
  • Variable.xml is the file that you modify to define your deployment.
  • Downloader.ps1 is a utility to allow you to obtain all the software required to deploy. Using this utility will be the topic of another post.
  • VMCreator.ps1 is a utility to quickly create domain joined VMs on which to deploy. Using this utility will be the topic of another post.

The only one of these files that you should modify is Variable.xml – the sample provided in the initial PDT post in the TechNet Gallery deploys a minimal installation of System Center 2012 SP1 with a single server per component (three for Service Manager), exactly the same way that Unified Installer did for System Center 2012, but with additional roles and integration completed. Those of you brave enough to try this at this point, just edit Variable.xml replacing the “Variable” entries with appropriate values for your environment, and the “Role” entries with appropriate server names, then run Installer.ps1.  If there are roles you don’t want to deploy, just delete those entries from the “Roles” section.

Go to Top