I’ve been working on a simple PowerShell command today to import into our endpoint management solution so we can alert on disks with low diskspace. It’s been a while since I’ve dabbled with PowerShell, and it reminded me just how flexible it is and much I love it!
So I thought I would walk you through the evolution of the command I ended up with.
Following on from a previous post on How to install Exchange 2013 SP1, in this multi-part series I’ll look at the initial configuration steps to get Exchange 2013 sending and receiving emails.
The demo environment I am using includes a Windows Server 2012 R2 domain controller and a single Windows Server 2012 R2 member server running Exchange 2013 installed using the instructions in the link above.
In the demo environment no previous versions of Exchange have been installed so we are setting up everything from scratch.
In this post we’ll look at how to use PowerShell to reduce the size of the WinSxS folder in Windows Server 2012 R2.
A customer has a very quick SSD based server at a cloud provider, but although it is SSD based it only has a tiny 40GB C:, which is a very small footprint for the OS, a couple of apps and logs files. So i was asked to take a look and see what i could do to make a bit of room.
The WinSxS folder contains the files for all the Windows Features you can install in the default operating system. Each time you run a windows update files in the WinSxS folder get update and the size will continue to grow.
Since Windows Server 2012 Microsoft have made it very easy to tidy the WinSxS folder up. They introduced a new feature called “Features on Demand”. Rather than the WinSxS containing all the binaries for all the features you could possibly install on the server, “Features on Demand” allows you to remove the files for features you aren’t using.
If at a later date you want to install a feature you have removed from the WinSxS folder you’ll need to specify a location for the source files.
The Directory Services Restore Mode (DSRM) password is used for restoring Active Directory data on a Domain Controller. During an AD restore you can’t authenticate to Acitve Directory because it isn’t started while you boot into the restore mode and there aren’t any local accounts on a Domain Controller, so the DSRM password is used instead. This is a particularly important password to know in a single Domain Controller environment like an Small Business Server domain (although you can add additional DCs). It’s also a very good password to reset if you take on a new client with existing infrastructure that has been setup by someone else.
On SBS 2011 although you are not prompted to specify the DSRM password, it defaults to the password you use to install the server with. On Windows 2008, 2012, 2012 R2 when you promote a Member Server to a Domain Controller, you are asked to specify the password.
On a couple of occassions recently I’ve changed an 180 day Windows 2012 R2 evaluation server into a full production version. This is particularly useful if your evaluation has worked out well, but you don’t want to reinstall a new producation server from scratch.
In this post we’ll look at the steps required to turn the evaluation server into a production server.
Please note, this does not work for Domain Controllers running on an evaluation license.
Exchange 2013 SP1 was released in February this year providing support for Windows Server 2012 R2. In this blog we’ll run through the installation process.
The demo environment I am using includes a Windows Server 2012 R2 domain controller and a Server 2012 R2 member server.
In the demo environment no previous versions of Exchange have been installed so as part of the installation the Exchange 2013 SP1 we will upgrade the AD Schema, even if you are running Exchange 2013, the installation of SP1 requires a Schema update. Note in this scenario we are going to jump straight to installing Exchange 2013 SP1, without installing Exchange 2013 first.
Finally before we start, always test in a demo environment before deploying in Production!