Summary
This article describes some limitations in accessing certain MFCOM calls with Citrix Presentation Server 4.5 and provides an example of a virtual channel class defined in the Microsoft .NET Framework.
Download
VSSDKNET Wrapper
MFCOM limitations on Citrix Presentation Server 4.5
Presentation Server 4.5 introduces many security improvements over the previous versions. These improvements are designed to make the product more secure against potential attacks. One such improvement is the restriction on accessing certain virtual channel-related calls. These calls are limited not only to Citrix administrators, but also to the system administrators.
The security restrictions are implemented in IMA and many other server components. Relaxing the security restrictions on certain MFCOM calls is not only difficult to implement, it also makes the security access inconsistent.
Although accessing MFCOM requires Citrix administrator privileges, additionally requiring Windows system administrator privileges may not be desirable for certain applications, particularly legacy applications that use MFCOM's virtual channel functionality. These applications no longer work on Presentation Server 4.5 if the user does not have both Windows and Citrix system administrator privileges.
Using WFAPI virtual channel calls
The WinFrame Application Programming Interface (WFAPI) is the only alternative to using MFCOM in writing server-side virtual channel applications. WFAPI calls are not subject to the security restrictions imposed and the virtual channel calls can be accessed by regular users.
Virtual channel .NET wrapper
One of the advantages of using MFCOM is that it provides a good object model for virtual channels. Another advantage is that users can make MFCOM calls in .NET.
The zip file attached to this article contains the implementation of a simple .NET virtual channel class. It allows the users of this class to read and write virtual channel data. The class is implemented using the .NET platform invoke technology, which allows the managed code to access WFAPI virtual channel functions.
Interested users can browse the project files by opening the vcnet.sln file, which includes two projects. The vcnet project contains a VirtualChannel.cs file, which contains definitions of the used WFAPI functions, structures used by the calls, and the methods that implement WFVirtualChannelRead, WFVirtualChannelWrite, and WFVirtualChannelQuery functions. The virtual channel open and close calls are implemented in the class constructor and destructor, thus hidden from the end user.
Additional equality operators and data conversion methods are defined for all the structs so that they can be accessed easily.
Note: In this implementation, the assembly can only be used to access the virtual channels on a local server. Remote access is implemented, although that can be easily extended by allowing a remote server name to be specified when opening a virtual channel.
Rewriting of the VCSDK VDPING example
To illustrate the use of the VirtualChannel class, one of the Virtual Channel Software Development Kit (VCSDK) examples, VDPING, has been rewritten completely in managed code. The implementation is in the VdPing project of the vcnet solution.
Other VCSDK examples (VDMIX and VDOVER) may be converted to using .NET similarly. For the most part, it involves only properly defining and implementing the structs used to communicate with the client side.
Note: The client-side module does not need to change.
Extend to other WFAPI calls
The other WFAPI calls can be wrapped in .NET in a similar way. Some methods may be grouped in some classes. For example, it makes sense to define a session class for session- related calls.
The following steps should be taken to wrap the other WFAPI calls:
1. Define the WFAPI calls in the UnsafeNativeMethods class. Pay attention to the function signatures to ensure that they are properly defined with the appropriate data types.
2. Define the structs used by some of the calls. Implement the equality operators and the methods that convert the structs to and from byte arrays.
3. Define a Session class for session methods. Other classes (for example, Event) may also be defined.
4. Implement the methods. Be careful with the manipulation of the unmanaged memory. Most of the time, the buffers must be allocated and freed explicitly.
5. Port some of the existing WFAPI examples to .NET to test the implementatio
