Home » Windows Server
Category Archives: Windows Server
If you manage servers you have likely come to a point where you finished doing work and got a prompt ‘Your server needs to reboot. Reboot now?’ Well you can’t reboot now… not during business hours. I guess you’ll have to come back tonight… or this weekend, right?
Wrong. Scheduling a reboot is actually pretty easy in Windows. Try this:
- Open Task Scheduler (taskschd.msc).
- In the Actions pane click Create Basic Task…
- Name the task accordingly… Reboot System for example.
- On the Task Trigger page click the radio button One Time
- On the One Time page enter the date and time when you want the server to reboot.
- On the Action page select Start a program.
- On the Start a Program page enter the name of the program shutdown.exe. In the Add arguments box enter /f /r /t 0. This will force the programs to close, restart the server (instead of just turning it off), and set the delay time to 0 seconds.
- Once you have done this your server will reboot at the precise time you want it to, and will come back up.
**NOTE: Don’t forget to check. it is not unheard of in this world for servers to go down and not come back up as they are supposed to!
Do it in PowerShell!
Using PowerShell to script this will allow you to not only save the script, but also run it on remote servers. From Justin Rich’s blog article I found this script:
Like most IT Managers I manage myriad servers, most of which are both remote and virtual. So when I configure them initially I make sure that I can manage them remotely… including in most cases the ability to connect via RDP (Remote Desktop).
But what happens if you have a server that you need to connect to, but does not have RDP enabled? Using PowerShell it is rather simple to enable the RDP feature remotely:
Enter-PSSession -ComputerName computername.domain.com –Credential domain\username
Set-ItemProperty -Path ‘HKLM:\System\CurrentControlSet\Control\Terminal Server’-name “fDenyTSConnections” -Value 0
Enable-NetFirewallRule -DisplayGroup “Remote Desktop”
Set-ItemProperty -Path ‘HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp’ -name “UserAuthentication” -Value 1
That should get you going. Good luck!
Those of us who have been in the IT industry for a while remember the heady days of never having to reboot a server… otherwise known as ‘The days before Windows Server.’ Those days are long gone, and even non-Windows servers need to be patched and restarted.
But how do you know when it last happened? If you have a proper management and monitoring infrastructure then you can simply pull up a report… but many smaller companies do not have that, and even in larger environments you may want to figure out up-time without having to go through the entire rigmarole of pulling up your reports. So here it is:
- Open a Command Prompt
- Type in net statistics server
There will be a line that says Statistics since m/dd/yyyy… That is when your server last rebooted.
If you want to shorten it, you can also just type Net Stats SRV. It provides the same results.
Incidentally, while the command specifically states Server, it works for workstations too.
…And now you know.
When I was a Virtual Technical Evangelist for Microsoft Canada I spent a lot of time telling you why you should use Server Core… especially if you were on Hyper-V. Why? You save resources.
It is now over two years since I turned in my Purple Badge, and I still think Server Core rocks. In fact, when Windows Server 2016 comes out I will probably spend a lot of time telling you about the new Nano Server option that they are including in that version. More on that to come.
Of course, I still like Hyper-V, but as an independent consultant I recognize (as I did quietly when I was with the Big Blue Machine) that the vast majority of the world is still running VMware for their enterprise-level server virtualization needs. That does not change my opinion of Server Core… it still rocks, even on VMware.
Of course, in order to get the full benefits of the virtualized environment, a VMware machine requires the installation of the VMware Tools (as Hyper-V requires the installation of Integration Services). With a Server with a GUI that is easy to do… but since Server Core is missing many of the hooks of the GUI, it has to be done from the command line. Here’s how:
1. As you would with any other server, click Install VMware Tools
2. Connect to and log on to the virtual machine. You will have to do this with Administrator credentials.
3. navigate to the mounted ISO (if you only have a single hard drive attached it will usually be D:)
4. type in the following command line: setup64.exe /S /v “/qn reboot=Y”
Once you have done this, the VMware tools will install, and your server will reboot. Nothing to it!
One of the benefits of virtualization is that you can segregate your SQL Servers from your other workloads. Why? If not then Microsoft SQL Server will hoard every last bit of resources on your machine, leaving scant crumbs for other workloads.
Seriously… when you start the Microsoft SQL Server you will immediately see your memory usage jump through… or more accurately, to the roof. That is because SQL Server is actually designed to take up all of your system’s memory. Actually that is not entirely true… out of the box, Microsoft SQL Server is designed to take up 2TB of RAM, which means that in all likelihood a lot more memory than your computer actually has.
So assuming you have been listening to me for all of these years, you are not installing anything else on the same computer as your SQL Server. You are also making sure that the virtual machine that your SQL Server is installed on (remember I told you to make sure to virtualize all of your workloads?) has its memory capped (Hyper-V sets the default Maximum RAM to 64GB). You are doing everything right… so why is SQL performing slowly?
It’s simple really… Your computer does not have 2TB of RAM to give SQL Server… and if it did have 2TB of RAM, the operating system (remember Windows?) still needs some of that. So the fact that SQL wants more than it can have can make it a little… grumpy. Imagine a cranky child throwing a tantrum because he can’t have deserts or whatever.
Fortunately there is an easy fix to this one (unlike the cranky child). What we are going to do is limit the amount of RAM that SQL actually thinks it wants… and when it has everything that it wants, it will stop misbehaving.
1) Determine how much RAM the server on which SQL Server is installed has.
2) Open Microsoft SQL Server Management Studio with administrative credentials.
3) Connect to the database (If you have multiple SQL databases on the same server see the note below)
4) In the navigation pane right-click on the actual SQL Server (the topmost item) and click Properties
5) In the Server Properties page navigate to Memory
6) Figure out how much 90% of your server’s RAM would be (in megabytes). Use the following equation:
1GB = 1024*.90=921.6
8GB = 1024*8 (8192)*.90=7373
7) In the Maximum server memory (in MB) field type that number, then click OK.
**Note: The math we are using here allocates 90% of the total RAM to the SQL Server. In the event that you have multiple SQL Server databases running on the same box you will have to do a bit of calculating to determine how much each database should use… and that can be a challenge.
If you only have the one database engine on your box, you should immediately notice marked improvements. This breathing room does not mean that it is now time to pour more workloads onto the server… only that your SQL Server should be running a little better!
Anyone who has taken a basic networking course will understand that UNC (Universal Naming Convention) paths are one of the common ways we in IT access file shares across our local networks. They will usually look like this: \\oak-mgt-01\Sharename. Of course, you can see all of the shares on a particular server by just entering the servername (\\oak-mgt-01). Once upon a time Windows Explorer would show you that path in the address bar, but in this era of simplification of everything (i.e.: Dumbing it down) it makes it prettier by showing > Network > oak-mgt-01 > Sharename. This changes nothing, it is the same under the hood.
Users are not the only ones who use these UNC paths. In fact, it is our servers and applications that use them far more frequently than we do, because under the hood that is what they use to connect to any network resource.
But what happens when UNC paths stop working?
A client called me recently to tell me that none of their UNC paths were working, and because of it their production applications were down. I checked, and sure enough a particular server could access the Internet just fine, and it could ping every internal resource it wanted, but when you tried to navigate to any UNC path, the result was a very unfriendly and generic one:
Not only was it not working, it was not even giving me a descriptive error code. I started down a troubleshooting rabbit hole that would haunt me for hours before I found the solution.
The first thing that we confirmed is that while we were pretty sure that this was a networking issue, it was contained within the specific server. How did we determine this? We discovered that we got the same result when we tried to navigate to \\localhost. Localhost is that trusty loopback adapter that exists in every network device, and is the equivalent of \\127.0.0.1… which of course we tried as well. Because we know that Localhost lives within the server, we knew that it was not an external issue.
Before we went out to the Internet for other ideas, we tried all of the obvious things. We changed the NIC, we verified DNS, WINS, and even NetBIOS over TCP/IP. We reset the network connection (netsh ip reset c:\resetlog.txt). Nothing doing.
We went out to the Internet and followed the advice of several people who had been in our spot before. We uninstalled and then reinstalled several networking components. We deleted phantom devices, we ran network reset tools. No joy.
When I came across Rick Strahl’s Web Log I thought I was close…he had experienced exactly the same symptoms, and in his article UNC Drive Mapping Failures: Network name cannot be found I was hopeful that when I re-ordered the Network Provider Order in the registry (HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order) I would be home free. Unfortunately I was wrong… but I was in the right place.
When Rick’s solution didn’t work, I was disheartened. I was about to close it out and look at the next ‘solution’ on-line. My instinct however told me to look again… to look closer.
There was a typo… but you have to really know what you are looking at to see it. In fact, even if you really know what you are looking at, it is easy enough to miss. Take a look… do you see it? Look closer… The entry LanmanWorkstation is right there, clear as day, right?
Nobody would blame you for not noticing that there is an S at the end of the string… because S is so common at the end of words – it just makes them plural, right? Well computers – and especially the Windows Registry – does not know English grammar, it knows binary… and the difference between LanmanWorkstation and LanmanWorkstations is the difference between working… and not working.
When I made the change it was instant – no reboot was required, the server application started working immediately. A big sigh of relief permeated the office.
The server in question is one that several people were working on when it stopped working, and nobody is entirely sure how it happened… was it human error, or did a rogue process cause it? We will look in our logs and figure that out later. For the moment though, our UNC paths are back, and my client is back at work.
In a recent conversation I realized that there are still a lot of misconceptions about OEM (Original Equipment Manufacturer) operating system rights with regard to Windows Server. While I am not here to say who is right and who is wrong (whether one should or should not buy OEM operating systems), I still think it is important to understand the facts.
Myth #1: OEM licensing is limited, and cannot be upgraded.
An OEM license is indeed tied to the physical hardware for which it was purchased. This is a distinct disadvantage to purchasing Volume Licenses (VLs). However when you buy an OEM operating system you have thirty (30) days to add Software Assurance to it. Any license with Software Assurance attached to it can be upgraded as new versions are released. However there is one important bit to understand… when decommissioning that server, the SA can be detached from the license and attached to another… but the OS itself cannot.
Myth #2: Virtualization rights are unclear on OEM licenses.
I hear this from people all the time, and although I have tried to explain it to many of them, sometimes I simply have to shrug my shoulders and walk away from it. There is nothing murky or unclear about virtualization licensing. Whether your host (hypervisor) is an OEM license, VL license, or FPP (Full Package Product) license, your virtualization rights are the same, and they depend not on how you bought the license, but what tier you bought (Standard vs. Datacenter).
The OEM license is applied to the host, and must be tied to that host. However the guest VMs (2 on Standard, unlimited on Datacenter) do not have any restrictions. Like any guest VM on any other license, they can be migrated to any other host, as long as the destination host has allowance – so if the destination host is Windows Server Standard Edition, it cannot host a third guest VM, but if the destination host is Windows Server Datacenter Edition, the only limitation is based on the available resources (CPUs, RAM, storage).
Myth #3: There are things you can with OEM Editions that you cannot do with VL Editions.
While this is a less common complaint, it is still there. I am told (and I have not really looked into this) that with Windows Server OEM versions (let’s take the HP ROK as an example) you can modify the image to show your logo during the boot-up process. While this is true, I have two points to it:
1) If you know what you are doing you can customize the boot process of any Windows Server installation, regardless of the edition or version.
2) Folks, it’s a server… how often are you rebooting it? Most of my servers (especially virtualization hosts) don’t reboot for months at a time. When they do get rebooted, it either happens at night (when I have scheduled patches) or remotely, when I am not sitting and watching the POST process. I can’t imagine there are too many customers who sit and watch their servers either…
Myth #4: When a reseller consultant sells OEM licenses there is more room for profit.
I am usually very saddened to hear this, but that is mostly because I am not the sort of consultant who makes a lot of money off products; I would rather make my money off my time, and that is what I do. I don’t like hearing that there are resellers who buy a cheaper (and less versatile) option but resells it for the same price as the full version. Aside from the previous point also applying, I am always certain that my customer will find out and call me on it, and I will lose their trust. It is just not worth it to me. That doesn’t mean it isn’t a legitimate issue for some.
There is nothing wrong with OEM licenses, and they are certainly less expensive than other ways of purchasing the operating system. They are just as versatile as non-OEM licenses, but not especially more versatile. If you replace (not upgrade or add more) servers often then they are likely not a good option for you, especially since they don’t add value to the physical server if you resell it. However if you keep your servers for more than a couple of year (as most companies will) then the cost savings might make it worthwhile, and if you do the cost benefit comparison, you might just come out ahead… and that’s CONFIRMED!