Scenario

1. Protected Accounts : AD Users which are part of a Protected Group (can be nested)
2. Non Admin Users : AD Users which might have Inheritance disabled because of Manual Error or during Migration if something broke and disabled inheritance.

Running the Function :

. C:\Users\Dexter\Downloads\Get-ADUserWithInheritanceDisabled.ps1 #Mark the first dot at beginning

help Get-ADUserWithInheritanceDisabled -Full 

Specifying SamAccountName(s)

PS>Get-Content C:\temp\test.txt | Get-ADUserWithInheritanceDisabled


SamAccountname      : DexterPOSH
UserPrincipalname   : DexterPOSH@dex.com
IsAdmin             : True
InheritanceDisabled : True
ProtectedGroup1     : CN=Schema Admins,CN=Users,DC=dex,DC=com
ProtectedGroup2     : CN=Administrators,CN=Builtin,DC=dex,DC=com
ProtectedGroup3     : CN=Enterprise Admins,CN=Users,DC=dex,DC=com
ProtectedGroup4     : CN=Domain Admins,CN=Users,DC=dex,DC=com

SamAccountname      : test123
UserPrincipalname   : test123@dex.com
IsAdmin             : True
InheritanceDisabled : True
ProtectedGroup1     : CN=NestedGroup2,CN=Users,DC=dex,DC=com

WARNING:  [PROCESS] : SamAccountName : Cannot find an object with identity: 'xyz1abc' under: 'DC=dex,DC=com'..exception 
SamAccountname      : Abdul.Yanwube
UserPrincipalname   : Abdul.Yanwube@dex.com
IsAdmin             : False
InheritanceDisabled : True

Using -Filter with SearchBase and SearchScope

PS>Get-ADUserWithInheritanceDisabled -Filter * -SearchBase 'OU=ExchangeUsers,DC=Dex,DC=Com' -SearchScope Base

PS>Get-ADUserWithInheritanceDisabled -Filter * -SearchBase 'OU=ExchangeUsers,DC=Dex,DC=Com' -SearchScope OneLevel


SamAccountname      : DexterPOSH
UserPrincipalname   : DexterPOSH@dex.com
IsAdmin             : True
InheritanceDisabled : True
ProtectedGroup1     : CN=Schema Admins,CN=Users,DC=dex,DC=com
ProtectedGroup2     : CN=Administrators,CN=Builtin,DC=dex,DC=com
ProtectedGroup3     : CN=Enterprise Admins,CN=Users,DC=dex,DC=com
ProtectedGroup4     : CN=Domain Admins,CN=Users,DC=dex,DC=com

 Using -LDAPFilter with SearchBase and SearchScope

PS>Get-ADUserWithInheritanceDisabled -LDAPFilter '(&(objectCategory=person)(objectClass=user)(name=test*))' -SearchBase 'OU=ExchangeUsers,Dc=Dex,Dc=Com'


SamAccountname      : test123
UserPrincipalname   : test123@dex.com
IsAdmin             : True
InheritanceDisabled : True
ProtectedGroup1     : CN=NestedGroup2,CN=Users,DC=dex,DC

Resources : 

Technet Wiki Article on : AdminSDHolder, Protected Groups and Security Descriptor Propagator

1. Since Azure Resource Manager cmdlets doesn't support Certificate based authentication. We have to use Azure AD here. First step is to use below cmdlet to add your account using which you login to the Azure Portal.

Add-AzureAccount



2. Once authenticated , Switch to using Azure resource manager cmdlets using the below cmdlet. So that we get the AzureResourceManager Module loaded.

Switch-AzureMode-Name AzureResourceManager



3. Now you can see in the PowerShell host that the AzureResourceManager Module is loaded:

PS>Get-Module

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Manifest   0.9.1      AzureResourceManager                {Add-AlertRule, Add-AutoscaleSetting, Add-AzureAccount, Ad...

4.  Use the cmdlet Get-AzureResourceGroup to get Resource Groups and store them in a variable for later processing.

PS>$ResourceGroups = Get-AzureResourceGroup

5. Now we can filter Resource Groups which have tags property like below :
   

   PS>$ResourceGroups | where tags
   
   
   ResourceGroupName : DexterPOSHCloudService
   Location          : southeastasia
   ProvisioningState : Succeeded
   Tags              :
                       Name         Value
                       ===========  =========
   Environment  QA
                       TestKey      TestValue
   
   ResourceId        : /subscriptions/4359ee69-61ce-430c-b885-4083b2656de7/resourceGroups/DexterPOSHCloudService
   
   ResourceGroupName : dexterseg
   Location          : southeastasia
   ProvisioningState : Succeeded
   Tags              :
                       Name         Value
                       ===========  =======
   Environment  Testing
   
   ResourceId        : /subscriptions/4359ee69-61ce-430c-b885-4083b2656de7/resourceGroups/dexterseg
   

   
   Maybe those who don't have the Tags property we can throw a warning but I leave the Scripting logic for you to build upon.
6. Now out of the 2 Resource groups above one has a valid Environment Tag of value "QA" (in green) but the other one has an invalid tag value of "Testing"  (in yellow).
   Before we start validating the Values we need to check if the Tag contains the desired Environment tag, for this we can use the contains() method.
   
   But if you look closely you will find something strange with the tags property :
   

   PS>$ResourceGroups[0].tags
   
   Name                           Value
   ----                           -----
   Value                          LAB
   Name                           Environment
   Value                          TestValue
   Name                           TestKey
   

   
   Tags property is a hashtable but the keys are "Name"& "Value" literal. Not very intuitive as I thought I would be getting the Environment as one of the key for the hashtable returned, submitted a issue at the GitHub repo for this.
   Until it is fixed we can check if at all our Environment tag is present by using the ContainsValue method on the Hashtable, like below :
   

   PS>$ResourceGroups[0].tags[0].ContainsValue('Environment')
   True

   
   Now if the tag has the Environment as the value for 'Name' key then evidently the value for 'Value' key will be the one we are seeking.
   

   PS>$ResourceGroups[0].tags[0]['Name']
   Environment
   PS>$ResourceGroups[0].tags[0]['Value']
   QA

   
   Wow ! so much work am already dozing off :P
7. It appears validating the value is one of our permitted values ('Dev','QA','Prod') is relatively easy using the validateset() parameter attribute, see the below:
   

   PS>[Validateset('DEV','QA','PROD')]$testme = $ResourceGroups[0].tags[0]['Value']
   PS>[Validateset('DEV','QA','PROD')]$testme = $ResourceGroups[1].tags[0]['Value']
   The attribute cannot be added because variable testme with value LAB would no longer be valid.
   At line:1 char:1
   + [Validateset('DEV','QA','PROD')]$testme = $ResourceGroups[0].tags[0]['Value']
   + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       + CategoryInfo          : MetadataError: (:) [], ValidationMetadataException
       + FullyQualifiedErrorId : ValidateSetFailure
   

   
   When we decorate the $testme variable with the ValidateSet() attribute and perform the assignment it will throw an exception if the value is not in the set (note that the second resource group in step 5 doesn't have a valid Environment tag), which we can catch later and display a message saying that the Environment tag doesn't have a valid value.

1. Install PowerShell Plugin& Nunit Plugin. Click on Manage Jenkins> Manage Plugins > Under Available tab , search 'PowerShell' , 'Nunit' respectively and install them :
   


2. Once done come back to the Home page and click 'New Item' and create a free style project.
   


3.  Your new project should appear in the dashboard now, hover over it and click on 'Configure'. Notice that
   


4. For this post I am gonna dump a PS1 file and associated Pester tests in a directory and add a build step which runs Pester tests. One can play and integrate their Version control tools like Git, Subversion etc too with Jenkins. So Let's configure our new Project to use a Folder say E:\PowerShell_Project now. Below is a gif to show that :
   


5.  Now in the same page above scroll down to Build steps and add a simple build action to show you a possible gotcha.Note - We added the PowerShell Plugin to Jenkins to get the option to add build step using PowerShell natively.
   Let's add few test PS statments to it like :
   $env:UserName
   Get-Module Pester
   Get-Location
   
   Note - You can use $env:PSModulePath in above code (or normal PS console) snippet to see which all folders PowerShell looks for the Module disocvery.
   


6.  Click on "Build Now"forthe project to see a possible pitfall.
   


7.  Below is the console output of the above build run :
   

   Started by user anonymous
   Building in workspace E:\PowerShell_Project
   [PowerShell_Project] $ powershell.exe "& 'C:\Windows\TEMP\hudson3182214357221040941.ps1'"
   DEXCLIENT$
   
   Path                                                                           
   ----                                                                           
   E:\PowerShell_Project 
   
   
   Finished: SUCCESS
   

   Few important things to note here are  :
   • When running PowerShell code as part of a build step be informed of which User account is being used. For my case I see it using the System Account (my .machine name is DexClient)
   • Based on above check if the Module is discoverable to PowerShell, notice that the Get-Module Pester in the build step return nothing. (Pester was placed in my User's Modules folder).
   • If you are using a Custom workspace (step 4) the default location for PowerShell host that runs our code (added in build step) is set to that Folder.
   • Check out how Jenkins runs the PowerShell code specified in the build step.
     powershell.exe
      
8. Now one can definitely configure Jenkins to handle this in a better way but that would make my post lengthy. Quick fix here is to load the Pester Module explicitly with full path. For example : Import-Module 'Import-Module 'C:\Users\dexterposh\WindowsPowerShell\Modules\Pester\pester.psd1'
9. 
   
10. Once you have taken care of how to load the Module, you can add another build step for modify the existing one to run Pester tests.I modified the existing build step to look like below :Import-Module 'C:\Users\dexterposh\WindowsPowerShell\Modules\Pester\pester.psd1'
    Invoke-Pester -EnableExit -OutputFile PSTestresults.xml -OutputFormat NUnitXml
    
    Take a note of the parameters used here -OutputFile , -OutputFormat and -EnableExit switch.
    Pester is really awesome as it supports integrating with almost all CI Solutions out there.
    Read morehere
11.  As a last step , We will be adding a post-build step to consume our PSTestresults.xml by the Nunit Module. Below is the last gist showing the test run :

Resources :

Initially Overwhelmed

Troubles

MVP Open Day - Eye Opener

Inspiration Source - never runs dry

•  First you network with people who tackle real world problems and these interactions come in handy when needed.

• Second is you can get ideas/ opinion on any Script/ Project you are working on from the Community. (Most of my last year posts came out of some cool ideas from the community)
• Third, We don't do serious boring stuff at these meets. We crack jokes and share our IT stories often.

Background

• Web Role - Windows Server running IIS on top of it.
• Worker Role - Windows Server.

• ServiceDefinition.csdef  : The service definition file defines the runtime settings for your cloud service including what roles are required, endpoints, and virtual machine size. None of the data stored in this file can be changed when your role is running.
• ServiceConfiguration.cscfg : The service configuration file configures how many instances of a role are run and the values of the settings defined for a role. The data stored in this file can be changed while your role is running.

Task at hand

Steps:

1. Create a new Project in Visual Studio.
   
   
2. Select Python Azure Cloud Service template to start with (need Python Azure SDK installed).
   
   
3. After you create the Project from the template, it will ask you to select roles for your Cloud Service. I have added a Web & Worker role, this depends on your project. After that it asks you to select a Python environment, I chose a virtual environment for my Python app again this depends on your project.
   
   
   
4. Now let's add a custom setting to our Worker role. Right click the Worker role > Properties. It will open up a configuration page like below:
   
   
5. Now go to 'Settings' and click on 'Add Settings' button; go ahead and add the custom setting.
   
   
   
   Note - Adding a custom setting above will make an entry in the ServiceConfiguration.*.csfg files , see below :
   
   
6. Before moving further and showing you how to access the custom setting in your code, it is important to understand the role PowerShell plays in configuring a Role.
   
   If you notice there is a bin directory under your each Role which contains PS scripts which configure your role e.g installing webpi, windows features etc and also take notice of a ps.cmd file which invokes these PowerShell script as a startup task.
   
   
   
   Take a look at the ServiceDefinition.csdef (which contains the runtime settings for my cloud service) and notice that it creates a startup task for the role.
   
   
   
   Below is the gist showing the ps.cmd batch file which calls our PowerShell Script, you can always modify it to fit the custom requirements you have, leaving up to you to direct Verbose stream to a log file (verbose stream used later):
   
7. Now to the final piece in the puzzle , How to access the custom setting value and use it while configuring the Worker Role ?
   Well the example is already provided at the MSDN, Click here
   
   PowerShell to the rescue. Since PowerShell Script is already being used to configure a cloud service. One can put the extra few lines of code into the Script named ConfigureCloudService.ps1 to access the custom setting and make decisions or perform any action based on the value. You could also add another script and get it called from the ps.cmd of configurecloudservice.ps1 (you know how it works already).
   
   Easiest way is to load the DLL and then simply call the static method named GetConfigurationSettingValue on the RoleEnvironment Class.

Resources:

Little about PSBUG

1. Sign Up for Azure (Free Trial is available)
2. Install Azure PowerShell Module & Configure your subscription
3. Create a Virtual Net for your LAB
4. Deploy the VM
5. Connecting to VM using PSRemoting
6. Add a new Data Disk to VM
7. Install ADDS and a new domain.

Sign Up for Azure

Install Azure PowerShell Module & Configure your Subscription

3. Create a Virtual Net for your LAB

4. Deploy VM

[ADMIN] PS C:\> Get-AzureVMImage | where { $_.ImageFamily -eq “Windows Server 2012 R2 Datacenter” } | Sort-Object -Descending -
Property PublishedDate | Select-Object -First 1 -OutVariable image


ImageName            : a699494373c04fc0bc8f2bb1389d6106__Windows-Server-2012-R2-201407.01-en.us-127GB.vhd
OS                   : Windows
MediaLink            :
LogicalSizeInGB      : 128
AffinityGroup        :
Category             : Public
Location             : East Asia;Southeast Asia;North Europe;West Europe;Japan West;Central US;East US;East US 2;South
                       Central US;West US
Label                : Windows Server 2012 R2 Datacenter, July 2014
Description          : At the heart of the Microsoft Cloud OS vision, Windows Server 2012 R2 brings Microsoft's experience
                       delivering global-scale cloud services into your infrastructure. It offers enterprise-class
                       performance, flexibility for your applications and excellent economics for your datacenter and hybrid
                       cloud environment. This image includes Windows Server 2012 R2 Update.
Eula                 :
ImageFamily          : Windows Server 2012 R2 Datacenter
PublishedDate        : 7/21/2014 12:30:00 PM
IsPremium            : False
IconUri              : WindowsServer2012R2_45.png
SmallIconUri         : WindowsServer2012R2_45.png
PrivacyUri           :
RecommendedVMSize    :
PublisherName        : Microsoft Windows Server Group
OperationDescription : Get-AzureVMImage
OperationId          : b556cf7a-a4e8-c744-8471-f0ea0e3473ca
OperationStatus      : Succeeded



[ADMIN] PS C:\> $image.imagename
a699494373c04fc0bc8f2bb1389d6106__Windows-Server-2012-R2-201407.01-en.us-127GB.vhd

[ADMIN] PS C:\>  New-AzureVMConfig -Name $VMName -InstanceSize Small -ImageName $image.ImageName -DiskLabel "OS" -HostCaching R
eadOnly | Tee-Object -Variable NewVM


AvailabilitySetName               :
ConfigurationSets                 : {}
DataVirtualHardDisks              : {}
Label                             : DexDC
OSVirtualHardDisk                 : Microsoft.WindowsAzure.Commands.ServiceManagement.Model.PersistentVMModel.OSVirtualHardDis
                                    k
RoleName                          : DexDC
RoleSize                          : Small
RoleType                          : PersistentVMRole
WinRMCertificate                  :
X509Certificates                  :
NoExportPrivateKey                : False
NoRDPEndpoint                     : False
NoSSHEndpoint                     : False
DefaultWinRmCertificateThumbprint :
ProvisionGuestAgent               : True
ResourceExtensionReferences       :
DataVirtualHardDisksToBeDeleted   :

[ADMIN] PS C:\> Add-AzureProvisioningConfig -Windows -Password $password -AdminUsername $username -DisableAutomaticUpdates -VM
$newVM


AvailabilitySetName               :
ConfigurationSets                 : {DexDC, Microsoft.WindowsAzure.Commands.ServiceManagement.Model.PersistentVMModel.NetworkC
                                    onfigurationSet}
DataVirtualHardDisks              : {}
Label                             : DexDC
OSVirtualHardDisk                 : Microsoft.WindowsAzure.Commands.ServiceManagement.Model.PersistentVMModel.OSVirtualHardDis
                                    k
RoleName                          : DexDC
RoleSize                          : Small
RoleType                          : PersistentVMRole
WinRMCertificate                  :
X509Certificates                  : {}
NoExportPrivateKey                : False
NoRDPEndpoint                     : False
NoSSHEndpoint                     : False
DefaultWinRmCertificateThumbprint :
ProvisionGuestAgent               : True
ResourceExtensionReferences       : {BGInfo}
DataVirtualHardDisksToBeDeleted   :

Connecting to Azure VM using PSRemoting

Add a new data disk to VM

Install ADDS and a new domain

• Add Name to Query
• Remove Name from Query

Add Name to Query

Remove Name from Query

Get the Ground work ready

So before we start doing anything else we need a mechanism in place to authenticate to Azure against my subscription. There are two ways to achieve that (links in Resource section) :

1. Using Azure Active Directory
2. Using Certificate Based Authentication

In my opinion using Azure AD for the authentication is better and easier to explain (am gonna use that for this post) . The below steps of using Azure AD for Authentication are borrowed from the Azure blog found here.

Now Let's head to our Azure Active Directory > Default Directory > Users > Add User.

Then after this you will see a wizard to add a User, Key in the UserName:

Click Next, Be careful and do not enable Multi-Factor auth.

On next screen , Click "Create Temporary password".  Make a note of Complete Username and temporary password. We will change it in next step.

Now logout of the browser or open another web browser and navigate to https://manage.windowsazure.com/ .

Now on the Sign-in page , you have to specify the username of the User you created above (that's why we had to make a note of the Username and Password).

After this you will be asked to enter password (key in the temporary password). Log-in and you will be asked to change your password, do that.

Create the Assets

Let's look at what we are trying to do here, We are going to author a PowerShell Workflow which will deploy a VM with Server Technical Preview on Azure and then add the machine to my domain :)

But before we get ahead of ourselves we have few important questions to answer here.

1. How does my workflow authenticate to Azure to add a new VM to my Cloud service ?
2. How to set Local Admin Username and Password for the VM deployed ? (We can hardcode these). 
3. Once the VM is up how to add it to the domain using another set of Credentials ?

This is where the Assets kick in (no Cmdlets as of now ).

We will have to create 3 Credential assets (stores Username and Password) to tackle this problem at hand. Creating Assets is very straight ahead :

Navigate to Azure Automation > Your Automation Account > Assets > Click on "Add Setting" (at the bottom). After this you will be presented with a page like below :

Select "Add Credential"

Give a Name to the Asset, have kept the Asset name same as the Azure AD User name.

 In the next screen give the User name and Password of the User we added in the first step to Azure AD.

The first asset is created, Now I will similarly add 2 mores credentials asset named "DomainDexterPOSH" of a User in my Domain dex.com which has permissions to add a Machine to my domain and another set of credential called "LocalDexterPOSH" to set the local admin username and password for the New VM which our workflow will provision.

Create a RunBook to deploy the VM

Under the Automation account in Azure portal, I can create a new RunBook from Scratch (supports authoring workflows) or create a workflow locally and upload it using the Azure Automation cmdlets. The Azure Automation cmdlets are evolving at the moment , So for this post let's focus more on using the portal to author RunBooks.

Let's get familiarize with how a  runbook looks like in the Azure portal.
To create a new runbook in portal you can click "New" and give it a name (see below)

Your runbook name should be unique among your runbooks.
Once done you will see the Runbook sitting in your Azure Automation account.

Click on it and it lands you to the editing area for the Runbook. See the below screenshot :

Notice that the Workflow Name and the Runbook name has to be the same.

The Workflow editor is pretty cool, you can play with that. This is one way of authoring things up in the Web browser.

Now the Runbooks in Azure Automation are essentially PowerShell workflows and they have few differences from the workflows which we author locally (if you have done that ). The whole workflow is available at the below link: 
https://gist.github.com/DexterPOSH/e9dceb72a6f171bd3d97

Basically you copy the whole workflow and paste it in your runbook. 
Once you have your workflow authored and tested well, you can Publish it. This way you can use that Runbook inside another runbooks too.

Once the workflow is Published, you can run it by clicking on the "Start" button at the end (this only shows up after you publish it...If you want to run a workflow while authoring it then there is "Test" button see above pic):

Clicking on "Start" will prompt you to supply arguments to the parameters, like below:

After this you can view the Job

Note - The workflow is very specific to my test LAB on Azure and you will have to substitute values and tweak the workflow for your own environment.

Below is an attempt to explain what the workflow does.

the parameters our Runbook will take:

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021

workflow New-TestVM {     param(         [parameter(Mandatory)]         [String]         $AzureConnectionName,            [parameter(Mandatory)]         [String]         $ServiceName,             [parameter(Mandatory)]         [String]         $VMName,                             [parameter()]         [String]         $InstanceSize = "Medium"        )

So the Workflow named New-TestVM (Note here that the workflow name and the Runbook name should be the same) will take 4 parameters for specifying the below :

1. Subscription Name ($AzureConnectionName)
2. Cloud Service Name ($ServiceName)
3. Name of the new VM to provision ($VMname)
4. Instance size of the VM ($InstanceSize which by default is Medium)

The first step in a Runbook is to authenticate to Azure this is where we use the below code snippet :

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022

$verbosepreference = 'continue'     #Get the Credentials to authenticate agains Azure     Write-Verbose -Message "Getting the Credentials"     $Cred = Get-AutomationPSCredential -Name "AuthAzure"     $LocalCred = Get-AutomationPSCredential -Name "LocalDexterPOSH"     $DomainCred = Get-AutomationPSCredential -Name "DomainDexterPOSH"     #Add the Account to the Workflow     Write-Verbose -Message "Adding the AuthAzure Account to Authenticate"     Add-AzureAccount -Credential $Cred     #select the Subscription     Write-Verbose -Message "Selecting the $AzureConnectionName Subscription"     Select-AzureSubscription -SubscriptionName $AzureConnectionName     #Set the Storage for the Subscrption     Write-Verbose -Message "Setting the Storage Account for the Subscription"     Set-AzureSubscription -SubscriptionName $AzureConnectionName -CurrentStorageAccountName "dexterposhstorage"

In the above code snippet we retrieve all of the Assets we created then we use one of them $cred to authenticate to Azure. After that we select the Subscription against which our workflow will run (& automate stuff). One more thing as we are going to create a new VM we will need to specify the storage account as well.


Now the below code snippet will :

• Get the Image details using Get-AzureVMImage and store the ImageName property in a variable
• Then we derive the Username and Password from the LocalCred which stores one of the Credential Asset
• Finally we specify all the configurations to the cmdlet New-AzureQuickVM (e.g SubnetName, Username, Password, ImageName etc.). Note the user of -WaitForBoot switch will pass on the control to next activity once the VM is up and running.
• After this let's do a checkpoint so that if something fails in our workflow past this point, it should be able to resume from here.

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018

#Select the most recent Server 2012 R2 Image     Write-Verbose -Message  "Getting the Image details"     $imagename = Get-AzureVMImage |                      where-object -filterscript { $_.ImageFamily -eq “Windows Server Technical Preview” } |                      Sort-Object -Descending -Property PublishedDate |                      Select-Object -First 1 |                      select -ExpandProperty ImageName     #use the above Image selected to build a new VM and wait for it to Boot     $Username = $LocalCred.UserName     $Password = $LocalCred.GetNetworkCredential().Password     New-AzureQuickVM -Windows -ServiceName $ServiceName -Name $VMName -ImageName $imagename -Password $Password -AdminUsername $Username -SubnetNames "Rest_LAB" -InstanceSize $InstanceSize  -WaitForBoot     Write-Verbose -Message "The VM is created and booted up now..Doing a checkpoint"     #CheckPoint the workflow     CheckPoint-WorkFlow     Write-Verbose -Message "Reached CheckPoint"

This will take some time and after the machine is provisioned, we have another task at hand of adding the new VM to our domain. This can be achieved by opening a PSSession to the new VM and performing the action.

Below is the code which will open a PSSession to the machine using the LocalCred Asset and perform the domain join passing the DomainCred as argument to the Scriptblock:

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028

#Call the Function Connect-VM to import the Certificate and give back the WinRM uri     $WinRMURi = Get-AzureWinRMUri -ServiceName $ServiceName -Name $VMName | Select-Object -ExpandProperty AbsoluteUri     InlineScript     {         do         {             #open a PSSession to the VM             $Session = New-PSSession -ConnectionUri $Using:WinRMURi -Credential $Using:LocalCred -Name $using:VMName -SessionOption (New-PSSessionOption -SkipCACheck ) -ErrorAction SilentlyContinue             Write-Verbose -Message "Trying to open a PSSession to the VM $VMName "         } While (! $Session)           #Once the Session is opened, first step is to join the new VM to the domain         if ($Session)         {             Write-Verbose -Message "Found a Session opened to VM $using:VMname. Now will try to add it to the domain"                                            Invoke-command -Session $Session -ArgumentList $Using:DomainCred -ScriptBlock {                 param($cred)                 Add-Computer -DomainName "dex.com" -DomainCredential $cred                 Restart-Computer -Force             }         }       } } #Workflow end

Resources:

Use Azure AD to authenticate to Azure
http://azure.microsoft.com/blog/2014/08/27/azure-automation-authenticating-to-azure-using-azure-active-directory/

PowerShell + Azure Automation : Deploy a Windows 10 VM (Server Tech Preview) & domain join (Script updated in Technet too)

Initial Hurdle

Finally Singapore -> PSConfAsia

Sometimes I wonder if, It was all part of grand scheme, orchestrated by Jeffrey Snower & PowerShell team at MSFT to turn an average Windows Admin (GUI driven) to a full blown automation driven ninja.

During the conference I had a pleasure meeting all the people whom I know via Social Networks. There were so many sponsored goodies for the participants that I was wondering if I would have been one e.g. F1 Ticket, iPad mini, DSC, DevOps related books, PowerShell Studio license by Sapien and many more.


Below are few of snaps :



KeyNote by none other than Jeffrey Snower himself (via Skype)

Panel discussion revolving around DevOps, Infra as Code etc. This was fun as we got to hear from the some well known names in the IT industry.

From Left to Right - Ferninand Rios, Jaap Brasser, Ryan Yates, Ravikanth Chaganti, Narayanan (Nana) Lakshmanan and Jason Brown.

Below is a pic of how colorful the MSFT Singapore Office is :

First day Speaker's Dinner was sponsored by Kemp Technologies and we all enjoyed a lot of local delicacies.

Below Jaap making a joke about his Birthdate

Just a reference on how much awesome the place was, below is what we got in Dessert :)

Nana in background while delivering his DSC Internals session. Foreground is my machine (Using ISE  to make notes, this is how I roll :D )

Dell has a PowerShell BIOS Provider which exposes the BIOS settings as a PSDrive. Girish Prakash from Dell R&D delivered an informative session on why the implementation choose PS Providers over Cmdlets and demoed the Provider.

Later in the evening there were Drinks for everyone at a nearby cafe. Before that I went for a little stroll with Jaap and Eswar Koneti (It was mostly technical things We talked about)

Eswar and me

Jaap and Me

Hoping you get the below :

PS>"{0} > {1} > {2}" -f $Me, $Miton, $Ravi

Circling back to the Cost Factor the very first thing that came to my mind. Looking back at the experience of meeting people from PS Community and learning few things in the process, I have to say that it was all worth it.

I have started making plans already for a next conference.
Cheers

1. Context "User Creation"
     It should return Object when -Passthru specified (New addition)
     It should take OU Path from template User.
     It should only copy allowed set of attributes from the User (by default).
     It should allow copying a subset of allowed set of attributes.
     

Before writing the tests, I wanted to share one important concept while practicing TDD/BDD. 

If at any point it becomes a pain writing tests then you are probably doing it wrong. Tests should be easy to write otherwise they depict a serious flaw in the logic you have. [Lesson learned hard way]

Also, one has to remember that Unit tests only test the logic of the code. So if I wrote code to create an AD user, my unit tests shouldn't be creating a test user each time (this would clutter things up). Easier way to test the logic is to mock the key pieces which have external dependency.

But Mocking is a slippery slope, when we use mocking we are actually testing the behavior of the code rather than the state that is why this approach is also termed as "Behavior" based testing.

Setting up Context

A quick search found me below link on Technet (going to use this as reference for my function and will keep refactoring this).
https://technet.microsoft.com/en-us/library/dd378959(v=ws.10).aspx

So it is clear, New-ADUser is the cmdlet (part of the AD PowerShell module) which will be ultimately called for creating user in function.

In my above example, querying AD is an external dependency it has nothing to do with the logic for my code. So it is wise to mock those cmdlets which will have sort of external dependency.

It is obvious that in order to create a new user I would be using New-ADUser cmdlet from the AD PowerShell module, but I will have to mock it and assert that it is being called by my code. So the context for my "user creation" tests will look like below to begin with :

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016

Context "User Creation" {           BeforeEach {             # Create a Dummy AD module and import it             $DummyModule = New-Module -Name ActiveDirectory  -Function "New-ADUser","Get-ADUser" -ScriptBlock {                                                                             Function New-ADUser {"New-ADUser"} ;                                                                         }             $DummyModule| Import-Module         }         AfterEach {             # Forcefully remove the Dummy AD Module             Remove-Module -Name ActiveDirectory -Force  -ErrorAction SilentlyContinue         }       }

Before moving forward take a look at the Context block one more time. The BeforeEach{} and AfterEach{} block provide a way to setup and teardown test environment for each Unit test run (the It{} blocks).
Note - If you haven't heard about the BeforeEach {} block earlier then take pause and read Michael Sorens article on Test anatomy.

So in the BeforeEach{} block, I create a dummy module named ActiveDirectory (AD PowerShell module which is not present in my local machine) and export Get-ADUser, New-ADUser functions.

In the AfterEach{} block, the Remove-Module is called to unload the dummy module forcefully. Because of the above hack, I had to modify the Module loading part in my code(see the try block below which got changed). 

Now the code tests if the module is already loaded because the dummy module is loaded in Beforeach{} block so the function should see it and do not try to load the module again.

001 002 003 004 005 006 007

TRY {             if ( -not (Get-Module -Name ActiveDirectory) ) {                 # try to import the Module                 Import-Module -name ActiveDirectory -ErrorAction stop                 $null = Get-PSDrive -Name AD -ErrorAction stop  # Query if the AD PSdrive is loaded             }         }

The reason to use the dummy module are :

1. Pester tests don't depend on AD PowerShell module.
2. AD PowerShell module is too complicated in implementation, Read more here

Test - It should return Object when -Passthru specified (New addition)

Now let's take a look at the test.

001 002 003 004 005 006 007 008

It "Should return object when -Passthru specified" {             $TemplateUser = [PSCustomObject]@{Name='templateuser';UserPrincipalName='templateuser@dex.com'}             Mock -CommandName New-ADuser  -MockWith {@{name='testuser'}} -Verifiable             $CreatedUser = New-ADUserFromTemplate -GivenName 'test 123' -SamAccountName 'test123' -Instance $TemplateUser -Passthru             Assert-VerifiableMocks # Assert that our verifiable mock for New-ADuser cmdlet was called.             $Createduser | Should Not BeNullOrEmpty               }

Inside the Unit test, I begin by storing a custom object in $TemplateUser which will be passed to our function.
Then the New-ADUser function (Yes! it is a function loaded from my dummy AD module) is mocked to return a hashtable (it could be a custom object too). Observant eye will notice that the mock has been marked -verifiable.

Later the Assert-VerifiableMocks is called to verify that all the verifiable mocks have been invoked. Also at the end I assert that the $CreatedUser should not be empty (-Passthru should return Object).

The tests fail at this point (Red phase) because I didn't modify the code, so I change my function definition.

So my bare bone code looks like below now (removed help for this one only here in this illustration not from the actual code). People will criticize me for passing the -Name an argument same as SamAccountName but that is fine, more focus is on the testing philosophy here.

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 032 033 034 035 036 037 038 039 040 041 042 043 044 045

function New-ADUserFromTemplate {    param(         # SPecify the unique SamAccountName for the User         [Parameter(Mandatory)]                        [ValidateNotNullOrEmpty()]         [string]$SamAccountName,             # Specify the First Name or Given name for the user         [Parameter(Mandatory)]         [ValidateNotNullOrEmpty()]         [String]$GivenName,         [Parameter(Mandatory)]         #[PSTyepName('Microsoft.ActiveDirectroy.Management.ADUser')]         [Object]$Instance,         [Switch]$Passthru         )         TRY {             if ( -not (Get-Module -Name ActiveDirectory) ) {                 # try to import the Module                 Import-Module -name ActiveDirectory -ErrorAction stop                 $null = Get-PSDrive -Name AD -ErrorAction stop  # Query if the AD PSdrive is loaded             }         }         CATCH [System.IO.FileNotFoundException]{             Write-Warning -Message $_.exception             throw "AD module not found"         }         CATCH {             throw $_.exception         }                  # Let's start by following the link : https://technet.microsoft.com/en-us/library/dd378959(v=ws.10).aspx         $Instance.UserPrincipalName = $Null         if ($Passthru.IsPresent) {                New-ADuser -Name $SamAccountName -SamAccountName $SamAccountName -GivenName $GivenName -Instance $Instance -Enabled $False -Passthru         }         else {           $null =  New-ADuser -Name $SamAccountname -SamAccountName $SamAccountName -GivenName $GivenName -Instance $Instance -Enabled $False         }   }

Now if I run the test then it should pass (Green phase) this particular unit test.

Test - It should NOT return object (by default)

Notice how I have added two more tests as I get clarity on the behavior of the function.
This unit test will check the exact opposite behavior of the previous test.

001 002 003 004 005 006 007

It "Should NOT return object by default" {             $TemplateUser = [PSCustomObject]@{Name='templateuser';UserPrincipalName='templateuser@dex.com'}             Mock -CommandName New-ADuser  -MockWith {@{name='testuser'}} -Verifiable             $CreatedUser = New-ADUserFromTemplate -GivenName 'test 123' -SamAccountName 'test123' -Instance $TemplateUser             Assert-VerifiableMocks # Assert that our verifiable mock for New-ADuser cmdlet was called.             $Createduser | Should  BeNullOrEmpty         }

The key difference in this unit test is that $Createduser should be empty. 

When I run the Pester test at this point the second unit test fail, but wait in the function definition New-ADUser cmdlet is not passed -Passthru switch if it is not specified to the New-ADUserFromTemplate function.

See below excerpt from the function, it should have taken care of the test (right?)

001 002 003 004 005 006

if ($Passthru.IsPresent) {               New-ADuser -Name $SamAccountName -SamAccountName $SamAccountName -GivenName $GivenName -Instance $Instance -Enabled $False -Passthru         }         else {             New-ADuser -Name $SamAccountname -SamAccountName $SamAccountName -GivenName $GivenName -Instance $Instance -Enabled $False         }

This is the downside of using a dummy dynamic module the BeforeEach{} trick, because the code just sees a New-ADUser dummy function, it doesn't mimic the behavior of the cmdlet. This approach comes with this downside but this shouldn't be hard to fix.

If I change the above code excerpt (if else condition) like below :

001 002 003 004 005 006 007

if ($Passthru.IsPresent) {               New-ADuser -Name $SamAccountName -SamAccountName $SamAccountName -GivenName $GivenName -Instance $Instance -Enabled $False -Passthru         }         else {           $null =  New-ADuser -Name $SamAccountname -SamAccountName $SamAccountName -GivenName $GivenName -Instance $Instance -Enabled $False         }

Now all the tests are passing, below is a screenshot showing that. 

Conclusion

We are at the end of this post, few more posts will follow. Wait ! What ?

No more tests (marked in red below) as mentioned in the starting of the post for the context block !!!

Context "User Creation"
  It should take OU Path from template User.
  It should only copy allowed set of attributes from the User (by default).
  It should allow copying a subset of allowed set of attributes.

Honestly, I had all those unit tests written but later I realized that the tests are actually checking the state of the Created user rather than the behavior of the function. If you have looked carefully the object returned from my function New-ADUserFromTemplate in the current context is a mocked object ( it is in my control, what I wish to return).

So ask yourself does it make sense to run tests which check the state of a mocked object ? You can only run these tests when you get an actual AD User which was created in AD. 

To summarize these tests are testing the "State" of the Object hence we can't use mocking here. This completely changes the initial strategy I had in my mind for testing my code for good.

Please read this article by Matt Wrock as it perfectly describes the dilemma I faced while writing this post, especially the part where he talks about mocking infrastructure.

http://www.hurryupandwait.io/blog/why-tdd-for-powershell-or-why-pester-or-why-unit-test-scripting-language

If you have anything to add on to my current approach then the feedback is much appreciated.

Below is the final state my code has achieved

Full Test Suite :

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 032 033 034 035 036 037 038 039 040 041 042 043 044 045 046 047 048 049 050 051 052 053 054 055 056 057 058 059 060 061 062 063 064 065 066 067 068 069 070 071 072 073 074 075 076 077 078 079 080 081

$here = Split-Path -Parent $MyInvocation.MyCommand.Path $sut = (Split-Path -Leaf $MyInvocation.MyCommand.Path).Replace(".Tests.", ".") . "$here\$sut" #region Unit Test - Test only the logic, Mock the Shit out of Variables ! Describe "New-ADUserFromTemplate" -Tags 'UnitTest'{     Context "Help and Parameter checks" {         Set-StrictMode -Version latest            It 'should have inbuilt help along with Description and examples' {             $helpinfo = Get-Help New-ADUserFromTemplate             $helpinfo.examples | should not BeNullOrEmpty  # should have examples             $helpinfo.Details | Should not BeNullOrEmpty   # Should have Details in the Help             $helpinfo.Description | Should not BeNullOrEmpty # Should have a Descriptiong for the Function         }         It 'Should have SamAccountName, GivenName & Instance Mandatory params' {             # {New-ADuserFromTemplate} | Should Throw             {New-ADuserFromTemplate -samAccountName $null } | should throw             {New-ADuserFromTemplate -GivenName $null} | should throw             {New-ADuserFromTemplate -Instance $null } | should throw             {New-ADuserFromTemplate -GivenName $Null -SamAccountName $null -Instance $Null } | Should Throw         }     } # end Context     Context "ActiveDirectory Module Available" {         $TemplateUser = [pscustomobject]@{                                             Name='testuser'                                             UserPrincipalName='testuser@dex.com'                                             #PStypeName = 'Microsoft.ActiveDirectory.Management.ADUser'                                             }         It "Should Fail if the AD Module not present" {             Mock Get-Module -MockWith {$Null}             Mock -CommandName Import-Module -ParameterFilter {$name -eq 'ActiveDirectory'} -MockWith {Throw (New-Object -TypeName System.IO.FileNotFoundException)} -Verifiable             {New-ADUserFromTemplate -SamAccountName test123 -GivenName 'test 123' -Instance $TemplateUser } | should throw                 Assert-VerifiableMocks         }     }     Context "User Creation" {            BeforeEach {             # Create a Dummy AD module and import it             $DummyModule = New-Module -Name ActiveDirectory  -Function "New-ADUser","Get-ADUser" -ScriptBlock {                                                                             Function New-ADUser {"New-ADUser"} ;                                                                         }             $DummyModule| Import-Module         }         AfterEach {             # Forcefully remove the Dummy AD Module             Remove-Module -Name ActiveDirectory -Force  -ErrorAction SilentlyContinue         }               It "Should return object when -Passthru specified" {             $TemplateUser = [PSCustomObject]@{Name='templateuser';UserPrincipalName='templateuser@dex.com'}             Mock -CommandName New-ADuser  -MockWith {@{name='testuser'}}  -Verifiable             $CreatedUser = New-ADUserFromTemplate -GivenName 'test 123' -SamAccountName 'test123' -Instance $TemplateUser -Passthru             Assert-VerifiableMocks # Assert that our verifiable mock for New-ADuser cmdlet was called.             $Createduser | Should Not BeNullOrEmpty                }         It "Should NOT return object by default" {             $TemplateUser = [PSCustomObject]@{Name='templateuser';UserPrincipalName='templateuser@dex.com'}             Mock -CommandName New-ADuser  -MockWith {@{name='testuser'}} -Verifiable             $CreatedUser = New-ADUserFromTemplate -GivenName 'test 123' -SamAccountName 'test123' -Instance $TemplateUser             Assert-VerifiableMocks # Assert that our verifiable mock for New-ADuser cmdlet was called.             $Createduser | Should  BeNullOrEmpty         }     } #end Context } #end Describe

New-ADuserTemplate Function :

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 032 033 034 035 036 037 038 039 040 041 042 043 044 045 046 047 048 049 050 051 052 053 054 055 056 057 058 059 060 061 062

<# .Synopsis    Function which enables creating new users using a Template .DESCRIPTION    Function which will use a User as a template and then copy set of below attributes to the new user. .EXAMPLE     First get the AD user Stored in a variable with all the properties (it copies only a subset of properties on the Object supplied)     PS> $TemplateUser = Get-ADUser -identity Test1 -Properties *     PS> New-ADUserFromTemplate -SamAccountname newuser123 -GivenName NewUser -Instance $TemplateUser .EXAMPLE    If the AD User Object doesn't have all the Properties on it then the Function only selects the available ones.     PS> $TemplateUser = Get-ADUser -identity Test1     PS> New-ADUserFromTemplate -SamAccountname newuser123 -GivenName NewUser -Instance $TemplateUser #> function New-ADUserFromTemplate {    param(         # SPecify the unique SamAccountName for the User         [Parameter(Mandatory)]                       [ValidateNotNullOrEmpty()]         [string]$SamAccountName,            # Specify the First Name or Given name for the user         [Parameter(Mandatory)]         [ValidateNotNullOrEmpty()]         [String]$GivenName,         [Parameter(Mandatory)]         #[PSTyepName('Microsoft.ActiveDirectroy.Management.ADUser')]         [Object]$Instance,         [Switch]$Passthru         )         TRY {             if ( -not (Get-Module -Name ActiveDirectory) ) {                 # try to import the Module                 Import-Module -name ActiveDirectory -ErrorAction stop                 $null = Get-PSDrive -Name AD -ErrorAction stop  # Query if the AD PSdrive is loaded             }         }         CATCH [System.IO.FileNotFoundException]{             Write-Warning -Message $_.exception             throw "AD module not found"         }         CATCH {             throw $_.exception         }                 # Let's start by following the link : https://technet.microsoft.com/en-us/library/dd378959(v=ws.10).aspx         $Instance.UserPrincipalName = $Null         if ($Passthru.IsPresent) {               New-ADuser -Name $SamAccountName -SamAccountName $SamAccountName -GivenName $GivenName -Instance $Instance -Enabled $False -Passthru         }         else {           $null =  New-ADuser -Name $SamAccountname -SamAccountName $SamAccountName -GivenName $GivenName -Instance $Instance -Enabled $False         }  }

Resources:

Preivous post
http://www.dexterposh.com/2015/09/powershell-ad-pester-create-new-user.html

https://msdn.microsoft.com/en-us/library/ms679765(v=vs.85).aspx

http://www.hurryupandwait.io/blog/why-tdd-for-powershell-or-why-pester-or-why-unit-test-scripting-language

https://www.simple-talk.com/sysadmin/powershell/practical-powershell-unit-testing-getting-started/#eleventh

Read this post by Jakub where he explained about CQS principle, which I intend to follow in my future practices.
http://powershell.org/wp/2015/10/18/command-and-query-separation-in-pester-tests/

1. Switching to native WMI calls when the CM cmdlets fail for some reason (probably bug in the CM Module).
2. Making your scripts more efficient by optimizing the WMI (WQL query) calls, the cmdlet will query all the properties for an Object (select *) you can select only ones you need. 
3. Lastly no dependency on the CM Module, you can run these automation scripts from a machine not having the CM console installed (needed for CM module).

Example Problem:

PowerShell + SCCM 2012 R2 : Create an Application (from MSI) & Deploy it

This is strange.
So what you do now ? Don't worry you can at anytime fallback to using PowerShell and WMI  until the bug is fixed ( it seems to be fixed in the latest version).

1. how to start exploring the WMI Class associated.
2. Read the documentation.
3. Use PowerShell + WMI to automate it.

Get the WMI Class name:

Read the WMI Class documentation