Category: Sysadmin

PowerShell 10961B Training – Top 5 Take Aways

rthomson Leave a comment

I recently attended the Microsoft 10961B PowerShell training course. In the spirit of sharing, here are my top five take aways for those new to PowerShell:

Take Away 1: Learning and using PowerShell is all about command and knowledge discovery.

Three cmdlets that help us learn about PowerShell concepts, lookup commands and inspect objects:

  1. Get-Help – Read help information for topics and commands
  2. Get-Command – Find commands based on partial names / concepts
  3. Get-Member – Discover object properties and methods

There are approximately 24 “core” cmdlets that a seasoned PowerShell user will want to memorize. The rest can be discovered on-demand. No need for memorizing thousands of commands.

Take Away 2: Most day-to-day tasks are generally performed on the command line, not by running complex scripts.

Scripting is powerful and useful but it probably makes sense to focus on using PowerShell as a shell first and transitioning to scripting once we want to do more advanced things.

The Microsoft terminal for hosting cmd.exe and powershell.exe is… not so great. Alternative terminal programs to host the PowerShell engine are available. I prefer ConEmu. Install it locally or on a terminal server “jumpbox” and use PS Remoting!

Take Away 3: Everything is an object.

Output of cmdlets are objects that can be fed into other cmdlets to form powerful pipelines of processing. Unlike traditional UNIX/Linux shells, PowerShell commands return objects, not text. While text parsing can be used in PowerShell, most use cases do not require it as there is often a simpler, more direct way of accomplishing the same thing using object properties or methods.

Take Away 4: Remoting is powerful!

Enabled by default on Server 2012 and newer. Uses a single port. Secure. Allows for one-to-one or one-to-many management of remote systems. PS Remoting is a great alternative to logging into remote servers with RDP to perform manual GUI tasks.

It’s almost like SSH in UNIX/Linux, but flavoured for Microsoft Windows.

Take Away 5: PowerShell is the current and future best practice for managing Microsoft Windows.

With the release of Windows 8 / Server 2012 (PS 3.0 and newer), Microsoft has provided over 1500 cmdlets to manage their flagship operating systems. It is clear that PowerShell is how Microsoft intends to move management of Windows forward from here on out.

Summary

Start learning PowerShell today to stay current with modern practices for management and administration of Microsoft products!

RDP Inception and Password Changes

rthomson 1 Comment

A common pain point that seems to come up regularly among technical folks is how to change a Windows account password over an RDP connection.

The correct answer is Control+Alt+End, right? Of course.

However, this doesn’t work as you might expect when you’re lost in RDP “Inception“. RDP inception is when you’re multiple levels deep with RDP connections, such as would be common when using one or more “jump boxes” or intermediate systems.

Example: Local Device->RDP1->RDP2->RDP3

When you’re lost in RDP inception, the Control+Alt+End command is sent to the very first RDP session you are connected to. In our example above, that would be RDP1. So what about changing your password on RDP2, RDP3 or any other systems beyond RDP1? The On-Screen Keyboard (osk.exe) is your new friend. Using osk.exe to bring up the Control+Alt+Del menu is not necessarily intuitive, though.

The Method

  1. Launch osk.exe in the RDP session for which you want to change your password.
  2. Hold down Control+Alt on your physical keyboard connected to your local device.
  3. Click “Del” using the On-Screen Keyboard running in the RDP session for which you want to change your password.

The Control+Alt+Del menu will now appear within the desired RDP session, allowing you to change your password.

Note: The “Desktop Experience” feature appears to be required for osk.exe to launch on Windows Server 2012 and perhaps also 2008 (untested).

NFSv4: Interop, ACLs & Automount

rthomson 2 Comments

NFSv4 has been around for a long time but it still seems a bit foreign to me. The following is a quick rundown of things I recent learned related to NFSv4 from limited experience in implementing it.

Interoperability

Is it possible to setup NFSv4 along side NFSv3 on the same server, serving the same volumes? Of course. However, it might not always work exactly as expected with legacy clients.

A normal /etc/exports for NFSv3/v4 interoperability might look like so:

/export                   10.0.0.0/8(rw,no_subtree_check,fsid=0)
/export/namespace         10.0.0.0/8(rw,no_subtree_check)
/export/namespace/share1  10.0.0.0/8(rw,no_subtree_check)
/export/namespace/share2  10.0.0.0/8(rw,no_subtree_check)

With this configuration, we have the “virtual root” export (fsid=0), the namespace export (for mounting the whole namespace with one mount) and the individual “share” exports (for mounting individual shares, most likely with automount). The NFSv4 clients can perform mounts using the servername:/namepace syntax and the NFSv3 clients can mount the whole root, namepace or individual “shares” with servername:/export, servername:/export/namespace or servername:/export/namespace/share1.

All is well in the NFS world… or so it seems at first. It turns out that an older SunOS does not entirely like how this RHEL 6 NFS server is exporting the file systems:

hostname% cd /namespace
hostname% ls
share1     share2     share3     share4
hostname% pwd
/namespace
ubcpetnxi% cd share1
ubcpetnxi% pwd
/share1

Notice the final line. I was just in /namespace then I changed into /namespace/share1. Now pwd tells me the path is only /share1. I was expecting /namespace/share1. It looks to me like the SunOS NFS client is not behaving well with how the NFS server exporting the file systems and/or how the bind mounts are setup locally on the server to map the storage into the NFSv4 “virtual root”.

Please leave a comment to if you know of a different /etc/exports and/or mount configuration that would alleviate the SunOS NFS client issues noted here!

Access Control Lists

NFSv4 defines a model for Access Control Lists (ACLs) that has similarities to that of Microsoft’s NTFS. But don’t worry about interoperability: NFSv4 translates your existing “POSIX” ACLs on ext3,ext4,xfs,etc. to NFSv4 ACLs automatically.

The main gotcha with exporting a filesystem with “POSIX” ACLs with the NFSv4 server is that the normal getfacl and setfacl tools don’t seem to work on the NFS client side! Because the NFSv4 server only presents the translated NFSv4 ACLs to the clients, the nfs4-progs package must be installed and the nfs4_getfacl and nfs4_setfacl commands used instead to view and manipulate the ACLs on NFSv4 clients.

Also, the little + at the end of the rwxrwxrwx permissions listing you can see with some variant of ls -l, the symbol that normally indicates the presence of an ACL, it simply doesn’t appear on a (Linux?) NFSv4 mount where ACLs exist. Sadness.

Automount

Automount on RHEL 6 (and clones) appears to have a bug related to bind mounts. NFSv4 exports cannot (trivially?) be mounted locally on the NFSv4 server on itself with bind mounts as is possible with NFSv3 (or lower) exports. I have read that this inability is due to the “virtual root” abstraction that NFSv4 employs. Instead, automount should be performing true NFSv4 mounts when operating locally on the server… but it doesn’t do that on CentOS 6 (and in my experience RHEL 6):

See: http://bugs.centos.org/view.php?id=6101

The workaround is to specify port=2049 in the NFS mount options of the automount map in use (where 2049 is the port the NFS server is listening on). This appears to cause automount to immediately attempt an NFS mount, bypassing the (failing) attempt at a bind mount.