Renaming and Terminal Services in Server Core

I thought for today’s post I would cover some of the top questions I get on how to do something on Server Core. In coming weeks I’ll expand this into some of my favorite command line tools.


First up is how to rename the box, since there isn’t a remoteable gui to let you do this. This is straightforward if you are domain joined:

Netdom renamecomputer %computername% /NewName:new-name /UserD:domain-username /PasswordD:*

But netdom doesn’t currently provide a way to rename a non-domain joined computer. It is a bit of a hassle to join and unjoin from a domain just to rename the computer. WMI is the solution to this one. Using WMIC you can rename the computer using:

wmic computersystem where name=”%computername%” rename name=”new-name

The one limitation to this is that it must be run while logged on with the default administrator account.


Terminal Services is another common topic. A lot of people think that since there is no shell you can’t TS into Server Core. However, Server Core does include TS remote admin mode, when connected you just have the same experience as if you were logged on locally, a cmd.exe window. TS remote admin mode is not enabled by default and it is another one of those things that is only available in a non-remoteable gui. For this one, we included a script that can be used to turn it on and off, turning it on is done by running:

Cscript \windows\system32\scregedit.wsf /ar 0

Terminal Services by default in Longhorn Server uses a new higher security mode that only allows Vista and Longhorn Server clients to connect. If you want to TS to your Server Core box from a pre-Vista\Longhorn Server Terminal Services client, you need to turn off the higher security mode, which can be done by running:

Cscript \windows\system32\scregedit.wsf /cs 0

Once enabled you can then use the TS MMC snap-ins to remotely manage TS on the Server Core box, or use the TS command line tools. For example, since there is no Start menu to select logoff to end your TS session, you can use the logoff.exe command line tool.


If you are ever trying to find a command line tool to do something, check out the “Command-line reference A-Z” at: This is from Windows XP/Windows Server 2003 help so doesn’t have any of the new Longhorn tools or switches, but it is a useful place to start.



Comments (11)

  1. Anonymous says:

    I realize this post is over 2 years old… but we just (finally) got our 2008 dvd and were thrilled to see a core option.

    So we tried it out. On a machine destined to be a terminal server. Oops. It doesn’t do that.

    Ok, fine, we’ll use core for our web server cluster! Oh, sorry, you can have IIS but no ASP.NET because that’s managed code.

    Then I read here that you can actually turn on terminal services, but only in admin mode (oh, thanks…) and even then you only get the CLI. Why would I use RDP for a CLI? Isn’t that kind of the point of ssh and its precursor telnet?

    Come on, Microsoft peoples! Give us a core os that we can actually use for something more than dns, dhcp,  file/print, and ad! Those are the things that use the least amount of resources in the first place! 🙂

    My 10 (binary) cents.

  2. Anonymous says:

    My friend, netdom works like a charm renaming non-domain joined computers.



  3. davidadner says:

    Don’t know if what’s described above is purely what you need to do with the current beta or if it’s what is planned for the RTM release.  If it’s the latter, then how about a command line equivalent to the new Server Manager.  It doesn’t need to be a 1:1 feature complete equivalent but it could incorporate many of the features, to include things like what’s described above.  The fact that to enable TS you have to run an obscure script with an even more obscure set of switches doesn’t make any sense.  Either make the script and switches logical or incorporate them into a command line tool.  Although ntdsutil.exe has its detractors, if something similar to it was built that contained many of these very common, "core" type commands/options/activities would make use of server core even more likely.  If nothing else, give the scripts and switches logical names.

  4. Thanks for the feedback. This is along the lines of what is planned for RTM. We are looking into more tools for RTM, but listing available roles and optional features is a higher priority.

    If you have suggestions for better switch names, we can change those.

  5. toast says:

    This comment is a little off topic, but I wanted to mention it because this post exhibits examples relevent to my comment, which is about command line interface conventions.

    I understand that PowerShell cannot work on core server because there is no CLR .NET platform support. While this completely throws a spanner into the works and vision of the PowerShell team to make PowerShell the new CLI for Windows administration and automation, I don’t see why much of the good consistancy in PowerShell cannot be adopted by the Core CMD environment.

    Here is a good example:  Why not use the PS way of implementing switches for all utilities? I noticed already in this and other posts on this site that many of the utilities use forward slashes, in direct contradiction to PowerShell.

    Another thing is that the unix MAN pages help system adopted by PowerShell could be adopted by the core CLI.

    Why do we have to go from an exciting new, fully worked out, consistent and STRICTLY implemented CLI (PowerShell) to a "same-old" reproduction of the crappy, mis-matched, poorly documented (help) and un-standardised idiosyncratic syntax of CLI utilities from Windows yester-year CMD?

    If there is one new server system that MUST HAVE a decent CLI, it would have to be Core Server. At least you could get away with a shithouse CLI in a GUI environment, but when your ONLY method of interactively manipulating the system is throught the CLI, you want a very powerfull CLI. I would think that would be pretty clear.

  6. I completely agree, the lack of consistency across command line tools is frustrating to say the least. There are efforts to improve that, but I don’t know how much you’ll see in Longhorn. We are investigating ways that you could at least use some of the PowerShell functionality to remotely manage Server Core, as well as full support in the future. Believe me, this is something we all want.

  7. toast says:

    Hi Amason. I’n sorry if my comment sounds ungratious. It is just that I, like so many others (including hardcore unix admins), have sat up and taken notice of PowerShell in recent times and rejoiced. Clearly, from your comment, yourself and many of your colleagues who are working on Core also want to bring the power and consistency of PowerShell to the system.

    One of the things I failed to consider, at first, was the fact that Core is a particular server option in the Longhorn family (obvious, I know) and that it is likely that all other variations of Longhorn will have the CLR installed by default. I had assumed that Core was how all Longhorn servers would install by default. Hence my rant.

    It appears that Core is specifically targeted at environments that require highly secure servers with barebones installations. Environments like IDCs with isolated AD forests which authenticate web clients. However, I am sure there would be many administrators who like the idea of installing Core on the standard production network because it is simple and efficient. With that in mind, perhaps an optional installation could be the CLR and PowerShell (or PowerShell with a cut down version of the CLR which enables it to function fully).

    Does your team have the capability to request that CLI utilities which are recreated, modified or made new, adhere to a set of requiremets provided by the PowerShell team? This is so that over time Microsoft can bring its legacy CLI utilities to a hight level of quality.

    Cheers, Nick.

  8. No worries, I didn’t take the comments that way at all, as I said I agree with them.

    Yes, we want to bring PowerShell to Server Core and are investigating what we can do in the Longhorn time frame and how we can keep improving it in future versions. The big issue is making it working without dragging a whole bunch of extra dependencies into Server Core, thus eliminating a lot of Server Core’s benefits. We are trying to strike the right balance.

    Correct, and sorry if that wasn’t clear. Server Core is an installation option that you can use to run AD, DNS, DHCP, and File server roles. There is still an option to install Server, with the GUI and support for all the roles and other functionality (MMC, IE, etc).

    There are efforts to standardize new tools that are being created. What is currently in Server Core are the exisiting tools, the same as in Vista/Server, with any minor updates that are being made. Hopefully over time the exisiting tools will improve, or even go away, as PowerShell replaces cmd.exe.

  9. toast says:

    Ah, thanks for your comments. It certainly looks like an exciting time for Microsoft, its partners and customers in the Longhorn/Vista timeframe. I am certainly excited.

    I was talking about Core here at work and some of the more pessimistic admins actually got excited at the thought of less to patch, which certainly is a good point. One could easily see Core becoming the preferred server deployment for other roles besides the four core roles, if it became possible.

    Cheers, Nick.

  10. You’re welcome, glad to hear that you and your colleagues are excited.

    We are looking into adding a couple of roles for Beta 3, but nothing is finalized yet.