1

I am trying to change the Terminal Services settings programmaticly. I learned that you must use tsuserex.dll. Being c# i ran tsuserex through tlbimp and created TSUSEREXLib.dll then registered it with regasm. I got it working and wrote a framework program with it as a prof of concept. However today after I made some changes when I run my program I get the error

Unable to cast COM object of type 'System.__ComObject' to interface type 'TSUSEREXLib.IADsTSUserEx'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{C4930E79-2989-4462-8A60-2FCF2F2955EF}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).

it thows the exception on the line

IADsTSUserEx iad = (IADsTSUserEx)((DirectoryEntry)user.GetUnderlyingObject()).NativeObject;

This exact line worked fine in the test project. I know user is a valid UserPrincipal, Googleing I found this is usually just needs the dll re-registered, but even after unloading and reloading it it still will not work. What am I missing to cause my dll to stop working.

Community
  • 1
  • 1
Scott Chamberlain
  • 124,994
  • 33
  • 282
  • 431

4 Answers4

3

I know this is an old thread but since I had trouble recently finding all the required steps to get the Terminal Services components working on Windows 7, I wanted to share what I found. I think the steps below are more reliable than copying the tsuserex.dll from a server and trying to register it.

From what I understand, on any operating system you need Remote Server Administration Tools (RSAT) installed in order to modify Terminal Services attributes of a user account programmatically. On some versions of Windows this requires a download. But on Windows 7, RSAT is already installed.

But you may need to enable it using the configuration options in Control Panel (appwiz.cpl). Under "Turn Windows features on or off" goto "Remote Server Administration Tools" then ensure that "Remote Desktop Services Tools" is checked.

After I did this (and rebooted) I was able to use the components from tsuserex.dll via PowerShell (e.g., Set-QADUser -Identity testUser -TsHomeDirectory "c:\tshome"), and by adding a reference in Visual Studio 2010 (to "tsexusrm 1.0 Type Library").

Shannon Wagner
  • 361
  • 7
  • 25
0

Visual Studio Build Setting „Platform target“ disable=> “Prefer 32-bit” solve the Problem.

Kruljac Marijan
  • 3
  • 3
0

You almost certainly need to re-register your TLB on the target machine. What likely happened is you have your assembly, interface or type GUID not hard coded in the application and hence it's changed on every rebuild. So after rebuilding and deploying your type no longer matches up with the previously registered TLB.

JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • I am running it localy and getting this error message. and I have already re-registered the TLB and still get the message. Where would I hard code the GUID in the TLB creation process? – Scott Chamberlain Jan 15 '10 at 21:16
  • @Scott, try looking in the registry for references to your DLL's name and removing them manually, then re-register. – JaredPar Jan 15 '10 at 21:18
  • @JaredPar, I removed all entries in the regrestry for both the DLL's name and and refrences to the GUID, I am still getting the same error. – Scott Chamberlain Jan 15 '10 at 22:11
0

The correct answer is that I am a idiot for not reliseing that my build environment did change. I moved to a new workstaion that was windows 7 corprate instead of server 2003 when i started on the project. Win7 corp does not have tsuserex.dll in its system.

Scott Chamberlain
  • 124,994
  • 33
  • 282
  • 431
  • 1
    And please watch out for 32bit & 64bit versions of the dll. I copied the wrong version from a win 2008 server to my 64 bit Win7 Workstation and had "lots of fun" getting ComExceptions, although every compiled just fine. – hoetz May 06 '11 at 14:29