My Profile Photo Title

Thoughts about DevOps and automation from a Windows guy

© 2024 Brandon olin | All rights reserved.

  1. Idea for VMware Provisioning with DSC

    feature image

    Here is an idea for VM Provisioning with DSC. This is how a custom DSC resource might look like in order to deploy a VM into a given vCenter. This DSC configuration would not target the VM itself but rather the vCenter server or maybe a proxy server with PowerCLI installed. >>

    concerning DSC, PowerShell, VMware
    2 min read

  2. Find Potentially Orphaned VM Snapshots

    feature image

    Here is a quick function to find potentially orphaned VMs snapshots. This basically looks for VMs with active snapshots using Get-Snapshot and compares that to a list of VMs where the disk file name matches *-*000*.vmdk. >>

    concerning PowerShell, Snapshots, VMware
    4 min read

  3. Import / Export PowerShell Credentials Module

    feature image

    Here is a handle little PS module I picked up from halr9000.com to import/export credentials to a file securely. The only person who can import and therefore decrypt the file is the user who exported it. Usage example: 

    1
2
3
4
5

    Import-Module Credentials
$creds = Get-Credential

Export-PSCredential -Credential $creds -Path 'c:\temp\creds.xml'
$newCreds = Import-PScredential -Path 'C:\Temp\creds.xml'
    >>

    concerning Credentials, PowerShell
    1 min read

  4. Creating a useful CMDB

    feature image

    This is the first post in what I intend to be a series of posts detailing the creation of a useful CMDB for your IT organization and how that CMDB can be used to assist in DevOps processes. At the end of the series, I hope to show how the CMDB can help drive automation in your IT environment by being a central hub for pushing/pulling information. First off, it is important to define what a CMDB is and why you should think about implementing one.

    What is a CMDB?

    A CMDB can mean many things to different people. Let’s start with the definition according to Wikipedia. A configuration management database (CMDB) is a repository that acts as a data warehouse for information technology (IT) organizations. Its contents are intended to hold a collection of IT assets that are commonly referred to as configuration items (CI), as well as descriptive relationships between such assets. When populated, the repository becomes a means of understanding how critical assets such as information systems are composed, what their upstream sources or dependencies are, and what their downstream targets are.

    What is a CI?

    A CI is a unique “thing” that you want to track and will be an instance of any number of defined CI types. You may have CI types for a physical server, virtual machine, switch, router, rack, database, firewall, UPS, etc. The CI types will share a handful of common attributes like ID, name, description and each type will have unique attributes relating just to it. In the case of a physical server this may be manufacturer, model, serial number, size in rack units. In the case of a VMware VM, it may be vCPUs, vRAM, type and number of VMDKs, etc.

    What is a CI relationship?

    A CI relationship defines how two or more CIs are related to each other. Documenting the relationships between CIs can assist in answering to the following questions:
    • What web server CIs are connected to a database on dbserver03?
    • What are the upstream and downstring CIs connected to appserver06?
    • How many physical servers are connected to switch10?
    • What VMs are running on this VM host?
    These relationships are critical in understanding what your IT landscape looks like and how everything fits together. They are also extremely valuable when troubleshooting a problem.

    Benefits of a CMDB

    The benefits of a fully populated and accurate CMDB are enormous. First off, it is a central place to hold all the “hard” data about your IT resources:
    • Asset Type
    • Serial Number
    • Asset Tag
    • Manufacturer
    • Model
    • Rack units
    • etc…
    But the CMDB is also a great place to hold all of your “soft” data as well and often, this is the most valuable:
    • Name
    • Service (what service does this CI provide and to who?)
    • IP address
    • FQDN
    • Location
    • Contact person (primary / alternate)
    • Status
    • Environment (Dev/Test, QA, Prod, etc)
    • Zone (DMZ, internal, private, hybrid)
    • CIs related to this one (servers connected to switch SW01A)
    • Maintenance windows
    Once at least some of this data is present in the CMDB, you can start analyzing your environment for useful information.
    • Ratio of Linux to Windows servers
    • Number of virtual machines in Chicago
    • Distribution of virtual machine resources (vCPU, vRAM, vStorage) globally
    • CI count trend over time.
    In later posts I will discuss ideas for:
    • CMDB architecture,
    • Useful CI types
    • CI relationships
    • CI discovery
    • CI configuration
    • Reporting / dashboards
    • Integrations with VMware/Puppet/Chef/DSC.
    Cheers, Brandon >>

    concerning CMDB
    3 min read