My Remote Desktop Session Hosts (RDSHs) have pieces of the vWorkspace client installed. vWorkspace is a product from Quest Software (well, it was a product from Provision Networks, but Quest Software took them over) and is a software package meant to extend RDS with extra broker functionality, web access, its own hosted application virtualization (like RemoteApp), and so forth. It’s an alternative to Citrix’ XenDesktop/XenApp.
On those servers I see the following warning event logged in the System event log after a startup of the system:
Event ID: 1
Description: Provision Networks Termianl Services started!
rdpdd.dll (version 6.1.7601.17514) is not supported.
File Signature: 6.1.7601.17514.F3919A6179F54F548B8BBCC35191CADC1
Task Category: None
First of all, I’m quite sure the word “Termianl” in the description is actually a typo and of course it must have been “Terminal”. J Secondly, the warning definitely brings up a problem related to Terminal Services (well, it’s Remote Desktop Services (RDS) in my case) and Provision Networks (well, that’s Quest Software now), actually meaning vWorkspace). But more to the point now, what is “pnterm”? Well, “pn” is probably “Provision Networks”, while “term” definitely stands for “Terminal Services”. Translated: it’s a vWorkspace DLL and related to RDS. But what exactly is it? Where precisely is it used?
In this context “pnterm” is a registered System event log source. Let’s take a look at that source: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\System\pnterm. Under this key we see a named value EventMessageFile with the value “%SystemRoot%\System32\pnterm.dll” (without the quotes). This DLL, pnterm.dll, takes care of the event messaging to the System event log. Lookup this value could be interesting to get to know DLL names, path names,… that could help us identify what “pnterm” is.
In this case we don’t know anything more that’s “really helpful” L What we could do is to find out if there are processes out there using this DLL too (in many cases the DLL that contains the “real” functionality is also the DLL that logs events). Start Process Explorer, wait a “minute” (so PE can collect information) and then search for “pnterm.dll” (CTRL+F and enter this string in the dialog that pops up). The following screenshot gives us a positive result.
It seems there is 1 process that has loaded pnterm.dll and that’s the svchost.exe process containing 1 specific Windows service, i.e. “Remote Desktop Services”.
If we search through the registry for “pnterm.dll” we also find pnterm.dll in the value (%SystemRoot%\System32\pnterm.dll) for the named value ServiceDll in the key HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\TermService\Parameters. “TermService” is the technical name of the “Remote Desktop Services” Windows service. This means this service loads pnterm.dll as configured through the registry, which is confirmed by what we saw in Process Explorer. By default this is termsrv.dll, but vWorkspace changed this to its own pnterm.dll. When the service loads pnterm.dll will still load termserv.dll as we can in figure 5.
Now let’s go to the DLL in Windows Explorer and take a look at its properties on the Details tab:
The DLL is called the “Quest Terminal Server Service”. The version I have installed is 7.1.301.358 (7.1.301.368 is the latest 7.1 version available and you can get there by installing Update_ 166018; the “latest-latest” vWorkspace version though is 7.5).
Ok, so we have a System event logged by a vWorkspace DLL loaded in the RDS service. First the event says “Provision Networks Terminal Services” has been started (remember, the event is logged at boot time), but I’m not sure how that should be interpreted: has the whole RDS service been started or only this component (as the DLL describes itself as a “Terminal Server Service” too…)? Anyway, it doesn’t really matter.
Then the event says rdpdd.dll 6.1.7601.17514 isn’t supported. You should know rdpdd.dll implements the RDPDD driver for the RDPDD device (RDPDD = Remote Desktop Protocol Display Driver) (the RDPDD device is actually the RDPCDD device). This “device” represents the display for remote sessions and converts the display information into a format suitable for transmission over the network to the client. So what is pnterm.dll doing with rdpdd.dll? Well, if we search the registry for “rdpdd.dll” we find the key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Provision Networks\Terminal Server\rdpdd.dll. My RDSHs run WS08 R2 SP1 (and thus 64 bit), so the registry key for vWorkspace is HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Provision Networks (yes, it’s still the old company’s name J). One key lower is “Terminal Server”, containing vWorkspace settings for the actual Terminal Server (or RDSH). After some research (thank you, Bing) and logical thinking I found that every lower key represents a file pnterm.dll needs to do something with. And yes, that seems the case with “rdpdd.dll” too! For every such file there is a set of sub-keys representing a certain version and named with the file signature of that file. For example, one version is 6.1.7600.16385 with file signature 6.1.7600.16385.B25089C5ADF6413B92A2FC687FC201701, so the key is HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Provision Networks\Terminal Server\rdpdd.dll\6.1.7600.16385.B25089C5ADF6413B92A2FC687FC201701. This means pnterm.dll can do something with rdpdd.dll 6.1.7600.16385.
The version of rdpdd.dll I have on my servers though is 6.1.7601.17514, but I don’t find a sub-key for this version… It seems pnterm.dll tries to hook something on rdpdd.dll (for adding graphics acceleration functionality) and it needs very precise information about how to do this, being different for each version. So pnterm.dll doesn’t find information on how to hook something on our rdpdd.dll and that’s why the warning has been logged! As pnterm.dll doesn’t find the right key, “our version is not supported”.
Sight… Why is our rdpdd.dll not “supported”? Well, I was wondering if vWorkspace 7.1 was actually supporting WS08R2 SP1 (6.1.7601)… The last version “supported” by our pnterm.dll is 6.1.7601 (which includes WS08R2 RTM). So I looked up the System Requirements document for version 7.0 and 7.2 (I didn’t find the documentation for 7.1) and didn’t find WS08R2 SP1 being mentioned explicitly as supported, while WS08R2 was mentioned and older OS versions with (!) SP level too… But hey, version 7.5 seems to officially support WS08R2 SP1 (http://us-downloads.quest.com/Repository/support.quest.com/vWorkspace/7.5/Documentation/vWorkspaceSystemRequirements_7.5.pdf)! So it seems the vWorkspace version is too old for our OS and that’s why the most recent version of rdpdd.dll isn’t “registered” under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Provision Networks\Terminal Server\rdpdd.dll, causing the warning to be logged at boot time. The only solution is to upgrade vWorkspace to version 7.5.
Side note 1: in our case it seems vWorkspace 7.1 is working decently on our WS08R2 SP1 RDSHs, although we only use the minimal core functionality plus Print-IT (the universal print driver solution from vWorkspace). I suppose we miss some graphics acceleration functionality (well, we don’t seem to miss it that bad! J), although I don’t have a clue which particular features it includes (we have disabled some things like EOP, so perhaps we actually do not miss anything at all in practice). Secondly, we get the warning, which isn’t a clean thing to have in your log. And thirdly, we have already experienced a server crash caused by another vWorkspace component, so perhaps this doesn’t occur at all with version 7.5. All this seems pretty OK for not being supported officially, but of course I cannot exclude other (minor) problems being caused because of this, even if I don’t have a proof of that. It’s always better to use products/versions that officially support your environment.
Side note 2: it could be that a registry entry for the rdpdd.dll hook would work with vWorkspace 7.1. But of course you are never sure for 100% if it works the way it should (even if you don’t see problematic symptoms at first sight) and of course you’re still not doing supported things. Also, it’s probably not that easy to find out how the entry should look like. I you can’t upgrade to 7.5, perhaps you could ask Quest Software if such an entry would help and how it should look like. Anyway, we are not asking so, because we are preparing for a move to Citrix XenDesktop! J