Monday, February 6, 2017

How to enable remote desktop protocol via Group Policy

It is deceptively challenging to enable Terminal Services / Remote Desktop Protocol / RDP in an automated fashion across an entire domain (or in an entire OU within a domain).  At least it was to me.  The task is pretty easy if you only want to grant this access to administrators; but we have IT interns at my office, and I want them to be able to get to the console of servers but have limited permissions once there.  In other words, they aren't administrators.

What makes this challenging is that there is a Group Policy setting for "Allow log on through Remote Desktop Services."  At first glance it appears this is all you need to set and you'll be done.  However, there is one more step that must be taken IF the user you wish to grant rights to is not a member of the local Administrators group (or the Remote Desktop Users group) on the computer they'll be connecting to.  This was my case. 

I created a new AD group called "Domain Admins (limited)" and added the intern's account to this group.  I configured this group to have the "Allow log on through Remote Desktop Services" user right (details below).  However, he could not establish a successful connection via RDP.  When he tried he got this message:

Error: The connection was denied because the user account is not authorized for remote login.

After some research I came across this excellent blog post that explained what was going on and got me most of the way to where I wanted to be.  After putting together a few more pieces I thought I'd create my own blog post that would provide complete step-by-step instructions for this setup.  

If you want to provide RDP access to all the computers on a domain (or OU) for an AD group that you've created, here's how to do it:
Create your AD group and add the desired members.  The group and its members are not required to have domain administrative or even local administrative privileges.
Specify the group created above in the following setting in the appropriate Group Policy Object (GPO): Computer Configuration| Policies | Windows Settings | Security Settings | Local Policies | User Rights Assignment | Allow log on through Remote Desktop Services.
Here's the part I had missed initially: Configure a Group Policy setting to add your new group to the local Remote Desktop Users group, as follows.  
  1. In the Group Policy Editor, locate and edit the appropriate GPO.
  2. Go to Computer Configuration | Preferences | Control Panel Settings | Local Users and Groups.  Click it (to highlight) on the left side.
  3. Right-click in the right pane and select New | Local Group...
  4. TYPE the name of the local group (DO NOT choose from the Group Name drop down list).  The group name should be Remote Desktop Users
  5. Click Add... at the bottom
  6. Click the "..." button and search for/choose the group to be added to the local Remote Desktop Users group and click OK.
  7. Click OK on the Local Group Member dialog.
  8. Click OK on the Remote Desktop Users Properties dialog.
  9. Close the Group Policy Management Editor
Now your desired group will be inserted into the Remote Desktop Users local group for all the computers in the Domain (or OU).

EDITED 2/23/17 to advise to not use the drop-down list for selecting the local group name.  If you do, the name of the group will be "Remote Desktop Users (built-in)", and a new group with that name will be created for you.  That's not what you want.

Friday, February 14, 2014

Mouse jumps around in Xenapp published app / fixed using Citrix Receiver


  • We had a problem where the mouse jumps around when running Citrix published apps.
  • Resolution identified as installing Citrix Receiver and ditching the Online Plug-in.
  • Craig gets unhappy because Citrix Receiver no longer allows launching of apps from the tray.
  • Unhappiness directed at Microsoft.
  • Resolution found for launching apps almost like we've always done.

We recently had a problem where the mouse jumps around when a dialog box is displayed.  This occurs when an end user is running a published (seamless) application from our Citrix XenApp 6.5 farm, using the Online Plug-In version 12.x or 13.x, and they have multiple monitors and the monitors do not all have the exact same resolution (or orientation).  Pretty specific, I know, but this problem is not really the focus of this post.

If you are having the specific problem mentioned above (the mouse jumping around when a dialog box appears when running a published app from a XenApp farm), then you may want to know that the fix is likely to uninstall the Online Plug-in and install Citrix Receiver. We installed version 3.4 Update 3 (at the suggestion of a Citrix technical support representative), which is not the latest version.  It does correct the mouse problem (yea!).

However, suddenly my end users can no longer launch applications from the system tray, which they've done for some 12 or so years now.  Bummer, to say the least.  Here's what I know: says:
Cause: Receiver for Windows 3.0 - Citrix has specifically deprecated support for the option of launching applications from the Notification Area menu to achieve a better and more intuitive user experience in Receiver deployments. This type of access on Windows 7 causes issues. Application access from the Notification Area is no longer consistent with Microsoft User Experience Guidelines. (bold type added for emphasis)

To those who would ask the question "why would you want this functionality anyway?":  Some have suggested that we should use the Start button, because that's where programs should be launched from.  The answer is simple: On a local computer there are lots of applications that are not work-related (not essential to performing one's daily tasks) and that are just "in the way."  My users should not have to wade through this just to access the targeted, concise application list that they need to do their everyday work.  (Do I really need a Program Group and icon for Microsoft Silverlight?  How about the Microsoft Mouse and Keyboard Center?  Java?  Quicktime?  SQLXML 3.0?  ...are you getting the picture?).  Using XenApp I can customize an application list that contains only those items that our end users need.  Yes, I could probably remove some of the unneeded application folders/shortcuts with desktop management tools, but I don't need to... I have Citrix XenApp that can populate a concise application list -- oh, wait.

In addition, there are some applications that are installed both through Citrix and locally.  It is sometimes important for an end user to specifically launch one or the other.  Using the Start button is a bit problematic (and less efficient, at least) in this regard.


So in order to resolve the mouse problem I have to install Receiver, which will now greatly inconvenience our users.  They'll have sometimes 15 applications open - layered on top of one another.  In order to get to their concise application listing they'll have to minimize applications so that they can see their desktop, open up the folder that Receiver has placed on the desktop, then locate and launch the app.  Using the Start button is a last resort in my mind.

Furthermore, I can't even find a way to pin the desktop folder that Receiver creates onto the Taskbar.  It only wants me to pin it to Windows Explorer, which means the user has to click the Explorer icon on the taskbar and then click the Citrix Applications folder.  ARGH!

Thanks to another poster in a forum (nod to your post Reto Gloor).  Here's exactly what I did (worked on both Windows 7 and Windows 8):

  1. Uninstall the Online Plug-in.
  2. Install Citrix Receiver 3.4 Update 3.  Not sure why the technician did not want us to use the current version, 4.1.
  3. Tell Receiver (3.4 update 3) to display a desktop icon:
    1. (right-click the Receiver's tray icon and select About.
    2. Click Advanced.
    3. Click Online Plug-in Settings.  Note that a reboot may be required before you'll see this option.
    4. Click Options
    5. Click Application Display.
    6. Check "Show applications on desktop" and give the folder a name.  Actually for me the name field is grayed out.  It says "Citrix Applications".  I don't know if that's a default name or not, because that's the folder name we used before.
    7. This will display the named folder on your computer's desktop.
  4. Right-click on an empty spot on your Windows 7 or 8 Taskbar and select Toolbars | New Toolbar.
  5. You will be prompted to Choose a folder for the new toolbar.  Browse to your desktop and select the named Citrix applications folder.

This will place a nice folder icon thingy just to the left of your system tray.  It works great for me... now will roll out to a few end users who are having the mouse problem, which is where this all started!

Tuesday, May 7, 2013

Tech Tip - Zooming in Excel and Word

Tech Tip - "Zooming" in Excel and Word

Is the information in your Excel spreadsheet or Word document too small for you to read comfortably?  Don’t squint or lean toward your monitors!  It’s easy to make the spreadsheet or document appear larger on your screen by using the “zoom” feature.  There are a couple of ways to do it, and they both accomplish the same thing.  Use whichever method you like (and can remember) best:

  1. Hold down the Ctrl key on your keyboard while rolling the scroll wheel on your mouse.  Rolling the wheel forward will zoom in (will make the spreadsheet or document appear larger), while rolling the wheel backward will zoom out (will make the spreadsheet or document appear smaller).
  2. There also is a zoom tool in the lower right corner of the Excel or Word screen (see figure below). Just click the “+” or “-“ buttons to zoom in or out.  You can also move the slider (in between the “+” and “-“ buttons) left or right to zoom in or out.

Craig Rhinehart
Director of Information Technology

Monday, February 11, 2013

Group Policy Preferences with Item-Level Targeting.... watch out for Distribution Groups

I've been using IFMEMBER.EXE (from an old Windows Server Resource Kit... not even sure which version) in my login scripts for a long time.  This handy but awkward command lets you test for a user's membership in a Security Group.  I won't go into details about it here because it's not the point.  The fact that it's awkward and login scripts are growing more and more dated is important to this post, however.  Most things that you used to do in login scripts can now be handled differently.  One of the last items still in my login scripts is assigning printers based on group membership.  The reasons we need to do this are simple: people in our office need to be connected only to those printers that are near them.

As a side note, I also like to automate printer disconnection; and have found/devised a scriptable command to do this, too.  It's handy for when a printer is retired or its name needs to change for some reason.

Today I needed to restrict certain mission-critical printers in a "production" area so that only a limited group of people could print to them.  Prior to today, these were "common" printers - everyone was connected to them.  Therefore, I needed to remove the existing printer connection from everyone except those people who still need to print to those printers.  No problem for me... I whipped out my login scripts and crafted a few additional lines using a combination of the lovely IFMEMBER.EXE command and my printer disconnect script.  I also worked into the code a few lines to connect anyone to those printers who should have them.  This is being prepared for when a new person moves into or out of that functional area... all I would have to do is change their group membership and they'd either get, or have deleted, all the right printers.

Today things weren't working properly, though.  In my script I tested a new security group "PRINTERS-ASSEMBLY" (which itself contained two other groups... this is an important nuance)  and mapped or deleted printers based on the value of the environment variable ERRORLEVEL (which is how IFMEMBER.EXE works).  But it wasn't working properly for one of my users.  She didn't have the printers she was supposed to have.  So I began troubleshooting.

I narrowed down the problem to the fact that IFMEMBER did not recognize her as being in that group.  I didn't test any other users yet, as she was the only person complaining.  I reviewed the scripts and became satisfied that there were no dumb errors there... they were coded properly.  IFMEMBER simply wasn't acknowledging that the user was a member of the group.

While researching IFMEMBER in order to give myself a refresher - again looking for something dumb I might have done - I came across several articles describing something called "Item-Level Targeting" in Windows Server 2008's Group Policy Preferences.  (Here's one of them).  I had looked at Preferences before, but I was unaware of ILT.  I configured some ILT-based preferences for the printers in question and even used the "remove" option so that people who didn't need the pritners would have them removed by this same setting.  Sweet!  But it still didn't work.  Fro some reason this user was not seen as a member of the group.

At this point I will describe how the user was a member of the group.  The new group was called PRINTERS-ASSEMBLY.  It contained, among other things, a group named CLERKS.  This user was a member of the CLERKS group.  Aha!  I jumped to the conclusion that neither IFMEMBER or ILT recognized members of sub-groups.  I even confirmed this (so I thought) by adding the user directly to the PRINTERS-ASSEMBLY group.  When I did, the IFMEMBER and ILT mechanisms worked fine.  I was prepared to call Microsoft to step through all this and find out if there was anything that could be done.  Thankfully one of my more AD-savvy admins took a look at it with me, and together (I'll take part of the credit) we identified the problem... Distribution Groups.  The sub-group that the user was a member of was a Distribution Group - not a Security Group.  We had never had a need to use that group as a Security Group - it was in existence strictly for use as a handy way to e-mail a handful of people at once.  When I added it to the PRINTERS-ASSEMBLY group I didn't stop to check to see what type of group it was... I just added it and rocked on.

After fiddling around for a little while, we arrived at a great solution that just might help someone else one day, so I will outline it here.  If your ILT (or IFMEMBER) isn't returning a group membership that you know is correct, check the group's type.  If it's a Distribution Group, neither of these mechanisms will report membership.  So what do you do?  Simple:
  1. Make note of the members (and any other special properties) of the Distribution Group and then delete it.
  2. Create a new Security Group using the same name.
  3. In Exchange, create a new Distribution List from an Existing Group, and then select the newly-create Security Group.  This will create a Distribution-Enabled Security Group.  With this new entity you can both e-mail to its members and check for group membership using ILT and IFMEMBER.
If I had been creating all the groups from scratch this wouldn't have been a problem.  It's only because I was utilizing existing groups (and didn't check their type before adding them to a new group).  But it was a real problem with a pretty specific solution.

Monday, July 11, 2011

Correcting Dynamic Disk is Invalid message

This was a really odd situation in my VMware ESXi environment involving a virtual disk that needed resizing.  I needed to add a few gigabytes to a virtual hard disk, which I have done scores of times and have my process pretty well down pat.  This one was a little different and I had to do some research and obtain some new tools.

My normal process is this:
  1. Add space to the .vmdk using the vSphere Client / vCenter Console.
  2. Use the diskpart command on the server to select the disk and volume in question, then issue the extend command. 
  3. If the command cannot complete (because the disk is in use in a certain way by the server), then I have to shut down that server and add the hard disk to another virtual server (as it's D: drive, for example).  I then perform #2 above from that server's console, detach the disk, and then power up the original server.
It's one of my favorite little admin tasks to do in VMware, because I know what it would take for me to add disk space to a server in the "real world", and I giggle a little bit every time I do it.

Today when I tried to use diskpart I could not see the volume when I ran the list vol command.  I knew then that something was wrong.  I check Disk Management (it's a Windows Server 2003 machine) and saw that the disk was a dynamic disk and was "Invalid".  I had never seen that before.  I could still access the disk just fine -- I could still see and manipulate all the files on the disk... I just couldn't make any changes to the size.  I also did not recall ever converting the disk to a dynamic disk.

Now I'll fast forward to the end... there are a few resources out there for handling this situation.  The best, most concise one that I found is here.  The explanation is that a byte on the disk that identifies it as dynamic or basic has become corrupt somehow.  The HxD disk editor can be used to see the value and even make a change to it.  Be careful, though, because you can really mess things up if you aren't careful.

According to the above instructions the trick is to look at sector 0 location 1C2.  For dynamic disks this value should be 42.  For basic disks the value should be 07.  In my case the value was 07 but Disk Management was showing the disk type as dynamic.  The instructions in the link above say to only make a change if the value in 1C2 is 42 (change it to 07), so this did not fit my situation.  I did notice that the value just below it in the HxD window was 42 (location 1D2).  I decided to give it a try, so I changed the 1D2 location from 42 to 07 (to match the value in 1C2) and then my server booted just fine.

So, based on my experience I'll add that it's important for the 1C2 and 1D2 values to match.  Of course it's possible that this isn't applicable in all cases.

Sunday, July 10, 2011

Transferring a blog from Typepad to Blogger

I am sometimes asked to work on technology stuff around the house.  Surprise, surprise.  Today my wife asked me to help her transfer her blog from Typepad to Blogger/Blogspot.  I haven't fooled with blogging at all except for once before when there was some trouble with getting her Typepad blog started.  I only recall that is was a lot harder than I thought I should have been.  Lots of scripting, Linux/Web server stuff... I don't know how non-IT types get it done, as it was a real challenge for me.  Well, today I had another challenge on my hands.

She is adventurous enough to have taken the task as far as she could take it.  She was at a point where she had exported her Typepad blog posts (in an .mht file) and was trying to download the Google blog converter to convert that file to a Moveable Type file (.mt) so that the blog posts could be imported into Blogger.  Seems pretty simple, but there were several challenges.

The download file from Google's blog converter was a .gz file, and the computer where my wife blogs had no program to handle that type of archive.  I downloaded a 40-day trial of  WinRAR to handle this task, and then extracted the folder structure from the Google download file and stored it in a temporary location on the computer.  I then set about trying to use the converter.

The converter has sparse documentation but I did find a .\lib folder that has some batch files in it.  I used the one called movabletype2blogger.bat but it had errors.  Turns out I had to download and install Python (I used version 2.7).  I still received errors because the paths in the bat file were all wrong.  I pretty much hardcoded all the variable paths that the file's author had tried to make.  Here is the batch file that finally worked for me.  Note that I had installed Python into its default folder, \python27.

set PYTHONPATH=c:\python27
set BASEPATH=c:\temp\google-blog-converters-r89
c:\python27\python "%BASEPATH%\src\movabletype2blogger\" %1

I continued to receive errors until I renamed the Typepad file from .mht to .mt. 

The command that I finally used was movabletype2blogger run form a Command prompt, of course.  (I had to navigate to the C:\temp\google-blog-converters-r89\bin folder, first).

This produced several seconds worth of scrolling text down the computer screen because the script output was to "stdout", so I simply redirected the output to a file, like this:

movabletype2blogger > import-to-google.xml

A quick look at the .xml file showed that the file contained blog posts.  Success!  Seems like I'd almost be finished at this point, but no... the .xml file produced some mysterious error message with no explanation when I tried to import it into Blogger.  After some trial and error I was able to pare down the .xml file to a single post and did import it successfully.  To do so I opened a copy of the .xml file in notepad and searched for "ns0:entry" (for the beginning of a post) and "/ns0:entry" (for the end of a post).  I had to leave "</ns0:feed>" at the bottom, but I found the first "/ns0:entry" and deleted everything between it and the the "/ns0:feed" tag.  I then proceeded to use the same process to import additional posts, one at a time at first -- then several at a time.  At one point near the end of the 120+ posts the imports began failing.  I finally determined that the export from Typepad or the conversion process had placed all the comments (where people had commented on the blog posts) at the end of the .xml file, and these would not import. 

So after all that my wife's blog was up and running, but no comments from her Typepad blog were brought over.  The blog's pictures still pointed to her Typepad blog, so she had to re-point those to a different location for the pictures before she took down that blog.  There were also some minor formatting quirks that she had to work on (extra line breaks and such), but those were simply aesthetic.

So, with all that blog "piping" experience I thought I'd start up a blog and write about the experience.  Let me know if this helps you!

What this is all about

I'm a technology guy.  I sometimes tackle challenges or learn things that might be beneficial to others.  This blog is my attempt to share some of my experiences with you, in case you might have run into the same issues.  I'll keep the information here to my professional / technology life.

I'm on LinkedIn.