Event ID 4105 TerminalServices-Licensing

Het logboek stond redelijk vol met warning meldingen  (Event ID 4105)

 

 

Het probleem zat in:

 

If the user accounts existed before the domain was upgraded to Windows Server 2003, the Terminal Server License Servers group might be missing in the discretionary access control list (DACL) of the user objects in Active Directory directory service. Or, the group is in the DACL, but the group does not have permissions to update the Terminal Services Licensing information for the user account.

 

Oplossing was om de rechten goed te zetten dmv dsacls:

 

 

De rechten kun je ook Op een bepaalde OU kun je delegation of control uitvoeren om het probleem op te lossen:

 

 

 

 

 

Resultaat is in beide gevallen hetzelfde:

 

 

 

Zie ook:

 

http://support.microsoft.com/kb/2030310

 

 

 

Installatie van Adobe Reader op Remote Desktop Session Host (Terminal Server)

Download de laatste MSI versie en MSP patches van: ftp://ftp.adobe.com/pub/adobe/reader/win/10.x/ naar (zeg) C:\Adobe\Downloads

(Voor meer informatie: http://kb2.adobe.com/cps/888/cpsid_88814.html)

Maak nu een Administrative Installation Point (AIP):

msiexec /a c:\Adobe\Downloads\AdbeRdr1010_nl_NL.msi

Geef tijdens de installatie als netwerklocatie de locatie op waarvan uit je later de Adobe Reader installatie wilt starten.

Persoonlijk geef ik de voorkeur aan een DFSRoot hiervoor (dus bijvb: \\domein.local\DFSRoot\SDP\AdobeX)

In deze map worden vervolgens een aantal bestanden en mappen geplaatst:

Werk deze installatie nu bij met de laatste patch:

msiexec /a "\\domein.local\DFSRoot\SDP\AdobeX\AdbeRdr1010_nl_NL.msi" /p "C:\Adobe\Downloads\AdbeRdrUpd1012.msp"

Download nu de executable (AdbeRdr1010_nl_NL.exe) van bovengenoemde FTP locatie (staat bij de MSI) en installeer deze met de volgende parameters:

C:\Adobe\Downloads\AdbeRdr1010_nl_NL.exe -nos_o"C:\Adobe" -nos_ne

Deze kun je namelijk met de Adobe Customization Wizard (ACW) bewerken. De MSI die al gedownload was is daarvoor te beperkt.

De MST die je aan de hand van deze uitgepakte executable maakt kun je gebruiken voor de AIP.

IE performance test

Wil je weten hoe Internet Explorer presteert?

Wat handig kan zijn om de performance te bekijken in RDP sessies.

Met onderstaande test kun je zien hoe IE presteert. Wijzig het aantal vissen en kijk naar de FPS et.

http://ie.microsoft.com/testdrive/Performance/FishIETank/

Overige testen:

http://ie.microsoft.com/testdrive/Views/SiteMap/

Disable8dot3 on Terminal Server Farm

Hieronder een verhaal waarom je 8dot3 moet uitzetten op een Terminal Server Farm (indien mogelijk).

Currenty i’m on the way to deploy a Windows Server 2008 R2 terminal server farm.
One server is already up and running productive and the other is one step before going online. I work a lot of with GPO’s and user roaming profiles, to ensure to have exactly the same configuration on the new server for all users. Also i use control panel restrictions to display only neccessary .CPL’s to the user.

And one special control panel addin, what is shipped with the MS Office suite ML32CFG.CPL (responsilbe for configuring MS Outlook MAPI Profile), i discovered how important it is, to ensure that applications have to be installed in the same order as on the other terminal servers.
Why, you may ask….because, of the 8dot3-names (8.3) and the windows internal file/path handling. In some cases the OS calls an an application it tries to use the 8dot3 path / name.

The control panel addin on the new server was registered successfully during the installation, and i could open it. But if i tried to open the CPL with my test user, what is already using the saved roaming profile, the addin would not open. Also the icon in the control panel window was different against to the other server.

So what happend? With Sysinternals Process Moinitor (PROCMON.EXE) I did a little bit research on both servers, and found out that the 8dot3 name of the MS Office path between both servers is different because i didn’t keep in mind the order, how i installed the applications on the new TS.

Server 1: (C:PROGRA~2\MICROS~1\Office12\MLCFG32.CPL)

Server 2: (C:PROGRA~2\MICROS~2\Office12\MLCFG32.CPL)

To solve the problem, i had no chance uninstall the application what occupies the 8dot3 name, uninstall office and reinstall office and the other application again. After reinstalling MS Office suite, the right 8dot3 name was assigned tho the new installation.

Zie voor extra info ook mijn blog over NTFS Hacks:
http://salfischberger.blogspot.com/2011/10/diverse-tips-hacks-betreft-filesystem.html