Copy Paste between remote desktop and local computer

In order to allow copy-paste functionality across remote desktop, ensure that the following services are running on the local computer and the remote system
1. Network DDE DSDM
2. Network DDE
3. ClipBook

Network Dynamic Data Exchange (DDE) is a technology that enables applications on different Windows computers to dynamically share data. This sharing is effected via communications channels called trusted shares, which are managed by a service called the Network DDE Agent. By design, processes on the local machine can levy requests upon the Network DDE Agent, including ones that indicate what application should be run in conjunction with a particular trusted share. The DSDM(Distributed Share Database Manager), manages the shared DDE(Dynamic Data Exchange) network conversations (from shares like: \\computername\ndde$).

However, a vulnerability exists because the Network DDE Agent runs using the Local System security context and processes all requests using this context, rather than that of the user. This would give an attacker an opportunity to cause the Network DDE Agent to run code of her choice in Local System context, as a means of gaining complete control over the local machine.

Managing remote connections without tsadmin

Most of those who have worked on remote terminals using the Remote Desktop Connection utility would have faced the problem of not being able to connect because of disconnected session. The solution usually is to use the tsadmin utility to close the sessions. However, while working on a Windows XP, this is not available.

However, Windows XP does provide the following to perform this action
- qwinsta (Query Windows Station)
qwinsta /server:servername allows the user to view the sessions and obtain the session ids on a remote windows host
- rwinsta (Reset Windows Station)
rwinsta sessionid /server:servername

Deploying a Windows 2003 cluster using VMWare

I was once assigned to test an application which was to be deployed on a clustered Windows 2003 environment. The budget at that time did not allow us the luxury of having dedicated hardware for the clustering so we had to workaround the situation by using a virtual environment. I was able to find this wonderful article by Roudy Bob on Setting Up A Windows Server 2003 Cluster in VS 2005 - Part I but was not able to perform the same using VMWare.
Whenever a virtual machine was powered on, it used to lock the vmdk files thus not allowing the second node in the clustered to be powered. After some searching on various blogs, I was able to work around this problem by modifying the vmx file of the virtual machine to include the following statements (without the comments)

scsi0:sharedbus="virtual" //this shares the whole scsi bus 0
scsi0:0.shared="true" //this shares the scsi0 port 0
disk.locking="false" //for disk.