Tag Archives: WindowsServer

Remote Desktop Gateway

In order to connect to the Remote Desktop service on centrally managed servers from off campus, as well as some more sensitive servers from on campus, you need to use the Remote Desktop Gateway feature.

For the current Remote Desktop Client on Windows, you can configure this option by going to the Advanced Options tab, and then click the Settings button.

Remote Desktop Gateway settings

On the RD Gateway Server Settings window that open, select the second option, Use these RD Gateway server settings. The server name is rdgateway.uvm.edu, and chose the Ask for password option.

Click OK, and you should be able to connect using the RD Gateway service. For more information about RD Gateway, see What is a Remote Desktop Gateway server?

 

 

Who’s logged into Server 2012?

I’m severely disappointed that Microsoft has removed from Server 2012 the tools required for managing and configuring Remote Desktop for Administration. On previous server editions, I’ve used the Remote Desktop Services Manager to troubleshoot colleagues and delegated administrators’ access issues. We’ve also had situations where the SSL certificate used to identify the server and to encrypt traffic has expired and needed some intervention.

Some discussion on Mark Minasi’s support forum indicates that some of this functionality is returning in Server 2012 R2. In the meantime, and until all our servers get upgraded, I’ll be using a combination of the Task Manager (which shows user sessions),

Displaying user logon sessions in Server 2012 Task manager

Displaying user logon sessions in Server 2012 Task manager

and Process Explorer, which can show the username and start time for process.

VSS diagnostics

For the past eight month, I’ve been working with EMC and Microsoft to diagnose a problem. Several time a month, during the backup of our primary Windows 2008 R2 file server, all the VSS shadow copies get deleted for the volume containing all our shared departmental directories.

This has two major effects. First, it means that our clients no longer can recover files using the Previous Versions feature of Windows. Second, it casts significant doubt on the validity of the backups performed at that time, which EMC NetWorker reports as having completed successfully.

We have been unable to find a technical solution to the shadow copy loss, so we will be reconfiguring our storage and shared directories to accommodate the limitations of NetWorker. In the meantime, I want to note a few of resources that have been helpful in diagnosing problems with VSS (it will be easier to find them here than in my pile o’ email):

Volume Shadow Copy Service (TechNet)

Volume Shadow Copy Service (MSDN)

Registry Keys and Values for Backup and Restore

How to enable the Volume Shadow Copy service’s debug tracing features in Microsoft Windows Server 2003 and Windows 2008

Using Tracing Tools with VSS

Custom event log queries

I really like the newer event log model on Windows 2008 family, and the flexibility of the XML events and the queries that makes possible.

Recently, I started noticing a quiet failure of a scheduled task. The Task Scheduler thinks that the task completed successfully, though the executable called by the task action returned an error code of 3:

Task Scheduler successfully completed task “\ShareVol_Sync” , instance “{92ac3257-f52d-47eb-9a3a-ce02c5196bbd}” , action “diskshadow.exe” with return code 3.

I wanted to see how long this have been going on, so I switched from the Task Scheduler console to Eventlog Viewer, and navigated to the Operational log under “Applications and Services Logs”- Microsoft – Windows – TaskScheduler.

I started by using the using the Filter Current log dialog to select events with Event ID 201, but this included all “Action completed” events for all tasks. So I looked at the XML view for one of the events for the task I was researching. The event includes a data value named “ActionName” with the value “diskshadow.exe” that should allow me to find all the relevant events.

eventvwr-evt-xml

Next, I needed to refine my filter to look for this value in the events. I opened the Filter Current log dialog again, and switched to the XML tab, then checked the Edit query manually option. You get a scary warning about not being able to use the GUI again, but that only applies to the current filter. Be bold: click OK.

Next, I edited the query, following examples from this excellent Ask the Directory Services Team blog post. The query is junk the between the select tags. Originally, the query was simply:

*[System[(EventID=201)]]

To that, I added the following:

and
*[EventData[Data[@Name=’ActionName’] and (Data=’diskshadow.exe’)]]

So that the whole query looks like this:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-TaskScheduler/Operational">
    <Select Path="Microsoft-Windows-TaskScheduler/Operational">
      *[System[(EventID=201)]]
       and
      *[EventData[Data[@Name='ActionName'] and (Data='diskshadow.exe')]]
    </Select>
  </Query>
</QueryList>

Now event viewer shows me only the “Action Completed” events for the diskshadow.exe command, and I can see exactly when the behavior changed.

Note that you can save use the query XML with PowerShell’s Get-WinEvent commandlet’s -filterXML parameter [See an example]. You can also use the Save Filter to Custom View option to make this view persistent.

I routinely review Windows’ Event logs during diagnostics and troubleshooting. I find the ability to query those logs for specific data is an indispensable technique. No more dumping to CSV and running findstr! I hope you find it helpful, too.

Script: Shadow Copy Report

We use EMC NetWorker for our enterprise backup solution. Since we migrated our primary file server from a NetApp filer to a native Windows server, we’ve been having a recurring problem with all the Shadow Copies for a volume getting deleted. There are strong indications that the problem is related to the NetWorker backups.

As we have been working on this issue with EMC (since the first week in January!), I wrote a script to tell me two things each morning; how many snapshots exist for each volume, and what VSS errors were logged, if any.

I thought someone might find it useful, so I’ve posted it as a separate page (the script doesn’t fit nicely in the column on the blog).

PowerShell Script: chksnap.ps1

Custom FSRM notification script

I’ve been working on a script to generate an informative message to users when they exceed quota thresholds on our file server. The features of the File Server Resource Manager (FSRM) provides a variety of useful variables that can be plugged into an automated email. However, we have found that it’s often very useful to provide more information about the kind of files that a user is storing, something akin to the output of the very useful and free utility WinDirStat.

I’ve made progress on the script that generates the email. However, I’ve run into a snarl in trying to configure the quota notification to run the script. The script runs just fine from a command prompt, even from a command prompt running as the Local System account. But when I trigger an FSRM event that should drive the script, I get an error in the Application Log:

 

Continue reading

Monday – June 1

It’s June! Cold and rainy?! Gah!!

On the list for today:

  • AD Domain Services on Server 2008 and Operations Manager 2007

Operations Manager – verifying current version

Post regarding installing hotfixes on the Management Server using SetupUpdateOM.exe. Never heard of it before. Doesn’t exist on my system. Perhaps it’s part of OPs Mgr 2007 R2?

I decided that the KB956184 patch looked the most promising. Because the installation involved manual replacement of msi files in the AgentManagement folder on the Root Management Server, I could back-out the changes if things went South.

After renaming the original 64-bit OOMADs.msi files and replacing them (AMD64 and IA64 versions) with the ones from the hotfix. Then I used the OpsMgr console to uninstall the agent from my four Windows server 2008 AMD64 domain controllers, one at a time. For each I verified that the new AD MP Helper Object was installed, checking appwiz and Program Files\Common. Then I checked the Operations Manager Event Log. This time, there were no errors running the DSDiscovery script. Health explorer on each DC is now clean. Yes!!!

The only lingering issue is the presence of five errors in the event logs on each DC, complaining about the inability to locate Performance Counters for DirectoryServices: “DS Search sub-operations/sec”, “LDAP Client Sessions”, “LDAP Searches/sec”, “LDAP UDP operations/sec”, and “LDAP Writes/sec”. I verified that I could see these counters within Performance Monitor on the DC. This thread in the OpsMgr Management Pack newsgroup seems germane, though the Live login isn’t working for me at the moment.

Managed to chime in on that thread. We’ll see if anything useful comes of it.

Opsmgr Friday

Having successfully deployed some agents to some recalcitrant hosts, I’m now trying to address a false positive issue on a DC. I’m getting an error regarding “AD Op Master Respone [sic] Monitor”. The host has a recurring error:

AD Op Master Response : The script ‘AD Op Master Response’ failed to create object ‘McActiveDir.ActiveDirectory’.  This is an unexpected error.
The error returned was: ‘ActiveX component can’t create object’ (0x1AD)

This led me to a blog post suggesting that the AD Helper Object needed to be installed. So I look in the OpsMgr host’s AgentManagement location and find the msi. When I tried to install that msi package, I received an error that the “this installation package is not supported by this processor type.” The host is running AMD64 Windows, and the file came from the AMD64 part of the AgentManagement tree.

I checked the list of installed apps on another x64 DC, and saw that the “System CenterManagement Pack Helper Objects” item had been installed. So I tried repairing the agent install from within Ops Manager. Error persists.

Checking the hotfixes required to make Ops Manager agent work on Server 2008, and they are missing. Stay tuned…

UPDATE:

Applied the hotfixes and still no love. I did dig into the eventlog, and saw that it appear the ADDiscover script failed in some way. I tried running the script manually (using the arguments from the eventlog entry), but it still failed. I fell back to google and found the following promising KB article: Alerts are issued from the MOM Active Directory Management Pack after you install an Operations Manager 2007 SP1 agent over a MOM 2005 agent on a domain controller that is running a 64-bit version of Windows.

Now this KB article describes a set of circumstances that don’t match my situation. I didn’t install MOM 2005 agent and then the OpsMgr 2007 agent on the same host. This system was built from the ground up with server 2008 x64 and Operations Manager 2007 was deployed here way before server 2008. However, the constellation of symptoms and architecture issues make it sound interesting.

Just found Kevin Holman’s blog and his list of hotfixes. I must go read about these and OpsMgr SP2 before doing anything drastic. Nothing like breaking the server late on a Friday…

Tuesday – May 5

Spurred by some recent traffic on the Windows-HiEd list, I have looked into the Windows Update process on some of our Server 2008 Core systems. The thread was specifically with regard to KB article 953631, and that some folks have found that it installs repeatedly on Server Core instances and blocks other updates.

In examining the event logs on a couple of our Server Core system, I found that the update is indeed re-installing repeatedly, but it doesn’t appear to be blocking other updates.

First, I ran the systeminfo command to display the installed updates. KB953631 was not listed. I grabbed the WUA_SearchDownloadInstall.vbs script from Microsoft (I renamed it to Get-WindowsUpdates.vbs, in keeping with the sound PowerShell naming conventions). When I ran the script, it found and downloaded two updates, the KB953631 update in question, and KB955430. I confirmed that I wanted the updates installed, and the first update installed successfully, but the second failed (my initial searches didn’t explain the 0x800f082f error code). I reproduced the same behavior on another server core instance.

I tried rebooting the host, and running the Get-WindowsUpdates.vbs script again, and this time both updates installed successfully. (yes, the KB953631 update installed again). I reproduced this success on the other host as well.

So it appears that in our environment, the KB953631 update isn’t blocking other updates. I’ll confirm this after Patch Tuesday.

At the very end of the KB article is the following:

Note for WSUS administrators
If you approve this update for deployment in a WSUS environment, be aware that after you run the update, it will not be reported as "Installed." The update itself is not installed on client computers. The update scans for missing files and replaces them as appropriate. If a computer requires a missing file, the 953631 update will be reported as "Needed.”

Also, Server Core is not mentioned specifically in the list of affected operating systems. It might be worth asking what the expected correct behavior should be in this situation.

In my investigating, I also found an article in the Scripting Center the describes a PowerShell approach to manipulating Windows Updates. This might be nice when Server 2008 R2 is availabel and .NET and PowerShell are included, or other update-wrangling tasks.