There’s very little more annoying in a windows environment than having to go to a console of a server because some idiot has disabled remote administration on a server 2003/2000 server. I was in this situation recently and decided not to go to the console out of principle.
I wrote the following program in order to get around this issue. Its called RDPon.exe and you can get it here:
With this you can:
- Query RDP status
- Enable RDP
- Disable RDP
I have sealed it as an exe so that you can right click it and choose run as to get at your admin account easily.
A pet peeve of mine are context menu extensions… Why software vendors decide to include non optional context menu addons are besides me! A good example of this would be Adobe.
when right clicking on an office document Adobe decided “Combine supported files in acrobat” to be we all must have, fine in the wild… but not so good in a shared desktop environment.
To remove this from your Citrix environment / Desktop simply run this command:
REGSVR32 /u "C:Program FilesAdobeAcrobat 9.0Acrobat ElementsContextMenu.dll.
If you also wish to remove the New > file type associations that Adobe decide to push in, heres a script to do so:
REG DELETE HKEY_CLASSES_ROOT.xdpAcroExch.XDPDocShellNew /f
REG DELETE HKEY_CLASSES_ROOT.xdpShellNew /f
With the move to 64 bit platforms, a new dll has been put in place:
C:Program Files (x86)AdobeAcrobat 9.0Acrobat Elementscontextmenu64.dll
This dll add’s the following items to the context menu:
- Convert to Adobe PDF
- Convert to Adobe PDF and Email.
If you wish to remove these, run the following command:
REGSVR32 /u "C:Program Files (x86)AdobeAcrobat 9.0Acrobat ElementsContextMenu64.dll"
To auto install web interface sites, sitemgr.exe must be used. the below script will create a default website for XenApp services and will also create a PNAgent site.
The pre Requisits for this script are:
· Installation of IIS 6.0 +
· Installation of .net framework 3.5
· Installation of J#
· Installation of Citrix access management console framework (and web interface component).
· Installation of citrix web interface.
Configure your variables for the management servers and farm names, then save the below as a batch file:
set sitemgrdir=C:Program FilesCitrixWeb Interface5.0.1
“%sitemgrdir%”sitemgr.exe -c “WIDest=1:/Citrix/XenApp,Config=local,XMLService=%mgmtservers%,farmname=%farmname%,XMLSPort=80,WIDefaultSite=yes”‘)/?
“%sitemgrdir%”sitemgr.exe -c “PNADest=1:/Citrix/PNAgent,Config=local,XMLService=%mgmtservers%,farmname=%farmname%,XMLSPort=80″‘)/?
The script in full can be downloaded here
I was asked the following question recently when finishing our Citrix server deployment method.
We needed a script that would run on a computer as part of a sequence of scripts that would move a server from its current OU to the servers final resting place a terminal servers OU.
The below script achieved what we needed by using the computers %computername% variable to move the computer.
In our case the following apply:
·The computers name is using the variable %computername%
·The domain is domain.net
·The computers OU before the move is computers
·The OU we wish to move to is Terminal Servers
dsmove “CN=%computername%,OU=computers,DC=domain,DC=net” -d domain.net -newparent OU=”Terminal Servers”,DC=domain,DC=net
if you are unaware of the computers current OU before the move and you still wish to script the move, the following forum post will get you in the right direction.
Heres a tricky problem with Enteo, When executing a batch file enteo only gives a batch file 10 minutes to complete before moving on.
Generally speaking this is no problem as how many batch files do you run take over 10 minutes?
This problem came to light for us when enteo began causing our ESX servers to purple screen of death during the pe stage of the build, which resulted in us moving our virtual servers to a stable ESX while we rebuilt. The problem was that the ESX was so slow with all the added servers that our scripted citrix updates were taking over 10 minutes, the script continued, rebooted the server during the updates and low and behold a very sick citrix server.
The trick to get around this, and i recommend this for any batch file you run in enteo, is to create a looping if statement in the enteo script to check for a registry key. Once you have this key created run your updates then delete the key as the last line in your batch file. This will cause enteo to loop even after the 10 minutes leaving your critical updates to install without fear of being.
heres the idea for the enteo script:
execute %systemdrive%longbatchfile.bat /?
if exist regkey goto sleep
And in the batchfile create the reg key, do your work then delete it:
reg add hklmsoftwareenteo /v checkkey
reg delete hklmsoftwareenteo /v checkkey
what will happen is simple, even if the script times out, the script will carry on sleeping until the key is deleted, no matter how long it takes.
After the jump is an example of my code so you can see what we did to get around this