I found myself curious if I could get my entire lab environment to build itself from scratch in a 100% automated fashion including deploying and configuring Active Directory.
All of the cmdlets to perform these tasks already exist in PowerShell and are trivial to perform individually. But what happens if you want to combine them together? In order to do that, you have to be able to manage restarts and be able to continue your script where it left off. That turns out to be a non-trivial problem for traditional PowerShell scripts. As I was researching how I might accomplish this, I stumbled across something called "Desired State Configuration" or DSC. I've heard it talked about constantly over the last year or two and all of the major PowerShell bloggers have stated that it is the concept to learn after you've got the basics of PowerShell down. I've never had a reason to look into it though… until now.
"DSC is not just a priority at Microsoft, it is THE priority at Microsoft." That may sound like hyperbole coming from most people but remember that Jeffrey Snover is now the Technical Lead Architect for Windows Server. So even accepting he probably meant his team specifically, that's still a big deal for those working in IT as most of our time is spent with the products he is responsible for.
With that backstory out of the way, what exactly is Desired State Configuration and why should you care? Here is what I've been able to piece together so far. DSC is a mechanism for you to define how a server or servers should be configured. Notice I did not say how specifically to configure them. This is the first thing that took me a while to wrap my head around. In DSC, you never define HOW to configure a server, only WHAT you want the final product to look like. Think of DSC more as a manager than a programmer.
The way this is accomplished is Microsoft (and others) create something called "resources" which are effectively large, complex PowerShell modules that are written by professional programmers that contain all of the logic and error handling and dependency management that is almost always missing from amateur scripts. You then use a special subset syntax of PowerShell to declare what you want and PowerShell will go out and do it for you.
Why are people on Kijiji like this?
I've recently put up several items on Kijiji and in doing so received a number of interested replies. Unfortunately, many of those replies are practically unintelligible.
Why is this? At first I thought that many of them are some kind of bot or automated software that intentionally uses exceptionally poor grammar but I couldn't think a reason anyone would benefit from this since the people on the other end are already willing to provide you details and meet you. So these replies must be from actual human beings.
Is our Education system really that bad? Could it be that they are all non-native English speakers? I've been in enough countries and met enough non-native English speakers to know that it's not that. ESL writers can come across as having poor English certainly, but it's… different. You can spot the mix up of language structures or at the very least identify that some modicum of effort was put into the writing.
As a public service, I'd like to present two such replies I received from two different people and rewrite the sentences in a way that makes some better degree of sense. Names and phone numbers are changed.
What these commands do is change the following two properties (Turn off the display and Put the computer to sleep) for the currently active PowerPlan and sets them to Never.
This HOWTO is fairly specific to me but since I needed to document it anyway I figured I would share it in case in benefited others.
I have scheduled yet another Microsoft Exam for October. One of the techniques I use during studying is to take the base "Skills Measured" list from Microsoft and build a checklist around it so I can keep track of what to review next. To do this I traditionally copy and paste the list from the Microsoft exam site and painstakingly edit it to make it compatible with a commercial task tracking software I purchased called Swift To-Do List. It's mind-numbing repetitive work and I always tell myself I'm going to try and automate it but never do. Well that ends today.
Imagine this scenario. You have a SharePoint 2007/2010/2013 server in your environment along with an Exchange 2007/2010/2013 server. You have configured email-enabled lists in your SharePoint environment by leveraging an SMTP server configured on your SharePoint server along with a send connector on your Exchange server. Everything works great and people can email an address and have their content automatically added as a SharePoint list entry.
Then you migrate to Office 365 in a full cutover migration, obsoleting your Exchange on premises server. Your email to list functionality breaks. What now?
I found myself in this exact situation and had to come up with a solution. Here is what I came up with. I won't be covering every step here and instead will only consider high level requirements. If you need more specific detail, please ask in the comments.
First, if you have performed a cut over migration, you likely don't need the firewall rule you had for port 25 to your Exchange server anymore. So the first thing to do would be to modify that firewall rule and redirect traffic for it from your Exchange server to your SharePoint server.
1) Modify your existing Exchange contact that is used for email to list functionality. Change the email address from [name]@sharepoint.domain.com to [name]@domain.com where domain.com matches your primary production domain.
Next, if you are using some type of Directory Synchronization tool, perform a sync to Office 365.
Imagine for a moment you have just deployed Office 365 in your environment using a cutover migration. Everything is working well and you've now decided to grant access for your users to use Skype for Business. (I so hate that name).
It basically tells you that at some point in the past, someone deployed either Office Communications Server or Lync server in your environment and the users that aren't showing up have their msRTCSIP Active Directory attributes populated which is confusing Skype for Business. The article goes on to show you how to clear the attributes.
Now imagine you test this process and it works and solves your problem. But then you slink into your chair when you realize you may potentially have hundreds of users to update and each user has as many as 14 attributes each that need to be modified.
That's the situation I found myself in. If you've seen any other posts on this site, you already know how I solved this – PowerShell!
I figured I'd share my solution in the event anyone else is in this situation. This is very rough code designed to solve the immediate problem and as a result I'd suggest that you have some comfort with PowerShell before attempting to use this code.
Windows 10 is nearly upon and one of the features I am looking forward to is PowerShell 5. More specifically I am looking forward to the new PowerShellGet module.
This is effectively apt-get or yum for Windows and the implications for systems administrators are significant. I just finished a quick test drive of the functionality in the Windows 10 Technical preview and wanted to share my findings.
If you use Pleasant Password Server, you may have a need to request passwords from a command line or automated process. If you do, the script below should be very helpful.
It took me most of the evening to figure out how to request passwords using PowerShell and the RESTful API built into Pleasant Password Server (aka Keepass Server).
The vendor's documentation is unfortunately very lacking. Seriously, would it kill you to include some examples? At any rate, the script below uses the Invoke-WebRequest cmdlet to access the RestfulAPI.
The key thing to note here is that the only way it seems to retrieve passwords is via their GUID. Importantly, this is not the UUID that is displayed in the desktop client.
The only way I've found to identify the GUID is to access the desired password using the webclient and then press F12 in your browser to activate the debugging tools.
From there if you select the "Network" tab, you should see the GUID appended to the end of the URL for your password server site.
I needed to run a PowerShell script on a few dozen machines scattered across just as many disconnected networks. I wanted to ensure that if anyone in the future attempted to make changes to the script that it would no longer execute. This means learning how to implement PowerShell certificates. After much Googling I found that there was no good end-to-end guide on implementing certificates. After much trial and error, I have figured out how to implement PowerShell certificates in such a way that you do NOT need to purchase a commercial certificate while still being able to run the script on remote systems. I figured I would share the process in the hopes that I can save the next person the frustration I had.
Disclaimer: These steps are presented without any warranty, express or implied. As far as I have been able to determine, this process should drastically improve the security of your scripts without otherwise introducing any new security issues. However as I am still learning about certificates, I may have missed something. If you do find such a security concern, please let me know as I'd love to know what I missed!