Opening an Elevated Command Prompt (Windows Server)

There are many instances when you want to open an elevated (admin) command prompt in Windows Server.  Normally this is really easy: right-click on the icon and select "Run as administrator".

But what do you do when you can't right-click, you are running in "core" mode, or the GUI isn't running properly?  Well, PowerShell to the rescue...

If you can open PowerShell, type:
       Start-Process cmd -Verb RunAs

If you can't, but can open a (none-admin) command prompt, type:
       Powershell -Command "Start-Process cmd -Verb RunAs"

You may get a UAC prompt, but essentially this will open an elevated command prompt.

Note:  This has been tested in Windows Server 2008, 2012 and 2016.

Generating a File Hash

Sometimes there is a need to generate a hash for a specific file.  Maybe this is so you can assure others that the file is the original, maybe you want to compare it to a file you've downloaded, and sometimes you may need to enter a file hash into some software (e.g. Whitelisting).

There are tools you can download to do this, but handily PowerShell has a command that will do all this for you.  The command is simply "Get-FileHash":

Get-FileHash [-Path] <String[]> [-Algorithm <String>] | Format-List

Where:

• -Path is simply the path of the file for which you want to generate a hash
• -Algorithm is the specific hash you want to generate (defaults to SHA256), possible parameters for this option are:
• SHA1
• SHA256
• SHA384
• SHA512
• MACTripleDES
• MD5
• RIPEMD160

Disable McAfee Solidcore from the Command Line

If you have a locally managed installation of McAfee, or have somehow lost the McAfee Agent connection to the ePO server, it may be necessary to remove/disable the Solidcore software from a command line.  To do this:

1) Open an elevated Command Prompt
2) Type sadmin recover
3) When prompted enter the "ePO Console" password
[The default password is "solidcore" - without the quotes]
4) Type sadmin disable
5) Type sadmin status
This should return two results:
McAfee Solidifier: Enabled
McAfee Solidifier on reboot: Disabled
6) Reboot the machine, and Solidifier will now be disabled

You can then uninstall Solidcore as per normal.

For other uses of the sadmin command, type sadmin help at the command prompt.

RAID

The next time someone asks you why you aren't using RAID5, here are a list of articles detailing why RAID5 is bad, and RAID10 is the way to go.

http://www.smbitjournal.com/2012/12/the-history-of-array-splitting
http://www.smbitjournal.com/2012/11/one-big-raid-10-a-new-standard-in-server-storage
http://www.smbitjournal.com/2012/11/choosing-raid-for-hard-drives-in-2013
http://www.smbitjournal.com/2012/11/choosing-a-raid-level-by-drive-count
http://www.smbitjournal.com/2012/11/hardware-and-software-raid
http://www.smbitjournal.com/2012/08/nearly-as-good-is-not-better
http://www.smbitjournal.com/2012/07/hot-spare-or-a-hot-mess
http://www.smbitjournal.com/2012/05/when-no-redundancy-is-more-reliable
http://www.smbitjournal.com/2011/09/spotlight-on-smb-storage
http://www.zdnet.com/blog/storage/why-raid-6-stops-working-in-2019/805
http://www.zdnet.com/blog/storage/why-raid-5-stops-working-in-2009/162
http://queue.acm.org/detail.cfm?id=1670144

Remove McAfee Agent

There are times when it is impossible to remove the McAfee agent from a machine when it is in "Managed Mode". You'll attempt to, but the appropriate error message will be displayed.

To get around this issue, the agent needs to be uninstalled via the trusty Command Line:

1) Open a command prompt
2) Change directory to the McAfee Framework directory:
   a) For 32-bit systems: cd "C:\Program Files (x86)\McAfee\Common Framework"
   b) For 64-bit systems: cd "C:\Program Files\McAfee\Common Framework"
3) Execute the Following Command: frminst.exe /remove=agent 

In most instances, this uninstalls the McAfee Agent.  However, at the very least, it will place the Agent in "Unmanaged Mode", meaning it can now be uninstalled via "Control Panel" / "Programs and Features".

If all else fails, and I do mean ALL ELSE, you can follow the steps in this McAfee KB Article:
https://kc.mcafee.com/corporate/index?page=content&id=KB75902

MAC Randomisation

MAC Randomization (sic) is a feature in Windows 10 that can be activated to prevent your location being tracked using your MAC address.  This can be a useful feature, especially for the more paranoid amongst us.  However, ensure that your connection is not locked to your specific MAC address before activating this feature.

To turn on MAC Randomization:

1) Open the "Settings" app
2) Select "Network & Internet"
3) Under the WiFi section, select "Advanced Options"
4) Turn on the "Random Hardware Address" feature

That's it, you're done.

Disable Network Bridging

Sometimes a Workstation or Server has multiple network interfaces (because it's common to dual home servers right?).  Since a network bridge allows a Layer 2 connection between two or more physical network segments, allowing data to be shared across networks, this is something that should often be avoided.

One way to accomplish this is via a Firewall (built-in or an additional piece of hardware).  However, the ability to create a bridge can be disabled using Group Policy, and it is this mechanism that is detailed below.

Steps to enable/disable network bridging in Group Policy:
1) Create a new Group Policy Object (or choose the appropriate existing policy) and open for editing
2) Under the "Computer" section, navigate to: Policies / Administrative Templates / Network, and Network Connections
3) Open the "Prohibit installation and configuration of Network Bridge on your DNS domain network" setting
4) Set the policy as required:
    a) To prevent a network bridge being created, click "Enabled"
    b) To allow a network bridge to be created, click "Disabled"
5) Save the Group Policy
6) Apply the Group Policy to the relevant OU/Computer within your Active Directory structure.

Finding your WiFi Password

Assuming you have signed into your WiFi previously, and have now forgotten your password, there is a simple way to find out what it is:

1) Open a command prompt with "Admin" privileges
2) Run the following command: netsh wlan show profile
(This will list all networks you have connected to)
3) Choose the profile you want from the list, then type: netsh wlan show profile <Network SSID> key=clear

The output from this command will have all the details of your chosen WiFi connection.  The last section is titled "Security settings" and your WiFi password is shown against the "Key Content" entry.

Resetting Local SQL Accounts

If you are unable to log into SQL Server as a Domain User, and any local account (such as "sa") is disabled, you can follow the procedure below to log in using a local administrator (any account which is a member of the "Local Administrators" group), and perform a number of tasks.

1) Stop the SQL Server and SQL Server Agent services
2) Disable SQL Agent service
3) Run the following command to start SQL server in 'Single User Mode': sc start MSSQLSERVER -m
(Where MSSQLSERVER is the name of the SQL service)
4) From a command prompt, start a SQLCMD: SQLCMD -s (local)
5) Run the appropriate command for the task you are trying to achieve.  For example:
    a) To create a new local SQL administrator account:
        1> CREATE LOGIN [NewAccount] WITH PASSWORD = N'[Password]',
        2>        DEFAULT_DATABASE = [master],
        3>        CHECK_EXPIRATION = OFF,
        4>        CHECK_POLICY = OFF
        5> GO
        1> ALTER SERVER ROLE [sysadmin]
        2> ADD MEMBER [NewAccount]
        3> GO

    b) To reset the password of an existing account:
        1> ALTER LOGIN [ExistingAccount] WITH PASSWORD = N'[Password]'
        2> GO

    c) To renable login for an existing account:
        1> ALTER LOGIN [ExistingAccount] ENABLE
        2> GO
6) Close the SQLCMD prompt
7) Stop the SQL Server Service
8) Enable the SQL Server Agent service
9) Start the SQL Server and SQL Server Agent services

You should now be able to log into SQL with either your new account, or the existing account that has been enabled or had its password reset.

Imaging and the McAfee Agent

When deploying machines using images, the McAfee agent will no longer communicate with the ePO Server.
This is because the GUID relating to the McAfee Agent needs to be reset.

Running SysPrep on a Windows machine will NOT reset the McAfee GUID, this should be done manually.

To accomplish this, delete the "AgentGUID" from the following location in the registry:
32-Bit:  [HKEY_LOCAL_MACHINE\SOFTWARE\Network Associates\ePolicy Orchestrator\Agent\]
64-Bit:  [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Network Associates\ePolicy Orchestrator\Agent\]

Once the registry entry has been deleted, restart the McAfee Framework Service.  The McAfee Agent should now communicate with the ePO server.

Note: If you are prepping a machine for imaging, the registry key should be deleted immediately before imaging takes place.

Converting a VMware Virtual Machine to Hyper-V

Occasionally the need arises to convert a VMware virtual machine (vmdk) to work in a Hyper-V environment (vhdx).  There are a number of third-party tools available to accomplish this task, some better than others.  However, wherever possible, I like to use tools built into an Operating System, or made directly by the same company.  Enter Microsoft Virtual Machine Converter.

This tool enables the direct conversion of a vmdk file with PowerShell, and can be downloaded from here: https://www.microsoft.com/en-us/download/details.aspx?id=42497

Download and install to the default location.  Then open a PowerShell window with elevated privilages, and run the following command:
     Import-Module 'C:\Program Files\Microsoft Virtual Machine Converter\MvmcCmdlet.psd1

This cmdlet contains a number of commands that can be used to perform various conversion tasks.  However the simplest is "ConvertTo-MvmcVirtualHardDisk".

Remaining in the elevated PowerShell window, enter the following command (obvioulsy you will need to change both the "SourceLiteralPath" (source) and "Destination" arguments:
     ConvertTo-MvmcVirtualHardDisk -SourceLiteralPath C:\TEMP\Disk1.vmdk -VhdType DynamicHardDisk -VhdFormat vhdx -destination C:\Temp\Disk1

That's it.  Wait for the command to complete, and you will have a fully functioning vhdx file you can use with your shiny new Hyper-V virtual machine.

Debugging Group Policy

Not entirely sure what is happening with the preferences you are setting in Group Policy?  You can enable Group Policy "Logging and Tracing" which should give you a better idea.

The settings can be found in Group Policy Editor, under:
Computer Configuration\Policies\Administrative Templates\System\Group Policy

Enable whichever policy settings you require

Reboot the machine and log on

Logs can be found in the following locations:
User trace %COMMONAPPDATA%\GroupPolicy\Preference\Trace\User.log
Computer trace %COMMONAPPDATA%\GroupPolicy\Preference\Trace\Computer.log
Planning trace %COMMONAPPDATA%\GroupPolicy\Preference\Trace\Planning.log

Domain Controller Replication

When setting up a domain, you really should check that all domain controllers are replicating successfully.  It is also useful to check this when troubleshooting domain related problems too, just in case a DC is out of sync.

At the command prompt, on the DC you are checking, type:
    repadmin /showrepl

That's it!
Obviously there is a bit more to this command.  For instance, to check the replication status of a different domain controller, you would use:
    repadmin /showrepl <servername> /u:<domain name>\<username> /pw:*

Mounting Windows Shares in Ubuntu

In a mixed Windows/Ubuntu environment, it is often the case the you need to mount a Windows a share from within Ubuntu.  This can be done on an ad-hoc basis, or at every log on.

Whilst it is possible to use one line to mount a share: (//servername/sharename  /media/windowsshare  cifs  username=msusername,password=mspassword,iocharset=utf8,sec=ntlm  0  0), this is not recommended, since the username and password are available for all to view.  This may not be a problem for you, but this post will take the extra steps of masking those details.

1. Install the CIFS Utilities
       sudo apt-get install cifs-utils
   
2. Create a directory where the share will be mounted.  I personally like to create this mount in my home directory, but you can create it pretty much where ever you like:
       sudo mkdir /home/<UbuntuUserName>/Server
   
3. Create a smbcredentials file:
       sudo gedit ~/.smbcredentials
   
4. Add lines for the username and password (for the destination where the share is located):
       username=<Username>
       password=<Password>
   
5. Edit the smbcredentials file to prevent changes:
       chmod 600 ~/.smbcredentials
   
6. Edit the /etc/fstab file with root privileges and add the following line:
       //<Servername>/<Sharename> /home/<UbuntuUserName>\Server cifs credentials=/home/<UbuntuUserName>/.smbcredentials,iocharset=utf8,sec=ntlm 0 0
   Don't forget to save the file!
   
7. This can then be tested by typing the following command:
       sudo mount -a
   If this correctly mounts the share, it should work the next time you log on.
   
8. Note: In the latest versions of most file managers, these mounted shares are only available read only by default.  If like me, you are used to a Windows environment, this can be a little annoying.
   However, it is much more secure.  To write to the mounted share, simply open the file manager as root (e.g. sudo pcmanfm)

Note: the following "variables" are used in the above steps:

<Username>
    Username for accessing the remote share

<Password>
    Password for accessing remote share
<UbuntuUserName>
    Local Ubuntu username

<Servername>
    Server name or IP address of the server housing the remote share

<Sharename>
    Share name on the remote server

Installing Wireless in Ubuntu

When installing Ubuntu (and it's many variants) on older hardware, it is often the case that the wireless drivers do not work without some tinkering.  There are too many different cards out there to write a set of instructions on how to install every card, therefore I will focus on the steps required to install network cards on my old Dell laptops, all running a Broadcom network cards.

The steps below show the steps required to install Broadcom drivers on Ubuntu:

1. Identify the installed hardware, by typing:
       lspci -vnn | grep Network
2. On my Dell D620, this returned the following:
       Broadcom Corporation BCM4311 802.11b/g WLAN [14e4:4311] (rev 01)
   It is the BCM4311 part we are interested in.
3. Remove the currently installed Broadcom drivers:
       sudo apt-get remove --purge bcmwl-kernel-source
4. Update the software list:
       sudo apt-get update
5. Install the correct firmware.  Since, the output in step #2 reported "BCM4311", I require the "b43" version of the firmware:
       sudo apt-get install firmware-b43-installer
6. Reboot

Upon starting the machine, a list of available wireless networks should be available.

Adding Services to Group Policies

By default, when you load up the services list in Group Policy editor, only the services running on that particular server are shown.  If you want to control services running on other machines, you need to add them.  Any service at all can be added, including ones from third party vendors.

Step 1: Export Settings

1. Log on to the machine that runs the service you require
2. Run secpol.msc
3. Create a new template
4. Within that template, navigate to "System Services" and all the services currently on that machine will be listed.
5. Edit the service(s) that you require (note: ONLY edit there services)
6. Save the template
7. Copy that file to the machine where you run the GP Editor (usually a DC)

Step 2: Import Settings

1. Load Group Policy Editor, and edit the policy that controls services you require
2. Navigate to the ‘Security’ node, right-click, choose import and select the file exported above
3. The service(s) should now appear in the policy, and can be modified just like any other service

Active Directory Basics

There are very few hard and fast rules when it comes to Active Directory (AD), the whole purpose of it is to be as flexible as possible.  However, when designing an AD structure there are a few things that you should bear in mind:

1. Keep it as simple as possible
2. Create multiple AD sites if required
3. Use multiple domain controllers and DNS servers
4. Ensure there are enough Global Catalogue servers
5. FSMO Roles
6. Restrict who can administer the structure and schema

So, what do these headings mean?  Below they are explained in a little more detail:

Keep it as simple as possible

Don't overcomplicate matters!  Keep your AD structure simple, and design it in such a way that it aids administration of the system.  Do not let "management" get involved in its structure, they nearly always want it to mimic the organisational structure of a company, and this is often the least useful way or organising things.

Design your AD structure based on the following two main uses of an Organisational Unit (OU):

• Configuring objects within an Organisational Unit
• Delegating control of objects within an Organisational Unit

In my experience, the latter is an often underutilised aspect of AD planning and design.

Create Multiple AD sites if required

Whilst attempting to not overcomplicate matters, do not sacrifice functionality for simplicity.  If a more complicated Active Directory structure is required, then by all means create one.  If your network has WAN links, then these should be separate sites.

Use multiple domain controllers and DNS servers

Whether your Domain Controllers and DNS Servers are physical or virtual, ensure that they are dedicated to their role.  Do not be tempted to use a file server as a Domain Controller for example.
Using servers that have multiple roles tend to cause problems if (or more likely when) a restore of one of the components is required.  It is possible to place DHCP and DNS on the Domain Controllers, and whilst such a set up works quite well, I would always advocate having multiple separate DNS Servers, since Active Directory depends on this service so heavily.

A further consideration for the virtual world: If you have multiple virtual Domain Controllers and DNS Servers, do NOT host them on the same physical server if this can avoided.  At the very least, spread them across multiple hosts, and if possible, place them in different locations.

Ensure there are enough Global Catalogue servers

Assuming you have multiple Domain Controllers (and why wouldn't you?), make multiple servers a Global Catalogue server.  More importantly, if you have multiple sites, ensure that there is a Global Catalogue server at EACH site, otherwise clients will have to go over the WAN link to look up information from the Global Catalogue.

FSMO Roles

As the saying goes: "In Active Directory, all domain controllers are equal, but some are more equal than others".  Domain Controllers that host "Flexible Single Master Operations" (FSMO) roles are vital to the running of Active Directory.  If you have multiple domain controllers, spread the FMSO roles out amongst them, and ensure that any domain controller that hosts a FSMO role is backed up regularly - but you were doing that already right?!

Restrict who can administer the Structure and Schema

Determining whether the whole Active Directory structure can be managed by a single person, a team of people, or deciding to break the structure down into components/areas that people manage, is the first step.  Decide who will manage what, and assign permissions that ONLY allows them to do what is required (Delegating control of objects within an Organisational Unit).

Whilst not something that appears overly common in organisations, it is possible to edit the Active Directory Schema itself (usually this is for the additional of fields).  This should absolutely be restricted to one or two people.

Flexible Single Master Operation (FSMO) Role Placement

It is not the goal of this article to explain the FSMO roles, rather just to provide information on where they should be located.

In Windows Server Active Directory, there are 5 FSMO roles which can be hosted on any Domain Controller.  Each role sits on just one DC, and theoretically you can have all five roles on one DC, or one role on five DCs, however neither of these scenarios is considered best practice.

In small organisations, where cost is an issue, it is common to find only a single domain controller.
There is nothing wrong with this, except from a redundancy point of view.  If the DC fails, there is no standby DC to take over, therefore all domain tasks stop (possibly even the ability to log on depending on how the security is configured) until the DC is recovered from a backup.  Note: In this scenario, it is imperative that the DC is backed up.

Microsoft Best Practice is to split the roles as follows:

Forest Wide Roles:
Schema Master
Domain Naming Master

Domain Wide Roles:
Relative ID (RID) Master
PDC Emulator
Infrastructure Master*

The PDC emulator and the RID master should be on the same DC, if possible.
The Schema Master and Domain Naming Master should also be on the same DC.

*Infrastructure Master

The Infrastructure Master (IM) role is an interesting one, since depending on the complexity of the set-up, it may not be needed at all. General guidance (for legacy NT 4.0 related reasons) is to place the IM role on a non-global catalog server.  However, there are two things to consider before choosing the location of this role:

1. Single Domain Forest:
   If a Forest has a single Active Directory domain, there are no phantoms.  As such, the Infrastructure Master has nothing to do, and can therefore be placed on any DC, regardless of whether or not it hosts the Global Catalog.
   
   
2. Multi-Domain Forest:
   a) If a Forest has multiple domains, but EVERY DC hosts the Global Catalog, there are no phantoms, and again the Infrastructure Master has nothing to do.
   
   b) If a Forest has multiple domains, and only SOME Of the DCs host the Global Catalog, then the Infrastructure Master MUST reside on a DC that does NOT host the Global Catalogue. 

In my experience, the vast majority of set-ups fall into category 1 or 2a, and therefore the Infrastructure Master can sit wherever you want.

If you are not sure on which DC each of the 5 FSMO roles currently reside, run the following command on any Domain Controller: NetDOM /query FSMO

Changing the Product Key on Windows Server

Occasionally, it may be necessary to change the product key on a server.  For example, if you have built the server using a development product key and now want to licence it properly with a customers licence.

Once you have licenced the server however, the option to enter a product key goes away, and there is no obvious way to get it back.  You could rebuild the server from scratch, but this seems overkill.

Alternatively:

• Open a command prompt and change working directory to system32 directory (or ensure the system32 directory is in the path)
• Type slmgr.vbs -ckms (this will remove any KMS entry)
• Type slmgr.vbs -upk (this will remove the current product key)
• Type slmgr.vbs -ipk <product key> (where <product-key> is the new product key you want to use, and is in the following format: xxxxx-xxxxx-xxxxx-xxxxx-xxxxx)
• Type slmgr.vbs -ato (for CORE servers.  This activates server, an Internet connection is required)
  Alternatively type slui which will open the usual activation GUI.

This process has been tested on Windows Server 2008, 2008 R2 and 2012 R2.

Who is logged on to the SQL Server?

This tiny script will tell you who is logged on to SQL Server, and which Database they are connected to. Simply run at an SQL Command Prompt, or within Management Studio:

SELECT DB_NAME(dbid) as DBName, 
       COUNT(dbid) as NumberOfConnections, 
       loginame as LoginName 
FROM sys.sysprocesses 
WHERE dbid > 0 
GROUP BY dbid, loginame
ORDER BY DBName