A bit of relaxed late-night admin from the comfort of the big cushy chair. 
Here is a brand new Lenovo Thinkpad X200 that has been running on a single charge for over 6 hours now, non stop (ultra low power mode). I am connected into work via our Citrix access gateway, logged into an admin desktop on Citrx, and am in fact rolling out a Citrix server remotely.
On the right of the screen is the big RES Wisdom job that runs the installation script. As you can see the entire process is hands-off. On the left is the console of the server, connected via the ILO. I dont need to do anything on the desktop, I just monitor it there and it gives me something to watch.
Tonight and this weekend, we are upgrading our Livelink document management system.
Tomorrow is also “Sinterklaas”, and it is traditional to send eachother lame poems as part of it.
So here is mine to all the users, to get them to log out on time:
Sint en Piet zaten te bedenken
Dat pakjesavond er is voor geschenken
Weet je wat het NOB in het schoentje vindt?
Een NECTS Release 1.2.1 met de groeten van Sint
Zo’n update door te voeren kost heel veel duiten
Daarom vraagt Piet aan iedereen om zo dadelijk af te sluiten
Zo hoeven de IT-ers niet lang te wachten
Om jullie Livelink pijn te helpen verzachten
Dus gaarne zo spoedig mogelijk af te loggen
Zodat het systeem dadelijk niet zal ontploffen!
Een voorspoedige reis naar huis, en wat betreft pakjesavond: geniet!
Heel veel groeten van de Sint en van Piet.
Sent over Citrix to all logged-in users:
As many before us, we ran into the following error in Virtual Center, when we tried to P-to-V a server:
“multiple connections to a server or shared resource by the same user”
This is not an uncommon error, and you might recognise it from other scenarios that involve remotely connecting to a Windows host.
I found quite a few posts that mentioned this problem, even a mention in the release notes of VMWare Converter itself, and an VMware knowledge base article, and they go something like this:
An Inter-Process Communication (IPC) named-pipe network connection is already open from the local Windows Redirector to the remote host with different credentials than you are specifying in Converter. The Windows Redirector does not allow IPC connections with multiple different credentials from the same user session. This restriction also applies to mapped network drives as they are also a type of named-pipe connection.To ensure the Converter agent connection succeeds, perform the following actions on the computer running Converter:
Note: This disconnects any mapped drives to the remote host.
So we tried all the above, but to no avail. Try as we may, from both our admin workstations, aswell as on the Virtual Center server itself, we could not get it to run.
In the end, my collegue tried to run the task using the IP adress of the server, itstead of its hostname!
That did the trick! But don’t ask me why! I suspect it has something to with the named-pipe actually being named differently when you do this.
Tags: error, multiple connections, virtual center, vmware, vmware converter
:p
Sometimes, a rogue printer driver entry gets left behind in your printer list. Sometimes, you cant delete it. Somtimes its even a duplicate of a printer that already exists, perhaps with a slightly different queue name.
Various message sources, like here suggest breaking network connection with the printer in question may be needed before windows “releases” the print queue so it can be deleted.
But what if the printer in question no longer exists at all?
This seems to occur under different circumstances, but one that is often suggestion is it can happen when printer mappings are added to a user profile using scripting.
The suggested solution in this case seems to be to run the following command:
rundll32 printui.dll, PrintUIEntry /gd \\server\printername
I ran into this problem on our Citrix farm.
Here we had 2 print queues for the same printer, the top one being incorrect, but impossible to delete:
\\srv-prt-01\prt052.nob.local
\\srv-prt-01\prt052
I isolated one of the servers so I could play with it without any users on it.
I made sure all scripted mappings to both the old and new queue where disabled.
I even deleted the queue on the server
I tried first disconnecting the printer physically, then trying to delete the errant queue. This did not work.
I tried the rundll32 command, no dice either.
The next step was the more drastic one. I logged onto the desktop of the Citrix server with ILO, disabled the network card, rebooted, and low and behold, I was able to remove the queue.
But when I logged into the server again as a test user, the driver had returned. Even with our scripting turned off, the queues actually deleted on the print server, the queue still appeared for my test user on the Citrix server.
This could only mean the entry was stuck in the user profile.
And indeed, there it was, under HKLU\<user-sid>\Printers\Connections
I deleted the errant entry, and I never saw the queue again, at least not for that particular user!
I wonder how often this happens. I was suprised to not have come across something about the user registry hive when googling this problem.
Now I have to see what I am going to do about all the other users that have this entry. Perhaps it would be better practice to actually delete this entire set of keys when they log out, every time.
The printers get mapped by our logon system anyway when they log in again. It might help keep their printer list a little cleaner in future.
Tags: driver, HKLU, mapping, printer, queue, registry, windows
Recent Comments