Hyper-V Packer Gen2 machines – version 1.0.4

https://github.com/marcinbojko/hv-packer

Petya(notPetya) ransomware attack and how to (quickly) vaccinate lot’s of machines

There was a lot of nice summary articles about latest „ransomware” attack caused by Petya. Soon, researchers started to claim almost permanent vaccine for this type of worm.

https://www.bleepingcomputer.com/news/security/vaccine-not-killswitch-found-for-petya-notpetya-ransomware-outbreak/

Even patched OS won’t save you from infection as one infected machine quickly spreads the infection using other protocols like WinRM.

So, how should one on its vast server farm vaccinate hundrets of machines?

For example, like this 🙂

win_manage:
  dsc_file:    
    petya_vaccine1:
      dsc_destinationpath: C:\Windows\perfc
      dsc_type: file
      dsc_attributes: readonly
      dsc_contents: ""
    petya_vaccine2:
      dsc_destinationpath: C:\Windows\perfc.dat
      dsc_type: file
      dsc_attributes: readonly
      dsc_contents: ""
    petya_vaccine3:
      dsc_destinationpath: C:\Windows\perfc.dll
      dsc_type: file
      dsc_attributes: readonly
      dsc_contents: ""

 

Does Foreman speak SQL? It does ;)

So, the question is – how to deploy and maintain farm of Microsoft SQL Servers? With different domains, install sources, roles, features. Should we create unattended installers for every single instance?

No, we shouldn’t.

We should use Powershell DSC – https://github.com/PowerShell/xSQLServer
With Foreman/Puppet and win_manage, we have something like:

The simplest way:

instance1:
  dsc_instancename: MSSQLSERVER
  dsc_sourcepath: "\\our.server.com\ourshare"
  dsc_sourcecredential:
    user: anonymous
    password: anonymous
  dsc_setupcredential:
    user: DOMAIN\someuser
    password: somepassword

Or, more sophisticated:

instance1:
  dsc_instancename: MSSQLSERVER
  dsc_sourcepath: "\\our.server.com\ourshare"
  dsc_sourcecredential:
    user: anonymous
    password: anonymous
  dsc_setupcredential:
    user: DOMAIN\someuser
    password: somepassword
  dsc_features: SQLENGINE
  dsc_forcereboot: true
  dsc_agtsvcaccount:
    user: DOMAIN\scvaccount
    password: somepassword
  dsc_sqlsvcaccount:
    user: DOMAIN\sqlaccount
    password: somepassword
  dsc_sqlcollation: SQL_Latin1_General_CP1_CI_AS
  dsc_sqlsysadminaccounts:
    - DOMAIN\someadmin
    - DOMAIN\someotheradmin
  dsc_securitymode: SQL
  dsc_sapwd:
  user: sa
  password: paaaswordisverysecure
  dsc_sqluserdbdir: D:\MSSQL\Data
  dsc_sqluserdblogdir: E:\MSSQL\Data
  dsc_browsersvcstartuptype: Disabled

Whole install from local source takes aprox. 400 seconds (with other OS related settings) to finish.

Change local Administrator passwords. Oh … and unlock them :) On 10k+ machines :)

Administrator:
  dsc_username: Administrator
  dsc_disabled: false
  dsc_password:
    user: NT AUTHORITY\\SYSTEM
    password: P@$$w0rd

Raw, unedited The Foreman/Puppet + Win_manage.

Puppet & The Foreman & Powershell DSC – Windows Updates: Neverending story.

Nobody likes Windows Updates even Microsoft itself. But sometimes one should make sure, you have perks your system needs. But, we co do it old fashion way: check, update, reboot, repeat. Boring, and completly not in a way DevOps do.

Again, Win_manage to the rescue.

First we make sure what we want to do:

dsc_xwindowsupdateagent_schedule

first:
  dsc_dayofweek: sunday
  dsc_afterhour: 11
  dsc_usenotify: true

dsc_xwindowsupdateagent

security:
  dsc_updatenow: 'true'
  dsc_category: security
important:
  dsc_updatenow: 'true'
  dsc_category: important
optional:
  dsc_updatenow: 'true'
  dsc_category: optional

dsc_reboot

dsc_reboot:
  message: Machine requested a reboot
  when: pending

But what does it do? First, we should prepare update schedule: let’s say, we can start auto-updates on Sunday, after 11 AM (remember 11 AM = 11:00, and 11:00 PM=23:00)

Second: we want to install 3 type of updates: security, important and optional.

Third: we want to auto-reboot our machine (dsc_reboot) and notify us about pending updates count BEFORE and AFTER update patch set (dsc_usenotify: true)

So, we can switch from:

to

in a time needed to get some music 🙂

Puppet & The Foreman & Powershell DSC – The Road So Far.

During last few weeks I was able to push and heavy test puppet-dsc code in a lots of environments and setups.

We had sysprepped Windows Server 2012 R2 images (different versions, builds and setups), a lots of Windows 10 Professional Workstations (Original, 1511, 1607 builds), few Windows 8.1 Pro – really great statistic sample.

As for now:

• Windows Server 2012 and Windows 2012 R2 – fully supported
• Windows 8.1/10 (original)/10 (1511) – fully supported
• Windows Server 2016/Windows 10 (1607) – unsupported due to parsing bug in Powershell 5.1 – Work in progress
• Windows 7/8 – not tested
• Windows 2008 R2 – not tested

Implemented modules:

• Chocolatey – with features and sources support (adding, removing, modyfing)
• DSC_WindowsFeature
• DSC_WindowsOptionalFeature
• DSC_Service
• DSC_Environment
• DSC_Group
• DSC_xFirewall
• DSC_Reboot

More code is coming, but this fine set allows you to deploy and manage a lots of types of servers and workstations.

Puppet & The Foreman & Powershell DSC – your System Center in a box :)

Few weeks ago I started a little project – complete Puppet module called: win_manage.

My goal was to manage Windows based machines almost as easy as Linux servers, as little code inside as possible (you know, I am not a developer in any kind). And when I was thinking: KISS is no more possible with this project, I’ve found Puppet Powershell DSC module: https://github.com/puppetlabs/puppetlabs-dsc

Adding another resources it is just a breeze, the biggest part of work was to test almost every setting provided by Microsoft, to have working examples in day-to-day SysAdmin/DevOP job.

And yes, I know – we have plenty of things like this, sold with different price plans, different support plans and so on. But if you cannot afford pricey tools like Puppet Enterprise or System Center 2012 R2 in your environment, this little project comes to help you 🙂

First things first – why?

1. We have excellent granularity using Puppet and Foreman architecture without complicated AD GPO with filters.
2. Nested groups/copying groups helps so much in creating cloned environment
3. It doesn’t matter what provider do you use: physical, virtual, VMWare,Hyper-V, Azure – it just works.
4. With additional modules like Chocolatey and our private sources (and private CDNs) the story is completed – no more AD MSI voodoo stuff. Software deployment and maintenance just got really better.
5. One is is to deploy, second thing is to maintain and manage. Securing running services or making permanent changes in your environment is as much important as just deploy them.
6. No more ‚just another script’ approach.
7. Everyone can afford simple machine with simple YAML examples 😉

So my work in progress looks just like this:

Dashboard

Host Groups

Parameters to set

We love YAML driven configuration: setting users, rules, applications is just as easy as writing very light code:

Setting registry:

tightvncpassword:
 dsc_key: HKEY_LOCAL_MACHINE\SOFTWARE\TightVNC\Server
 dsc_valuename: Password
 dsc_valuedata: af af af af af af af af
 dsc_valuetype: binary
 tightvncpasswordcontrol:
 dsc_key: HKEY_LOCAL_MACHINE\SOFTWARE\TightVNC\Server
 dsc_valuename: ControlPassword
 dsc_valuedata: af af af af af af af af
 dsc_valuetype: binary

Adding features:

Web-Server:
 dsc_ensure: present
 dsc_name: Web-Server
 dsc_includeallsubfeature: true
 DSC-Service:
 dsc_ensure: present
 dsc_name: DSC-Service

Installing and maintaining latest version of packages:

chocolatey:
 ensure: latest
 powershell:
 ensure: latest
 doublecmd:
 ensure: latest
 conemu:
 ensure: latest

So, what to do next? I will be adding additional DSC Resources to module and hopefully will be able to make it public. Stay tuned and keep your fingers crossed 😉