Checking the Onboard Administrator revealed that “IPL Device” Boot ordre was missing the PXE NIC 1 method. However, the “One Time Boot From” still had it listed (didnt work tho)

And the bios configuration was identical to rest of my blades. Testing with both NIC1/NIC2 as PXE bootable didnt change anything.

After a little search at google, i found this article descripting smiliar problem – only problem is the date of the article/bios update (i got a newer bios date)

I decided to try the latest bios update that was available for 465c. Still no luck..

After calling HP support, it turns out that one of the reasons for this problem could be a difference between the blades servers bios rom, iLO firmware versions

as in, if your blade servers in the enclosure contains different versions(eg. you recently installed a new blade, which has a newer iLO firmware version) it could

cause problems for the onboard administrator. And since i recently had installed a new blade, it would make a little sense.

HP advised me to first upgrade all the blades (link) followed by (link) which upgrades the Onboard administrator to 2.60

In my case, the problem was solved already by upgrading the one servers rom and ilo firmware as the only thing. but i’m still going to upgade everything as planned

just in case.

It seems that if you use the quick access toolbar in eg. Word, those settings will be appended to C:\Users\john\AppData\Local\Microsoft\Office\word.qat (etc)

which is local and not roaming – and therefore wont be updated on your UserProfiles network share.

as far as google told me, theres no fancy gpo or registry setting that can change the path of where to store the qat files.

and redirecting the Applications\… folder can work, but often runs into conflicts with other apps or updates that don’t seem to like
it ‘moved’, so it’s side effects can outweigh its benefits.

So, the easiest way to solve this little problem, is to use the Logon/Logoff gpo (User Configuration – Policies – Windows Settings – Scripts (Logon/Logoff)

In the Logoff Properties, add your newly created saveqat.bat which contains the following

SET target=%APPDATA%\Microsoft\Office
SET source=%USERPROFILE%\Local Settings\Application Data\Microsoft\Office

IF NOT EXIST “%target%” MD “%target%”

copy “%source%\*.qat” “%target%”

And in the Logon properties, add loadqat.bat

SET source=%APPDATA%\Microsoft\Office
SET target=%USERPROFILE%\Local Settings\Application Data\Microsoft\Office

IF NOT EXIST “%target%” MD “%target%”

copy “%source%\*.qat” “%target%”

Now your probem should be solved – your qat files will be copied along with your roaming profile, and copied back, and the user settings will be preserved.

ive been all the way around from pressing multiple keys at boot up, clicking the left mouse button, etc etc etc.

and since im using Windows 7 (go hate on me mac fanboys) i can´t use various os x ways.

anyway, when trying to eject your cd/dvd from windows, it pops up with a message i forgot all about (some weird error) and its just impossible to eject it.

i actually had to dissamble the dvd and pull it out manually one time where i had exchanged the drive with a brand new intel ssd (pressing F12 and holding it down while turning on the mac worked, but after i accidently inserted the leopard dvd, it refused afterwards and ignored F12)

Anyway, heres the little trick i found out about. – use ImgBurn!

simply press the eject button, and magic will happen. the fun thing about this, is if you select Tools – Drive – Eject – it will fail the same way if it was done though Windows.

anyway, if anyone got an explanation on this, please feel free to share your knowledge.

and if i get the time, i will update it later on.

In my previous post, i talked about running the ica client in the userlogon script, making it possible to open files from explorer with a streamed application.

in this case, it would be nice to use Pass-Though Authentication so the user dont get prompted twice for logon credentials.

so i started playing around with it – actually spent way to many hours on something that should be pretty straight forward.

one of the first things one should do, is to reinstall the ica client as admin with the correct options like

CitrixOnlinePluginFull.exe /silent SERVER_LOCATION=”http://10.20.30.40:81″ ADDLOCAL=”ICA_Client,PN_Agent,SSON” ENABLE_SSON=”Yes”

so heres a short list of stuff to check (feel free to comment if theres more)

• Add the ica client adminstrative template for the domain and enabled pass-though & Local username password
• Checked the reg key for NetworkProvider/Order (Citrix single-SignOn needs to be in top)
• Checked that pass-though was enabled and set to default on the XenWeb servers under PNAgent service site/Config.xml
• Check that SSOnUserSetting=On in “UserProfiles\userxxx\AppData\Roaming\ICAClient\APPSRV.ini” and not Off

In my case none of the above worked, and a few days after i found this article. with a hotfix that should solve the problem

Pass-through authentication is not available when accessing a published application from within a published desktop on XenApp 5.0 servers. The user is required to provide valid credentials to launch a session within the desktop session even when pass-through authentication is enabled in the XenApp Plugin.

Another possible workaround is to enable GPO – Computer Configuration\Administrative Templates\System\Credentials Delegation

“Allow Delegating Default Credentials” – set it to Enable, leave “Concatenate OS defaults with input above” checked, and click “Show…”

1) Explorer.exe is published for your users to use (browsing shared folders, private folders, etc)

2) Main part of Office 2007 is installed locally on your golden XenApp image (win2k8)

3) A few applications like Visio, OneNote, Project are profiled and streamed to server

Now when a user launches Explorer, and tries to open a Visio project, it appears as Visio is not installed (no file associations) – now i think about it, it would probably also

be a problem if the user tries to open an attachment from outlook.

This happends cause its a streamed to server application, and cant be seen by the xenapp server it self,unless its actually logged on to a profile with the appropriate access to the published resources)

as far as i can tell, theres not yet any smart way to solve this problem, a temporary solution until Citrix figures something out is to run the ICA client a second time when

the user logs on (letting it run on the xenapp server)

for this to work theres a few things we need to do.

in your UserLogon.cmd script for your AD users, add

Cmd /C “C:\Program Files (x86)\Citrix\ICA Client\pnagent.exe”

just remember to change the path if its located somewhere else.’

On your XenApp servers add the following registry entries to prevent the ica client from hanging on the server after user logs off

Path: HKLM\System\CurrentControlSet\Control\Citrix\wfshell\TWI
Value Name: LogoffCheckSysModules
Type: REG_SZ
String: pnamain.exe

Now fire up Streaming Profiler and get ready to edit your already profiled applications.

After its opened, browse to (Target Properties – Applications – Modify)

Under “Command line parameters – Optional) Add 2 asterisks (**) and save your profile again.

in AMC open up all your published profiled applications and go to Content redirection

here you need to check “Show all available file types for this application” And Select all the extensions you want to use.

Now, when the user logs on, he will see the ica client again, and after logging on, he should be able to browse and open documents though Explorer with streamed applications.

It started out with the some users complaining about their danish published office applications switched to using US keyboard layout

and naturally i started testing (logged on with same user account) and found no issues at all. We tested a bit, playing around with the language bar

and the local region settings, and we found out that on the airbooks, on windows 7, it had 2 keyboard layouts installed (da-dk, and danish-apple)

and after removing it, setting danish as the default, it seemed to have solved the problem.

a week later, it all started over again (cant remember why) and this time, it would always default back to US keyboard (only way to shift was using ALT+SHIFT) since i’ve hidden the language bar.

but every time the user logged out of and profile was saved – it went straight back to the old us layout.

This was only related to the machines running Mac with Windows installed, and after a bit of research i found out that its actually defaulting back to us layout

cause the terminal server allows the remote user keyboard to decide what layout to use. – ignoring the users last used setting.

its actually a nice feature, but of course in this situation i cant live with it – and i see this as a temporary solution until i figure out another way of dealing with it.

1.    On the terminal server (XenApp server), click Start, click Run, type regedit, and then click OK.
2.    Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout
3.    On the Edit menu, click Add Value, and then add the following registry information:

Value name: IgnoreRemoteKeyboardLayout
Data type: REG_DWORD
Value data: 1

4. Quit Registry Editor.

Next time the user logs on – make the changes to use native language (danish i my case) and logs off again, the setting will be saved to the users profile

and remembered next time the user logs on.

and i was met with the error message above.

theres probably multiple answers to solving this problem. some say that you need to run it as administrator permissions (doh) and some want you to change permissions on the

registry vmware path.

what almost worked for me was deleting the reg entry “HKLM\Software\VMware Inc” and then just retrying with the installation. i however, had to delete the entry

“HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VMware, Inc.” for it to work.

so heres the basic setup (this does not include signing up your gtalk account)

Procotol: XMPP/Gtalk

Username: Dennis
Domain: annoying.dk
Resource: Empty
Password: mypassword (god,love,sex…)
Local alias (nickname)

Under Advance, keep it simple.

No checkmarks required in the first 3 boxes.

Connect port: 5222
Connect server: talk.google.com

the funny thing was that it was actually working great, running it from the shell. but setting it up in crontab – it just didnt run the script fully.

after playing around with the script, setting it to -x and using tee i could see that the script stopped working half way – really nothing special that was about to be executed.

Checking ps aux, right after the script was executed, i saw..

root 25294 0.0 0.0 0 0 ? Z 18:05 0:00 [cron] <defunct>

after spending too much time on google, i really never found anything specific. but something in my script was fucking up cron..

after a tip from a friend (google) i did the following

root@foo:/# env |grep SHELL
SHELL=/bin/bash

and from crontab the same (just redirected the output to a file)

this showed that CRON uses “SH” and not “BASH” when running. however, this shouldnt really matter since its defined in my script (#!/bin/bash)

never the less, i tried to change my script to use SH instead of BASH, and to my surprise, it stopped the exact same place..

i guess theres a way to change cron to use bash instead of SH, but it could probably screw up more things – which i dont need right now.

so adding /bin/bash infront of the script i want to execute in cron

* * * * * /bin/bash /root/myscript.sh

seems to solve the problem.

i decided to use an old disk.

I inserted the installation disc, followed the installation instructions, formatted the disks, created the partitions manually, everything went just fine.

After installing and updating the system,and installing the raid drivers (earlier post) it was now time to install mdadm and lvm2, to get my data back on track.

it updated the files in /boot/ without any errors, all just perfect..until

I rebooted the system, and got some nasty error (sorry, cant remember which, but it was same second grub started)

No matter what i did, i was unable to get the system up and running again, someting fucked it for good.

anyhow, since the whole installation didnt take more than 15minutes, i just decided to do it all over again.

(repeat this post 12 times… 3 hours later..)

it seems like the disks i borrowed from a friend, was part of an old mdadm raid-5, and since the raid information is stored in the superblocks, it didnt really matter how many times we format the disks – installing mdadm and rebooting the system, would make mdadm recognize the disk and so some naughty stuff to it

the solution for me was to boot an ubuntu live cd, set up pppoeconf, install mdadm and do a

mdadm –zero-superblock /dev/sdx (be carefull, and be sure its the right disks your fucking with)

it takes a sec, and now the disks is ready for use again.