I recently had to troubleshoot a Problem where the Customer told me that sometimes all the Sessions on a XenApp 6 Host got disconnected and the Users then had to reconnect to their XenApp Sessions to continue working.

After a little Research (thanks to Google!) I narrowed it down to the the Group Policy Refresh. Not always, but sometimes, when doing an "gpupdate /force" on a XenApp Host all User Sessions got disconnected. With this in mind I found the following Microsoft Knowledgebase Article: http://support.microsoft.com/kb/2083411

The customer in fact used the Group Policy Option "Allow users to connect remotely using Terminal Services" to enable Remote Desktop and force a specific Remote Desktop Security Setting on all of his XenApp Servers.

After setting the Registry Key "fDenyTSConnection" to 0 (as suggested in the Microsoft KB Article) the sudden disconnects were gone.

Problem solved! :)

I recently worked in a Project where we deployed XenApp 6.5 Workers via Citrix Provisioning Services 6.0 (PVS) onto a vSphere 5 Cluster and ran into a Problem regarding the PXE Boot. We knew that PVS 6.0 is currently not supported with vSphere 5, but the customer wanted to use his vSphere 5 Cluster nonetheless.

Everytime we rebooted a Target Device, running an XenApp 6.5 Worker, it would reboot and then hang on the PXE Boot in a Screen like this:

When we powered the VM completely off and then started the VM again (cold reboot) the PXE Boot worked without a Problem. The Problem would only occur when rebooting the VM without completely shutting it down before (warm reboot).

To fix the Problem we enabled the "Interrupt safe mode" Option in the Bootsptrap Configuration of our Provisioning Servers:

And voilà: Rebooting the XenApp 6.5 Workers on a vSphere 5 Host/Cluster now works as expected.

UPDATE: Citrix published an official Support Article (with the same Solution) regarding the Bootstrap Configuration in an vSphere 5 Enviroment: http://support.citrix.com/article/CTX131993

 

I recently had a customer where on all XenApp 6 Workers an Error with the EventID 602 from the Source PrintService was logged in the EventViewer during the User Logon Process. This only seemed to happen when using Session-based Printers in the XenApp Session.

After a bit of Research I found a Microsoft KnowledgeBase Article with an "private" Hotfix which fixed the Problem: http://support.microsoft.com/kb/2457866

Note: This Hotfix is NOT included in the Windows Server 2008 R2 Service Pack 1. I have only tested this on XenApp 6, but this should also apply to XenApp 6.5 Systems.

Recently I have been struggeling to successfully stream the Adobe Acrobat 9 via Citrix Application Streaming into Pooled Standard Mode XenDesktop Machines (or Hosted VDI Desktops as Citrix likes to call them).

The Adobe FlexNET Licensing Service was very uncooperative to say the least, so after countless tries I gave up on streaming Adobe Acrobat 9 and gave the newer Adobe Acrobat X a shot - with success! With Adobe Acrobat X there is no FlexNET Licensing Service anymore and the Licensing is handled somehow internally and not via a service.

Prerequisites:

• Offline Plug-in 6.0.2 or later (includes a Bugfix regarding the Adobe Acrobat Distiller)
• Streaming Profiler 6.0.2 or later
• AppHubWhiteList Registry Entry set correctly (not really needed for Acrobat X)

Create a Transforms File (.mst) for Adobe Acrobat X:

• Customize your Adobe Acrobat X Installation via the Adobe Customization Wizard X.
  • Disable Update Functionality
  • Disable Registration and EULA Prompts
  • Disable Acrobat.com Functions
  • ...

Save your Customizations as a Transforms (.mst) file and place it in the folder where the AcroStan.msi is located. In the following Screenshots you can see the Steps and Customizations I choose to create the .mst file. I choose to name the Transforms file Streaming.mst.

Create the Adobe Acrobat X Profile Package:

All the following Screenshots are taken from a German Streaming Profiler although all Menu Items should be the same in the English Version of the Streaming Profiler. If you have questions or problems understanding the Screenshots, feel free to leave a comment.

• Now it's time to fire up your Streaming Profiler on your Profiling Machine and choose a Name for the Profile.

• Don't select "User Updates" (or whatever it's called in the English Streaming Profiler Version).

• Select "Advanced Installation" and click "Next".

•  Now select "Run install program or command line script" and click "Next" again.

• At the "Choose Installer" dialog, click "Browse" and locate the AcroStan.msi in the Adobe Acrobat X Installation Folder. In the "Command line parameters (optional)" field put TRANSFORMS=Streaming.mst /qn and then click "Next".

PLEASE NOTE: If you named and/or placed your .mst file other than Streaming.mst (and next to the AcroStan.msi) you have to adjust the command line parameter accordingly.

• Click "Run Installer" and wait for the completion of the installation (check the Task Manager for running msiexec.exe processes). After completion click "Next".

• At the "Select Next Step" dialog, select "Perform additional Installations", and then click "Next".

• Now select "Edit Registry" and continue with "Next".

• Click "Start Windows Registry Editor" and the Registry Editor should open up.

• Now browse to "HKLM\Software\Adobe\Acrobat Distiller\10.0\PrinterName\" and change the existing Default Key from "Adobe PDF" to "Microsoft XPS Document Writer". 

NOTE: You have to choose a Printer Name that exists on your Target Device(s) (every Printer will work - doesn't matter what Driver/Printer it is) where you want to stream the Adobe Acrobat X to. If there is no Printer with the exact same Name (like in the Default Key) on the Target Device the Adobe Acrobat Distiller will fail when trying to convert Microsoft Office Documents into PDF Files. I choose the XPS Document Writer because it is on every XenDesktop I wanted to stream the Acrobat X to. You can find more Infos in an offical Citrix Blogpost here.

• When finished close the Registry Editor and click "Next". 

• At the "Select Next Step"  dialog, select "Finish Installations", and then click "Next".

• At the "Run Application" dialog, do not run any Application and just continue with "Next".

•  Click "Next" through the remaining dialogs (unless additional settings are required for your environment), and then click "Finish" on the "Build Profile" screen.

Done! You can now save and then publish the Profile.

Ich darf mich nun inzwischen offiziell "Certified CAcert Assurer" nennen. Yay! :-) Nachdem ich mich zwischenzeitlich bei 3 Personen habe "assuren" lassen und somit die 100 benötigten Assurance Punkte bei CAcert angesammelt habe, als auch die "CAcert Assurer Certification" erfolgreich abgelegt habe, kann ich nun auch offiziel andere Personen für CAcert "assuren". Mehr Infos zu dem ganzen Verfahren gibts z. b. hier. Wer also im Raum Mannheim für CAcert "assured" werden möchte kann sich gerne bei mir melden. (siehe "Contact")

Da ich nun schon mehrfach gefragt wurde ob ich denn eine Dialplan.xml sowie XMLDefault.cnf.xml für ein Cisco 7970G im Zusammenspiel mit der Fritz!Box habe, poste ich hier mal meine Konfigurationen für jedermann zur freien Verfügung.

Für eine Beispiel SEPMAC.cnf.xml solltet ihr meinen vorherigen Blogpost beachten. Die Dateien zum Download findet ihr nachfolgend:

Read the rest of this post »

Neues Jahr, (endlich) ein neuer Blogeintrag. Zwischen den Jahren habe ich meinen Asterisk auf einem vServer abgelöst und durch den eingebauten SIP Registrar meiner Fritz!Box ersetzt. Somit betreibe ich nun mein Cisco 7970G an der Fritz!Box selbst.

Auf der Suche nach einer passenden SEPMAC.cnf.xml für das Cisco 7070G hatte ich jedoch Anfangs einige Schwierigkeiten eine passende zu finden da die meisten SEPMAC.cnf.xml für das ältere Model 7960 sind und daher nicht mit dem 7970 kompatibel sind.

Lange Rede, kurzer Sinn... für alle die eine passende SEPMAC.cnf.xml für ein Cisco 7970G im Zusammenspiel mit einer Fritz!Box suchen gibt es nachfolgend meine Beispielkonfig.

Read the rest of this post »

Ich wärme mal einen Post aus meinem alten Blog wieder auf... Eine einfache Methode, per VBScript einen Dell Servicetag auszulesen und zwar ohne zusätzliche Programme bietet folgendes Script:

strComputer = "."

Set objWMIService = GetObject("winmgmts:" & _
"{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

For Each objSMBIOS in objWMIService.ExecQuery("Select * from Win32_SystemEnclosure")
Wscript.Echo "Serial Number: " & objSMBIOS.SerialNumber
Next

 

Da ich letzte Woche einige Schwierigkeiten bei der Einrichtung des Firefox Bookmark Addons Xmarks BYOS Edition im Zusammenspiel mit dem WebDAV Verzeichnis meines Hosters schokokeks.org (sehr zu empfehlen übrigens!) hatte, hier ein kleiner Tipp. Nach dem erstellen des WebDAV Verzeichnisses per Administrationsmenü von schokokeks.org und der Konfiguration von Xmarks tauchte beim Hochladen/Synchronisieren meiner Bookmarks in der Protokolldatei von Xmarks immer wieder folgender Fehler auf:

[2009-11-19 17:48:30] >>> Callback ({status:403, errormsg:""})
[2009-11-19 17:48:30] Got a 403
[2009-11-19 17:48:30] Returned error: Verboten(403)

Die Ursache allen Übels lag an den fehlenden Rechten auf der Dateisystemebene (wie so oft). Also per SSH auf den Webserver und dort folgenden Befehle abgesetzt:

setfacl -m default:u:apache:rwx /home/<user>/websites/webdavfolder

Damit gebt ihr dem Apache Schreib-/Leserechte auf euer WebDAV Verzeichniss, ohne diese Rechte könnt ihr dort sonst nämlich keinerlei Dateien ablegen. Anschließend klappte auch die Synchronisation meiner Bookmarks mit dem WebDAV Verzeichniss einwandfrei. Update: Zwischenzeitlich wurde der WebDAV Wiki Artikel bei schokokeks.org überarbeitet und man findet die passenden Befehle auch dort.

Ich bin heute auf einen Stolperstein bei der Migration eines Office Communications Server 2007 auf R2 gestoßen, und zwar beim "Umziehen" der OCS Konfiguration von der Dömänenpartition (Standard bei der OCS 2007 Installation) in die Konfigurationspartition (empfohlen bei OCS 2007 R2) innerhalb des AD Schemas. Und zwar beim 3. Schritt (siehe auch TechNet Artikel) bei welchem man folgenden Befehl ausführt:

lcscmd /Forest /Action:ForestPrep /global:configuration

brach dieser Befehl bei mir mit einem 0x8007005 Fehler (Zugriff verweigert) ab. Letztendlich war die Ursache das meinem Administrationsaccount die Berechtigung des "Organisations-Admins" fehlte, da in die Konfigurationspartition der AD keine Domänen-Admins schreiben können (im Gegensatz zur Domänenpartition wo "Domänen-Admins" reinschreiben können).