Some time ago I wrote a blog post where I explained how to change SQL Server instance collation for installed SQL server instance (see “Changing SQL collation for deployed instance without reinstall (almost)“). That post contained some scripting bits to detect installed SQL Server version and navigate to appropriate setup directory to facilitate collation change process. Recently I had a bit of time to consolidate these bits of PowerShell into one script which detects installed SQL Server version and changes directory to appropriate setup folder. Here you have it:
You can find sample PowerShell script for starting multiple process instances in K2 Developer Reference, below you can find just slightly modified version which I am normally using. I’ve only added some variables to specify desired number of instances, project and workflow name along with folio value.
You know, sometimes need of creating 10 groups using ADUC groups for quick test is enough to fire off Windows PowerShell ISE and compose PS script… Below you can find little script to create any number of AD DS group you want, thanks to its compactness it may also serve you as an example of implementing WHILE cycle in PowerShell, so I’ll just leave it here.
Sometimes while looking at somebody’s else ADDS environment you may want to know some basics about it – things such as total number of users, or in which OU this specific server is hiding. What surprises me a lot is that how frequently you can see people telling you that they don’t have right consoles here on this server (while their just in one PoSh line from all they need), or they not sure if they have permissions (which they usually do have). If you are lucky you just spend some time waiting for a person switching over to some other machine or directly to DC (yes to DC, just because ADUC console lives there 🙂 ), or in some other cases you will be dragged through multiple redirects / additions of people to the call only to end up explaining final person in that chain exact steps to be performed to get your questions answered (which you were perfectly able to do without switching servers and involving other people, in the first place).
Unless you already got it, it is more preferable and faster just to do yourself a favor of comfortably staying on the server where you working and issue Install-WindowsFeature RSAT-AD-PowerShell to solve missing tools problem in 20 seconds, and then, use PoSh to get your questions answered. Here is sample PS function, which I named similarly to CHKDSK (thing of which I have very fond memories ever since I use it to help my classmate to repair his HDD at the time of 1-2 GB hard drives and Windows 95) – ADDSCHK:
In the world where increasing number of people does not hone their “I can do this in N ways” skills (and sometimes even “I understand how it works” too), you frequently better off speaking PoSh with infrastructure directly than with those who entrusted to keep it up and running 🙂
In Windows Server 2016 you no longer have an opportunity to switch back and forth between core and GUI installation, hence you cannot do install and configure AD DS in a lazy way (using full GUI) and then convert it to core. That was something I discovered hard way long time ago – so I already have separate VHDX templates for Server 2016 core and full GUI VMs.
But it has been quite a while since I was playing with Server Core so when I starting provisioning my new Server 2016 core domain controller VMs today I realized that I need to remember quite a few commands to fully install AD DS on Server Core. I was about to create a blog post listing essential commands, but actually found very well written blog post on TechNet covering exactly that: Chad’s Quick Notes – Installing a Domain Controller with Server 2016 Core. So just sharing it here, instead of writing the same myself 🙂