Windows Server

Know about WinRM (Remote Management) and WinRS (Remote Shell)

Miguel Garrido — Wed, 20 Jan 2010 01:05:14 GMT

I just recently migrated my data to another machine (to use as a file server) since it has a Sans Digital NAS attached to it. Normally working with files across the network (I now map a shared drive to the share on the server) is perfectly acceptable – however, there are some operations better left on the remote machine, for instance: extracting or compressing [rar/zip] archives.

Ideally, I’d prefer to have a solution where I can (in this case) right click on an item on my machine and run a command on the remote machine, and with WinRS and some programming I may get it done eventually, but in the meantime as a quick and dirty solution I set up WinRM on both machines and I currently start a command prompt instance using WinRS and I can use the command line rar.exe or 7za.exe for dealing with archives on the remote machine.

TechNet has more information on WinRM and WinRS, for brevity I am just going to outline what I had to do to get my current solution working:

First, from an administrative [read: elevated, if applicable] command prompt execute: winrm quickconfig on both machines, answering each prompt with yes.

If the machines are domain joined then they already trust each other thanks to Kerberos, however if the machines are part of a workgroup you need to tell each machine to trust the other by executing: winrm set winrm/config/client @{TrustedHosts=”%remotecomputername%”}. (Note: replace %remotecomputername% with the hostname of the remote computer.)

Now you should have all that is needed to either remotely manage each machine from the other using winrm (e.g. starting or stopping a service, or querying information using WMI) or run commands on the remote machine using winrs. My particular usage is: winrs –r:%remotecomputername% cmd.exe. This command will start a remote command prompt instance that I can then use to navigate directories on the server and run command line utilities like 7za.exe or netsh, ipconfig, etc.

If you prefer PowerShell, there is one more step that needs to be taken from within an elevated PowerShell command prompt, on the machine that you want to remotely connect to execute: Enable-PSRemoting. This will enable the PowerShell listener and PowerShell should then accept connections from remote PowerShell instances. To connect to the remote PowerShell session execute: Enter-PSSession %remotecomputername%.

Again, I did not go into any detail on this because 1) I am not an authority and I didn’t look further than this, and 2) there is plenty of information on the web and TechNet regarding this topic.

I will probably post an update to this post if/when I ever decide and have enough time to write some code that will allow me to execute canned commands on a remote machine (mainly targeted at extracting archives on the remote machine right now).

Enjoy reading up on WinRM/WinRS.

Infrastructure Master FSMO role and Global Catalogs in your Active Directory domain

Miguel Garrido — Mon, 21 Sep 2009 02:42:52 GMT

Remember: If only some of your Domain Controllers are Global Catalogs make sure that the domain controller that holds your Infrastructure FSMO role¹ is not a Global Catalog. The reason for this is that a global catalog that holds the infrastructure master role will stop looking for and removing phantom objects in your directory since it will have no phantom objects (we all know global catalogs hold partial information on every object in the directory) because it knows about every object in the directory if even a little.

However, if all your domain controllers are global catalogs, then it doesn’t matter where the infrastructure master lies since all domain controllers will know about everything in the directory and will (unless there are bigger problems) have accurate information about your directory objects.

Notes
1. http://support.microsoft.com/kb/197132

Make use of additional UPN suffixes for your Active Directory domain

Miguel Garrido — Tue, 08 Sep 2009 13:00:00 GMT

With the advent of Active Directory, the old school Security Accounts Manager (SAM) account names are almost a thing of the past, not that anyone got the memo. Most people still authenticate to their domain using their SAM account name, which is usually DOMAIN\username; with DOMAIN being the NETBIOS name for the AD domain.

While this is still (as previously mentioned) widely used and acceptable, in my opinion there is a more appealing method for having users log into their accounts on Active Directory networks, and that is using the User Principal Name (or UPN) suffix. A UPN will allow a user to specify their username@upnsuffix to log into their account, and you can now see why this is appealing for some users. If your domain name does not live in the global DNS namespace, you probably have an Active Directory domain utilizing a .local suffix, or a sub-domain of a domain that does live in the global DNS namespace like corp.mydomain.com. By default, the UPN that is added (and thus shows up in the Account tab of an Active Directory user’s properties) is the fully qualified domain name (FQDN) of your Active Directory domain. This can be quite a task to type, if, for instance your FQDN is corp.mydomain.com. In my opinion this is one of the main reasons that a down-level SAM account name is still used to log into AD domains most of the time today. But what if you could add the UPN suffix of your internet facing domain name, the domain name that your users are assigned for their e-mail addresses to the list of UPN suffixes that they can use to log into the network?

As an administrator, you will know that each user will at least remember their e-mail address, so they can share it with co-workers or colleagues outside the company (and the GAL). Allowing a user to log on with their e-mail address gives your users less to remember and in the end can even save you a support call if they need to log in to OWA or Outlook on their laptop configured with Outlook Anywhere. The reason for this is that they are logging into their domain and will sooner remember to type in their e-mail address than remember the NETBIOS name of the domain they use to log into the corporate network.

Now to answer your question before you ask it, you can add any UPN suffix you want inside your Active Directory forest, you will naturally want to choose something your users can relate to, but you don’t necessarily need to follow that advice either. Once you add a UPN suffix to your forest, you simply need to navigate to the Account tab on a user’s properties in AD and change the drop down in the User logon name: section to the UPN suffix that you’ve just added to the forest. You will recognize the UPN suffix because it looks like the end of an e-mail address. This can also be scripted using the DS commands (more on those in later posts), in case you want to change the UPN suffixes for accounts already present in Active Directory to allow log on with your newly created UPN suffix.

So now, I’m sure you are asking yourself “Where is it that I add these UPN suffixes? Tell me already!”

You can add a UPN suffix to your forest by opening the Active Directory Domains and Trusts snap-in, right clicking the root of the snap-in which is Active Directory Domains and Trusts and clicking on Properties. From there you will see a UPN Suffixes tab, and it is here where you can add the new UPN suffix to be used in your forest (and domains within the forest).

If you only have one domain controller (shame on you, there should be at least two DCs in each AD domain), but if you do only have the one, you should be able to make the change instantaneously to your accounts. Otherwise, you will need to either force replication using the repadmin utility, or wait long enough for the DCs to replicate between each other.

Now your users will be able to log into the domain using username@mycompany.com instead of username@corp.mycompany.com or username@mycompany.local or MYCOMPANY\username, and you want this because a user will sooner remember his e-mail address than any of the latter example account names. However, just because they can log in with one does not mean they can’t log in with the others, as long as the UPN suffixes are there and/or the NETBIOS name is correct, the user should be able to log into the network using any of the previous account names. Correction: Once the UPN suffix for an account has been set, the user will only be able to authenticate using that UPN suffix, the domain NETBIOS name followed by a backslash and the username will also continue to work (since that will provide the server with the old SAM account name).