Exploring the PowerShell DSC xPendingReboot Resource

While building a DSC Demo for the new job this week I got the chance to explore using many of the “new” Resources that have been released.  One of those Resources is the xPendingReboot which I am going to talk about here, because the documentation wasn’t very clear (to me anyways after having been away from DSC for a long time) on how to use it properly.

The TechNet article on the Resource and an article by the Scripting Guy can be found at the links below.

https://gallery.technet.microsoft.com/scriptcenter/xPendingReboot-PowerShell-b269f154

http://blogs.technet.com/b/heyscriptingguy/archive/2014/10/15/use-powershell-dsc-to-check-pending-reboot.aspx

If you just look at it, you would assume you could do something like this to check for a reboot:

However, you would be wrong! If we create the .MOF file for this Configuration and run this against the local system (which has a reboot pending after a computer rename), the system doesn’t actually reboot itself, it just notifies you that a reboot is pending.

Well, that’s great and all but it didn’t reboot the machine like I needed it to. Looking at those examples, maybe I need to add the LocalConfigurationManager piece to make this work?

When you build this Configuration you will immediately notice you get a localhost.mof as well as a localhost.meta.mof . The Meta.mof is a result of making a change to the Local Configuration Manager (LCM) and should be a hint that something needs to be done with it :). The TechNet article uses a RebootNodeifNeeded = ‘True’ instead of the Boolean $True, which is not correct. If you try to build the Configuration using ‘True’ you get this error:

I am going to ignore the localhost.meta.mof file for now and just try this again to see what happens. And the exact same thing happens. If you are wondering if moving the LocalConfigurationManager section ahead of the xPendingReboot section matters or will help, it won’t. You actually need to change the LCM setting on the computer before starting the Configuration, because right now it is set to this. Notice the RebootNodeIfNeeded section at the bottom:

You do that by using this command:

Now when we start the Configuration, we get the exact same result as above, plus an automatic reboot!
PendingReboot






If you want everything in one file, you can find it here.

Moving SCOM 2012 R2 Data Warehouse Database to New SQL Server Cluster

This is the second of two posts in regards to moving Operations Manager 2012 R2 Databases.  The first post about moving the OperationsManager database can be found here.  I won’t rehash any of that information but will instead just get right into the How To portion.  The TechNet article for moving the SCOM DataWarehouse Database can be found here.

  1. Stop the following services on OPSMGR01 and change their type to Manual.  Otherwise they will restart and cause you problems.
    1. System Center Data Access
    2. System Center Management Configuration
  2. Stop the following services on OPSMGR02 and change their type to Manual.  Otherwise they will restart and cause you problems.
    1. System Center Data Access
    2. System Center Management Configuration
  3. On OLDSQLServer, use SQL Server Management Studio to create a full backup of the data warehouse database. The default name is OperationsManagerDW. We recommend that you also back up the associated master database.
    1. Copy backup file to \\SQLCLUSTERNODE1\SHARE
  4. Open SQL Management Studio on SQLCLUSTERNODE1 and connect to SQLCLUSTER\SCOMDW Instance
    1. Restore OperationsManagerDW Database using SQL
  5. Backup registry on OPSMGR01
  6. Backup registry on OPSMGR02
  7. Update Registry on OPSMGR01
    1. Regedit
    2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup
    3. For each of the following keys, double-click the name, change the value to the hostname of the SQL Server-based computer now hosting the operational database, and then click OK to save your changes.
      1. DatabaseWarehouseDBServerName: SQLCLUSTER\SCOMDW
      2. DatabaseName: OperationsManagerDW
  8. Update Registry on OPSMGR02
    1. Regedit
    2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup
    3. For each of the following keys, double-click the name, change the value to the hostname of the SQL Server-based computer now hosting the operational database, and then click OK to save your changes.
      1. DatabaseWarehouseDBServerName: SQLCLUSTER\SCOMDW
      2. DatabaseName: OperationsManagerDW
  9. Login to the server you are using for reporting off of the SCOM Data Warehouse
    1. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center Operations Manager\3.0\Reporting,\ DWDBInstance double-click the name and change the value to the hostname of the SQL Server-based computer now hosting the operations manager DW database, and then click OK to save your change.
      1. In my case that would be SQLCLUSTER\SCOMDW
    1. Start the System Center Data Access Service on OPSMGR01 associated with the reporting server. This is needed to access the reports page
    2. On reporting server, change the connection strings.
      1. Open a browser and go to the reporting webpage
      2. Click Show Details and then click Data Warehouse Main. Change the Connection String to contain the new data warehouse server name, and then click Apply. SQLCLUSTER\SCOMDW.
      3. Test the connection
      4. Click Application monitoring, and then click .NET monitoring.
      5. Click AppMonitoringSource.
      6. On the AppMonitoringSource page, click Properties and change Connection string to contain SQLCLUSTER\SCOMDW, and then click Apply.
      7. Test the connection
      8. Close the browser.
    3. On SQLCLUSTERNODE1 update the OperationsManager database table. (Note that this is NOT the DataWarehouse instance!)
      1. Open SQL Server Management Studio. SQLCLUSTER\SCOM
      2. Expand Databases, OperationsManager, and Tables.
      3. Right-click dbo.MT_Microsoft$SystemCenter$DataWarehouse, and then click Edit Top 200 Rows.
      4. Change the value in the MainDatabaseServerName_2C77AA48_DB0A_5D69_F8FF_20E48F3AED0F column to SQLCLUSTER\SCOMDW
    4. Update the OperationsManager database for Application Performance Monitoring functionality.
      1. Right-click dbo.MT_Microsoft$SystemCenter$DataWarehouse$AppMonitoring, and then click Edit Top 200 Rows.
      2. Change the value in the MainDatabaseServerName_5C00C79B_6B71_6EEE_4ADE_80C11F84527A column to SQLCLUSTER\SCOMDW
      3. Do the same for the following tables.
      4. Right-click dbo. MT_Microsoft$SystemCenter$DataWarehouse$AppMonitoring_Log and then click Edit Top 200 Rows. Change the value of column Post_MainDatabaseServerName_5C00C79B_6B71_6EEE_4ADE_80C11F84527A to SQLCLUSTER\SCOMDW
      5. Right-click dbo.MT_Microsoft$SystemCenter$DataWarehouse_Log and then click Edit Top 200 Rows. Change the value of column.Pre_MainDatabaseServerName_2C77AA48_DB0A_5D69_F8FF_20E48F3AED0F TO SQLCLUSTER\SCOMDW.
      6. Close SQL Server Management Studio.
    5. On SQLCLUSTERNODE1, update the member database.
      1. Open SQL Server Management Studio and connect to SQLCLUSTER\SCOMDW instance.
      2. Expand Databases, OperationsManagerDW, and Tables.
      3. Right-click dbo.MemberDatabase, and then click Edit Top 200 Rows.
      4. Change the value in the ServerName column to reflect the name of the new SQL Server, SQLCLUSTER\SCOMDW
      5. Close SQL Server Management Studio.
    6. Update security credentials on SQLCLUSTER\SCOMDW
      1. All of my security credentials carried over and I had no issues.  However, your environment may be completely different.  Definitely make sure to read this section in the TechNet documentation
    7. Stop SQL Services relating to SCOM on OLDSQLServer
    8. Open PowerShell.  Type Write-Host “Bye Kitty” to sacrifice a kitten
    9. Restart OPSMGR01 and OSPMGR02 (this was to ensure registry setting changes were picked up)
    10. Start the following services on OPSMGR01 and change their startup type to Automatic
      1. System Center Data Access
      2. System Center Management Configuration
    11. Start the following services on OPSMGR02 and change their startup type to Automatic
      1. System Center Data Access
      2. System Center Management Configuration
    12. Spam refresh OperationsManager event log on OPSMGR01.  Hopefully you see lots of informational messages and no errors about connections to the SQL Server.

To verify a successful move of the Operations Manager Data Warehouse Database:

  1. Verify that you can successfully run a report from the console.
  2. Ensure that the health state of all management servers in the management group are Healthy.
  3. If the health state of any management server is Critical, open Health Explorer, expand Availability – <server name>, and then continue to expand until you can navigate to Data Warehouse SQL RS Deployed Management Pack List Request State. Check the associated events to determine if there is an issue accessing the data warehouse database.
  4. Check operating system events:
    1. Open the operating system’s Event viewer. Navigate to Event Viewer, and then to Operations Manager.
    2. In the Operations Manager pane, search for events with a Source of Health Service Module and a Category of Data Warehouse.
  1. The move was successful if event number 31570, 31558, or 31554 exists.
  2. There is an issue accessing the data warehouse database if event numbers 31563, 31551, 31569, or 31552 exists.
  3. Check events in Operations Manager:
    1. In the Operations console, select Monitoring.
    2. Navigate to Monitoring, Operations Manager, Health Service Module Events, and then to Performance Data Source Module Events.
    3. Search the Performance Data Source Module Events pane for events with a Date and Time that is later than the move.

 

Moving SCOM 2012 R2 Database to New SQL Server Cluster

When our System Center environment (VMM, Orchestrator, SCOM, DPM) was originally setup all the databases were installed on a single SQL Server VM (but in separate instances).  For a variety of reasons I made the decision that our System Center databases needed to at least be in a cluster configuration.  Luckily I stumbled across this excellent guide by MVP Paul Keely about configuring a SQL 2012 Cluster with Always On to be used for System Center databases.  I am not going to cover any of that here, this post is just going to be about how to move the Operations Manager database once the new cluster is built.

First, I need to go on a rant about just plain poor timing on my part.  If you don’t care to read it, skip to the next paragraph.  There is an article published by Microsoft that talks about how to move the Operational Database.  If you look at that article you will notice that it was last updated on January 19th.  That’s awesome.  You know what’s not awesome?  I first attempted to move the Operational Database on January 17th.  It failed miserably.  Why?  Because the article I was working off of didn’t include a second registry key that needed to be modified.  That’s 6 hours of my  life I will never get back.

In my environment I have two Operations Manager Management servers, in this article they are named OPSMGR01 and OPSMGR02.  When I wrote up my plan for this move I duplicated some sections that needed to be done on both servers and I kept that the same in this article.  For the SQL Server name, I used the name of the new SQL Cluster as SQLCLUSTER followed by the instance name.  If you are moving the databases to a single server you would just use the server name followed by the instance name.

  1. Stop the following services on OPSMGR01 and change their type to Manual.  Otherwise they will restart and cause you problems.
    1. System Center Data Access
    2. System Center Management Configuration
  2. Stop the following services on OPSMGR02 and change their type to Manual.  Otherwise they will restart and cause you problems.
    1. System Center Data Access
    2. System Center Management Configuration
  3. Create full backup of OperationsManager Database on OLDSQLServer using SQL
    1. Copy backup file to \\SQLCLUSTERNODE1\SHARE
  4. Open SQL Management Studio on SQLCLUSTERNODE1 and connect to SQLCLUSTER\SCOM Instance
    1. Restore OperationsManager Database using SQL
  5. Delete backup file from \\SOMEFILESHARE (Needed the space for the massive SCOM Data Warehouse Database backup that was coming next)
  6. Backup Registry on OPSMGR01
  7. Backup Registry on OPSMGR02
  8. Update Registry on OPSMGR01
    1. Regedit
    2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup
    3. For each of the following keys, double-click the name, change the value to the hostname of the SQL Server-based computer now hosting the operational database, and then click OK to save your changes.
      1. DatabaseName: SQLCLUSTER\SCOM
      2. DatabaseServerName: OperationsManager
    4. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\Database and repeat step 3. (This was the aforementioned missing step)
  9. Update Registry on OPSMGR02
    1. Regedit
    2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup
    3. For each of the following keys, double-click the name, change the value to the hostname of the SQL Server-based computer now hosting the operational database, and then click OK to save your changes.
      1. DatabaseName: SQLCLUSTER\SCOM
      2. DatabaseServerName: OperationsManager
    4. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\Database and repeat step 3.
  10. Edit the following file on OPSMGR01
    1. Browse to %ProgramFiles%\System Center 2012\Operations Manager\Server\ConfigService.config
    2. Backup existing file (copy and rename to .old and place somewhere safe)
    3. Open Notepad as Administrator and open the file in Step 1.
    4. In the <Category> tags named “Cmdb” and “ConfigStore”, change the value for ServerName to the name of the new SQL server.
    5. SQLCLUSTER\SCOM
    6. Save changes and close
  11. Edit the following file on OPSMGR02
    1. Browse to %ProgramFiles%\System Center 2012\Operations Manager\Server\ConfigService.config
    2. Backup existing file (copy and rename to .old and place somewhere safe)
    3. Open Notepad as Administrator and open the file in Step 1.
    4. In the <Category> tags named “Cmdb” and “ConfigStore”, change the value for ServerName to the name of the new SQL server.
    5. SQLCLUSTER\SCOM
    6. Save changes and close
  12. Update the operational database with the new database server name on SQLCLUSTERNODE1
    1. Open SQL Server Management Studio. Connect to SQLCLUSTER\SCOM instance.
    2. Expand Databases, OperationsManager, and Tables.
    3. Right-click dbo.MT_Microsoft$SystemCenter$ManagementGroup, and then click Edit Top 200 Rows.
    4. Change the value in the SQLServerName_6B1D1BE8_EBB4_B425_08DC_2385C5930B04 column to SQLCLUSTER\SCOM
      1. The GUID part in your database isn’t going to match the one above.  It’s ok!
    5. Save the change.
  13. On SQLCLUSTERNODE1, update the operational database with the new database server name to specify the location of the Application Performance Monitoring tables
    1. Open SQL Server Management Studio. Connect to SQLCLUSTER\SCOM instance
    2. Expand Databases, OperationsManager, and Tables.
    3. Right-click dbo.MT_Microsoft$SystemCenter$OpsMgrDB$AppMonitoring, and then click Edit Top 200 Rows.
    4. Change the value in the MainDatabaseServerName_5C00C79B_6B71_6EEE_4ADE_80C11F84527A column to SC-SQLCLUS-SCOM\SCOM
      1. The GUID part in your database isn’t going to match the one above.  It’s ok!
    5. Save the change.
  14. Update security credentials on SQLCLUSTER\SCOM
    1. All of my security credentials carried over and I had no issues.  However, your environment may be completely different.  Definitely make sure to read this section in the TechNet documentation
  15. Execute these SQL commands on new OperationsManager database instance:
    1. sp_configure ‘show advanced options’,1
    2. reconfigure
    3. sp_configure ‘clr enabled’,1
    4. reconfigure
  16. Run the following SQL query (If you added the OperationsManager database to AlwaysOn before this step you can skip this step. I ran through all of this and added it to AlwaysOn once I knew for sure it was working on the new SQLCLUSTER):
    1. SELECT is_broker_enabled FROM sys.databases WHERE name=’OperationsManager’
      1. If the result of this query was an is_broker_enabled value of 1, skip this step. Otherwise, run the following SQL queries:
    2. ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
    3. ALTER DATABASE OperationsManager SET ENABLE_BROKER
    4. ALTER DATABASE OperationsManager SET MULTI_USER
  17. Stop SQL Services relating to SCOM on OLDSQLServer
  18. Open PowerShell.  Type Write-Host “Bye Kitty” to sacrifice a kitten
  19. Restart OPSMGR01 and OSPMGR02 (this was to ensure registry setting changes were picked up)
  20. Start the following services on OPSMGR01 and change their startup type to Automatic
    1. System Center Data Access
    2. System Center Management Configuration
  21. Start the following services on OPSMGR02 and change their startup type to Automatic
    1. System Center Data Access
    2. System Center Management Configuration
  22. Spam refresh OperationsManager event log on OPSMGR01.  Hopefully you see lots of informational messages and no errors about connections to the SQL Server.
  23. Start OperationsManager console.  Check stuff

That’s it!

2015 PowerShell Resolutions

I am stealing this idea from Boe Prox. He blogged about his own PowerShell Resolutions for 2015.

I will keep this short and sweet. In no particular order here are my PowerShell Resolutions for 2015:

  1. Figure out a PowerShell related topic to speak about that I won’t get bored with in a month or two
  2. Speak about this topic at the Omaha PowerShell User Group
  3. Speak about this topic at 2-3 other PowerShell User Groups or other organizations (local or otherwise)
  4. Start and Finish PowerShell Deep Dives Book
  5. Start and Finish Windows PowerShell Best Practices Book
  6. Implement PowerShell DSC in Production at my current place of employment
  7. Deploy Private Cloud (WAP, Azure, DSC etc) in Production at my current place of employment
  8. Write at minimum one blog post a week
  9. Schedule one hour a week on my calendar to browse PowerShell.org and TechNet forums looking for PowerShell related questions to answer
  10. Learn how to do more things in SCOM and VMM using PowerShell instead of clicking around in the GUI

That’s probably a little on the ambitious side, but we will see how it goes!  What are your PowerShell Resolutions for 2015?

Creation of the VMM Resource Group Failed

While trying to install VMM as a Highly Available following the steps in this article, I kept running into the same issue over and over and over again.  The installation would start, run for a few minutes, and then fail and rollback with this error at the end:  “Creation of the VMM resource group VMM failed.Ensure that the group name is valid, and cluster resource or group with the same name does not exist, and the group name is not used in the network.”

I first thought it was because I had pre-configured the DNS entry, but even after removing the DNS entry and verifying that neither cluster node could resolve it anymore the installation still failed.  Next I rebooted both nodes of the cluster.  The installation still failed.  My next thought is maybe I can’t use VMM as the HA VMM name so I used XXXVMM and sure enough it worked.  Now, whether or not that is because I had the VMM DNS entry created previously and it screwed something up, or because you really can’t use the VMM name, I don’t know.

At this point it said setup completed successfully, but with warnings.

 

Starting the clustered VMM service XXXVMM failed.Ensure that the user has permission, the VMM service is installed properly, and cluster resources can be brought online.A service connection point (SCP) could not be registered in Active Directory Domain Services (AD DS) for the VMM management server.Run “D:\Program Files\Microsoft System Center 2012 R2\Virtual Machine Manager\setup\ConfigureSCPTool.exe -install XXXVMM.nfm.com XXX\XXXVMM$” in a command window and then check AD DS. If an SCP is not registered, VMM consoles on other computers will not be able to connect to this VMM management server and deploying a Hyper-V host to a bare-metal computer will not work.

I ran the setup as a domain administrator, and am logged into the cluster node as this same domain administrator.

Looking at the Cluster event logs, this is the error I get when I try to manually bring the service online:

Failed to bring the resource VMM Service XXXVMM online.  Error code 0x80071736 The Resource failed to come online due to the failure of one or more resource providers.

Looking at Services, the System Center Virtual Machine Manager Agent service is running, but the System Center Virtual Machine Manager service is not running, and if I try to start it, it fails with the error.

In the Event Log, I find this error entry which seems pretty useful.

Cluster network name resource ‘XXXVMM’ failed to create its associated computer object in domain ‘nfm.com’ during: Resource online.

The text for the associated error code is: A constraint violation occurred.

Please work with your domain administrator to ensure that:

– The cluster identity ‘VMM-HV-CLUS01$’ has Create Computer Objects permissions. By default all computer objects are created in the same container as the cluster identity ‘VMM-HV-CLUS01$’.

– The quota for computer objects has not been reached.

– If there is an existing computer object, verify the Cluster Identity ‘VMM-HV-CLUS01$’ has ‘Full Control’ permission to that computer object using the Active Directory Users and Computers tool.

While looking in AD for this object, I also stumbled across a VMM computer object (who the hell knows where that come from) so I deleted that object as well.  I am nearly 100% certain that is what caused my installation using VMM as my VMM Cluster Name to fail.

At the very bottom of this article it outlines how to troubleshoot issues with Cluster AD Accounts.  The instructions are only slightly different for Server 2012, and it tells you how to grant only the permissions that you need.

With that done, I removed the VMM installation and tried it again, with the original VMM Cluster name (just VMM) and it worked fine, with no errors!

 

 

 

 

PowerShell DSC Journey – Day 23

No intro. Going right back into trying to add a Network Adapter and a VMNetwork to that adapter. I look first at the hardware profile, and lo and behold I have 9 legacy network adapters, which is interesting because yesterday I had none. So, I remove them all first.

Ok, first things first, let’s make sure I can get the network I want, which I can do using this command:

The next thing I can do is try to create a new network adapter on the Hardware Profile, which I can do using this command.

However, this creates a Legacy network adapter. After reading the help file I determine that I need the -Synthetic parameter in order to make it a non-legacy network adapter.

So, that’s all working now. Next step is to see if I can actually set the Virtual Network on the adapter itself, which is where I failed so hard yesterday. This works.

So, let’s try this next. And it works. I swear I did this a billion times but I am not even to go back and look because it might make me angry or depressed. Or both.

So, let’s run my Configuration and see what happens again. And it works. Of course it does.

I then add most of the same code to the section of Set-TargetResource for when a Hardware Profile doesn’t exist. Now let me delete my profile and try it. And of course I get some errors because I am using the $ResourceHWProfile variable in this section of code instead of just $Name. So, I change it to this.

And that works as well. One interesting thing to note. There is a lot of Write-Verbose commands I have that aren’t being written after this section of code. And I have no idea why either.

Well, that’s working now so I am happy. Now that I have a functioning Resource that does what I wanted it to do, this will be the last post in the series 🙂

PowerShell DSC Journey – Day 22

Alright, after my little fiasco yesterday I need to do a little re-configuring of my Configuration because of course DSC will not allow a Plain text password.

Here is the new version of the Configuration.

Now, let’s try to run this and see what breaks. And. Nothing breaks. I am literally speechless. Seriously.

Well. Here goes nothing. And I forgot to change something back in .psm1 file when I was messing around with it yesterday that caused this entire thing to blow up. I will spare you all the red text but here is the error.

With that fixed I try to run it, and I don’t get any errors, but clearly I have something to fix with my Test-TargetResource function because it just skipped running Set-TargetResource.

So, let’s see if we can figure out what’s going on. I am pretty sure this section is the problem.

I set the $result to $false, then tested for the $VMMServer, and returned $True, so DSC was like “oh hey, everything is gravy.” Fail on my part. Let’s fix this. I already know if the Credential or VMMServer is invalid that it will fail, so I just need to check to make sure $ResourceVMMServer exists and then do the rest of my checks. I am pretty sure this is going to fail for a couple of reasons, but I am going to test this anyways in the interest of full disclosure :).

I run several of my tests that I expect to return both $True and $False. I made a few changes and added one line, so here is the new and improved section of my code.

So, let’s try this again! HOLY BUCKETS IT WORKED! Minus, one small issue.

dsc62

Now, the one issue there is that no VMNetwork was set. Probably because there is no network adapter, which I am guessing I forgot to include in my Set-TargetResource. Let’s take a look.

Yeah, that’s not going to work. I need to create the adapter first. Turns out it’s easier than I thought it would be. Just kidding, I can’t use the parameter for $VMNetwork, it needs to be a different type.

Which opens a whole new can of worms because I need to check to make sure that is a valid VM Network somewhere. For the purposes of this, I am going to assume that if it should be present, it is a valid name. Actually I lied. We aren’t going to do that, because that opens up a giant mess when it comes to creating a new Virtual Network.

After banging away on this for about the last 30 minutes I am going to stop here for the day and pick it up again tomorrow. I am currently stuck on getting the right object type from Get-SCVMNetwork to pass to……..oh hell…wait a minute. Just kidding! Kidding again. I have a moment of genius! And this is also where I hate Virtual Machine Manager anymore. Only thing good to say is that I learned a hell of a lot more than I ever wanted to know about VMM cmdlets this afternoon.

So, let me delete the Hardware Profile and run my Configuration again. The network adapter didn’t get created. My brain is exhausted. I’m done for today. For real this time.

PowerShell DSC Journey – Day 21

Alright, when I left off I had added in some testing for the $Credential Property of the Resource in the Get-TargetResource and Test-TargetResource functions. Today I am going to do the same with Set-TargetResource, and then test my Configuration to see what I did wrong. If I survive that I will try to create a Hardware Profile with my Resource.

First things first, I add this same section to Set-TargetResource.

I think that is all I need to do here because Get-SCHardwareProfile and Set-SCHardwareProfile don’t require a credential.

I run my first test, and everything works great except the test removed the DVD Drive. Which it wasn’t supposed to do. And there is all some verbage for the CPU Count that is incorrect, and it looks like I need to add a case for when CPUCount is not specified.

Ok, let’s tackle the DVD Drive issue first. I didn’t specify an option for it, it was already present, and the profile was set to Ensure = Present, so it should not have been removed. Here is the code block.

What is happening is I am not specifying a value for the DVDDrive Property. So as far as it is concerned, the last Else statement gets executed. I am going to need to add a case for not specifying the DVDDrive Property. I reconfigured this code to look like this instead.

And that works exactly like it should. Now I need to do the same thing for CPUCount. This also works just fine. And it’s also at this point that I realize that I already have the VMNetwork parameter setup that way. Apparently it never occurred to me I would need to do the same thing for the others. Oh well. Moving along! I run a few more test and make a few more minor changes and tweaks but I am not going to bore you with those details. I just needed to update the part of the function that creates a new Hardware Profile with the same If checks as above.

And now. Let’s see how badly I have failed here. Let’s test this bad boy.

Pretty good. So far. I don’t expect this to continue.

Well. That was unexpected. I guess on to the next thing. Let’s try my Configuration again. Here is my current Configuration.

}

}

Alright. So….I declared my credential variable to be of the type [pscredential]. Maybe it needs to be [MSFT_Credential]? Let’s try it. But wait, I have the bright idea that I should check to see how the ADDomain resource handles it, and I find my answer in the .psm1 file for the resource.

Looks like I need to update my Resource.

Hmmm. How else would you get the schema.mof to show that Type? Then I look at the schema.mof for my resource and get my answer.

So the type Credential, automatically changes to that in the schema. Good to know. Now I try my Resource using [MSFT_Credential]$Credential and that fails.

This has me stumped. Nothing of use in the DSC Event Logs. Comparing my .psm1 file to the ADDomain.psm1 file, I notice that all of their credentials are of the type [PSCredential] while mine is of the type [System.Management.Automation.PSCredential]. Which is weird (I think?). I try to change the parameter in my Configuration to the type [System.Management.Automation.PSCredential] but I get the same error. So I am going to change the .psm1 type to just [pscredential] and see what happens. I reloaded everything and change the type for Credential back to [PSCredential] and the same thing still happens.

I am stumped. Going to call it a day on that front.

Edit: Thanks to Jason Hofferle for helping figure out what I was doing wrong (and it was something dumb). I was so wrapped up in the thought that I did something wrong in my Resource that I didn’t bother to specify the Credential property in my actual Configuration.

PowerShell DSC Journey – Day 20

When I left off yesterday I was trying to actually run a Configuration to create a Hardware Profile, and quickly realized that I was going to need a Credential parameter in order to do this, because not just anyone can connect to a Virtual Machine Manager server. So today’s post is going to be about adding a Credential property to my Configuration.

I am going to be referencing the Active Directory resource for this because I know that uses a credential parameter to authenticate to Active Directory. First thing first, let’s create a new DSC Resource Property.

Then I will need to update my resource with this new Property.

And here is what my schema.mof file looks like:

And this is a snippet of the Get-TargetResource function show the additional property as well.

Now, that’s all well and good, but how do I go about testing this in Get-TargetResource? Let’s take a look at what the Active Directory resource does. It looks like it is using the Credential property when testing other properties, so I will do the same. I believe I only need to add this where other commands need to authenticate to the VMMServer, and I should probably test to make sure the credential is valid. Get-SCHardwareProfile doesn’t require a credential, only the VMMServer name, so I don’t think I need to do anything there. I did add this to the Get-TargetResource function.

And I suppose I should test this now to see what breaks. This test prompted me for the credential and completed successfully.

Just to be safe I tried the same test but added a -Credential (Get-Credential) command and everything worked fine.

Here is a test where I submitted a completely bogus credential that has no permissions to anything.

Here is what I added to my Test-TargetResource Function.

So let’s test this out. I am astounded this is actually working properly. With valid credential:

With non valid Credential:

I am running out of time today and feel like this is a great place to stop. I will move on to the Set-TargetResource function tomorrow!

PowerShell DSC Journey – Day 19

Alright, so in my last post I was able to resolve the issue with my Custom Resource not showing up under Get-DSCResource (because as usual I was doing something dumb).

Proof!

Now, let’s try and write a Configuration! Look ma, no errors!

Let’s build this out for a test.

I run this Configuration and the .MOF gets created.

When I run this configuration I immediately encounter two errors.

The first issue crossed my mind literally as I was hitting enter to start the Configuration. That is, am I going to need a credential variable to pull this off because not just anyone can connect to a VMM Server. This error came from running PowerShell as Administrator. When I run PowerShell as my elevated account (which has access) this is what happens.

I am going to try this (although if it works this not a valid solution as far as I am concerned), and this shouldn’t work but I am going to try it anyways.

And it did exactly what I thought it should do (which is nice for a change).

So, I am going to need a $Credential parameter. That sounds like a good place to start tomorrow 🙂