XenServer: Join A Domain.
xe pool-enable-external-auth auth-type=AD service-name=<domain.com> config:user=<username> config:pass=<password>
xe pool-enable-external-auth auth-type=AD service-name=<domain.com> config:user=<username> config:pass=<password>
xe pif-list
This will return the list of network connections currently seen, if you only see one (if adding a second card), or do not see the right one (eth#) for however many NIC's you have in the machine then proceed to scan for it.
xe host-list
xe pif-scan host-uuid=<host uuid>
Now check again.
xe pif-list
Unless there is a problem this should be all you need, now you should be able to see the NIC in XenCenter and XSConsole.
xe pif-list host-name-label=<hostname> management=true
xe pif-param-set uuid=<uuid> other-config:domain=domain.com
reboot
hostname -d -v
Should show the search domains at the bottom.
Alternatively:
cat /etc/resolv.conf
If you get this error when trying to double click Word documents do the following, this was taken from the App-V Forums, can't find the original author:
In the console goto File Type Associations.
Find the .doc association and right click it, then click Properties.
Click Advanced.
Click "&Open" and then click edit on the right.
Change the parameters to: /n /dde
Check Use DDE.
Change DDE Message to: [FileOpen("%1")]
Change DDE Application to: winword
Change DDE Topic to: system
Hit OK.
This should apply the same changes to .docx but check it to make sure.
If you are using Office 2010 on Win7x64 you've pobably already seen the joys of getting it sequenced correctly. Well the headaches extend down the line. And poorly written plugins are the biggest issue I've seen so far.
In this case it is the Cisco IronPort plugin for Outlook that allows users to flag messages as spam or not in conjunction with the Cisco spam filter backend.
Nearest I can tell the problem lies in the fact that if you want FULL functionality from Office 2010 you have to use the 32-bit version, the ADK doesn't have full support for the 64-bit version. And due to...it being microsoft I guess...the only way to get it working is to sequence on Win7x86. Well when you go to sequence the IronPort plugin it does NOT translate over well AT ALL. Which is fair enough, there is a reason why they suggest sequencing on the same arch/level/os as your target machines. And sequencing it on Win7x64 doesn't work because your copy of office wasn't sequenced like that.
Making matters worse Cisco is AWFUL about error messages and logs. The error message you get when launching Outlook is literally just a message that tells you to contact your admin. The admin is instructed to run the diagnostic tool, which is fine but the registry errors I got in particular look something like this:
Trying to read registry information.
Result OK.
Failed to read registry information: Outlook.Addin.Cisco
Windows.Registry.Location does not exist.
Could they have told you exactly WHAT key they tried to read? Or exactly WHAT key they couldn't find? Of course. Do they? No.
So the fact that EVERYONE using outlook gets this plugin finally convinced me to bump it to the category I am LOATHE to bump things to..."sequenced with office"
Another app with this problem is Communicator 2007. So now my patches for Office, Communicator and IronPort are now all tied to one another...but at least it works...
The alternative it to mail a brick to Cisco and ask them to politely describe what the hell is missing, or the next one doesn't come FedEx. ;p (That's the two day old migraine talking, don't actually mail bricks...it's bad for your carbon footprint.)
Elevate a command prompt and do the following
Now take the Win7 install media and extract it locally, there will be a "boot" folder under wherever you extracted it, go back to your elevated command prompt and type: <pathtobootfolder>\bootsect.exe /nt60 $:
$: is the drive letter assigned to your thumbdrive during the preparation stage.
You should now have a bootable, installable, USB thumb drive.
If you've used App-V for very long at all chances are you've discovered that it doesn't really handle applications that need admin rights with UAC prompting very well.
There are two problems, the first is the AppCompat layer, it doesn't except arguments, so you CAN right click the shortcut for an application and set it to run as admin, thinking it will run "sfttray.exe" "Application Name 1.0" as admin, but in reality it only sees sfttray.exe, meaning you just set ALL your applications to RunAsAdmin. Which if locked down now means only administrators can run appv apps, or, if you have admin rights, you've just mooted the entire point of UAC and may as well just turn it off.
The second problem is, App-V was not built with ANY real intelligence when it comes to elevation. They say it's a "design choice" but then say a design choice is their way of saying they know it can't do it yet but they didn't have enough time to fix it. I guess they were too busy introducing bugs and useless UI fixes in SP1 to bother.
So given their two "workarounds" are, well, ones flat out not a workaround because you'd have to be an idiot to do it (and even they say only do it for testing, which...makes it not a workaround) and the other involes installing one of the WORST "powertoys" I've ever used (including over 30 files you need to push locally to the machine) I finally came up with what I would call an ACTUAL workaround.
Ready?
Copy sfttray.exe, rename it to sfttrayad.exe, point your shortcut for the App-V Console or whatever else to IT and not sfttray.exe, and set the compatability to Run As Administrator.
Now anything you know needs admin rights to run simply modify the shortcut, adding "ad" to the end of "sfttray" and tada...no more right click runas, no more shift+right click if it's on your taskbar.
Dear App-V guys. I don't even really care if you can't figure out a better solution, but surely even implementing something like this (where a flag in the admin console tells the client to point to a different copy of sfttray if you specify it as needing admin rights) is better than NOTHING.
So trying to boot off PXE on a XenServer VM seems to VERY frequently cause problems. I finally figured out how to work around the issue.
When booting from network (you probably need to bump network boot up above the "will not boot" line) hit Ctrl+B when it says to bring up the gPXE command line. Then do the following.
Note that you NEED to know the location where the images are stored and be able to see them so you know what file to point it to. If you can't figure it out, start pointing it to every .com you can find lol.
Also beware that on reboot these settings are NOT saved. Which is annoying. But hey, it beats flat out not being able to RIS.
You can use wusa <path to .msu> /quiet to install the update, then run this powershell script to enable all the features for RSAT.
&$env:systemroot\SysNative\dism.exe /Online /Enable-Feature:IIS-WebServerRole&$env:systemroot\SysNative\dism.exe /Online /Enable-Feature:IIS-WebServerManagementTools&$env:systemroot\SysNative\dism.exe /Online /Enable-Feature:IIS-IIS6ManagementCompatibility&$env:systemroot\SysNative\dism.exe /Online /Enable-Feature:IIS-Metabase&$env:systemroot\SysNative\dism.exe /Online /Enable-Feature:IIS-LegacySnapIn&$env:systemroot\SysNative\dism.exe /online /get-features | Select-String -Pattern remote* | %{$Exec = "dism.exe /online /enable-feature /featurename:RemoteServerAdministrationTools /featurename:" + ($_).ToString().Replace('Feature Name : ',''); Invoke-expression $Exec}&$env:systemroot\SysNative\dism.exe /Online /Enable-Feature:RemoteServerAdministrationTools-Roles-AD-DS-AdministrativeCenter
via Xenophane
Update: If you don't want the SMTP Server Tools installed you can ditch the dism lines that turn on all the IIS components and just run the /get-features line and the AdminCenter line after it. The reason for running Admin Center again is because it shows up in the list before its pre-req so it fails to enable the first time around, so you just enable it again and viola...
Update 2: I modified the script and had the WiseScript call it because SCCM kinda blows. I had to modify the script because calling it with WiseScript tripped the issue with DISM reverting to the x86 version, which errors out, so now it's pointing to the SysNative version (another brilliant idea from microsoft, I guess calling it dism64 or defaulting to x64 and not x86 or about fifty other options made too much sense and therefor had to go).
Don't ask me why I'm posting this here, Service Manager is one of the worst written things I've ever used, and I use App-V. No surprise it's written in Java. The developers need to be drawn and quartered.
-silent
-options-record <answer file>
-options <answer file>
For a silent default install just use -silent, for one that uses the answer file, just do -option AND -silent.
Ugh.
A quick How-To: on adding a RAID array as an SR in XenServer, the version I personally used was 5.6 but 5.5 and 5.0 should be identical.
Steps to create an SR in a Xenserver.
Locate the RAID array partition.
cat /proc/partitions
This returns a list of all partitions, find the RAID array and make note of it's name (sda, sdb, sdx, etc.).
Now locate the disk-id.
ll /dev/disk/by-id
This lists disk ID's, look for the ID that matches the partition name from the previous step.
Obtain the XenServer host-uuid, we need this because we need to specify the XenServer as the host to attach the SR to in the next step.
xe host-list
Create the SR.
xe sr-create content-type=user device-config:device=/dev/<sdx> host-uuid=<host-uuid> name-label=”RAID Array” shared=false type=lvm
You should now be able to see (and use) your RAID array in XenCenter.
A powershell script to suite two applications in the local OSD cache, for testing interaction and hotfixing a user if need be. At some point I may update it to accept arguments.
$offcGuid = "22C76228-3DF0-48DD-853C-77FDC955CC86" $sPath = "RTSPS://%SFT_SOFTGRIDSERVER%:322/Power Pivot for Excel.sft" $sGuid = "F5B20FA7-E437-4E03-885B-3D5B67F3DC22" $sParam = "" $sFile = "%CSIDL_PROGRAM_FILES%\Microsoft Analysis Services\AS Excel Client\10\Microsoft.AnalysisServices.AtomLauncher.exe" $sGuard = "POWPIVOT.1\osguard.cp" $sSize = "323267785" $sMand = "FALSE" $path = "C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\OSD Cache\" $dir = Get-ChildItem $path $list = $dir | where {$_.extension -eq ".osd"} foreach ($i in $list) { [xml] $xml = gc ($path + $i) if($xml.SOFTPKG.IMPLEMENTATION.CODEBASE.GUID -eq $offcGuid) { $final = ($path + $i) [xml] $excel = gc $final $newitem = $excel.CreateElement("CODEBASE") $newitem.SetAttribute("HREF", $sPath) $newitem.SetAttribute("GUID", $sGuid) $newitem.SetAttribute("PARAMETERS", $sParam) $newitem.SetAttribute("FILENAME", $sFile) $newitem.SetAttribute("SYSGUARDFILE", $sGuard) $newitem.SetAttribute("SIZE", $sSize) $newitem.SetAttribute("MANDATORY", $sMand) $excel.SOFTPKG.IMPLEMENTATION.VIRTUALENV.DEPENDENCIES.AppendChild($newitem) $excel.Save($final) } }
If you use Office Communicator 2007 you are bound to find something useful in that list.
Client Log File Location:
C:\ProgramData\Microsoft\Application Virtualization Client\sftlog.txt
Icon Cache:
C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\Icon Cache
OSD Cache:
C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\OSD Cache
Machine AppFS Storage:
C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\AppFS Storage
User AppFS Non-Roaming:
C:\Users\fulbripd\AppData\Local\SoftGrid Client
User AppFS Roaming:
C:\Users\fulbripd\AppData\Roaming\SoftGrid Client
Why would I need or want to know these locations?
Well, the OSD cache is important if you want to, say, suite something in-place (i.e. suite two applications together just on the machine to test integration or to hotfix someone until you can update it on the backend), the icon cache is useful for determining whether or not Windows Icon database is corrupt or if the icons provided by App-V are corrupt. The log file location is...hopefully obvious.
My personal favorite however is the AppFS locations.
I wouldn't worry to much about WHAT files are in there. But these locations are where the user changes that are saved "to the bubble" are stored. They are broken down into basically three types. Changes that are global (say, an HKLM key), changes that only apply to the user but shouldn't roam (say, an HKCU key with the machine name in it), and changes that are user specific and are ok to roam (say, an .ini file with preferences stored in it).
Where knowing this comes in handy is when, for whatever reason, the client decides to not truly clear the AppFS when you tell it to. I've had more than one instance of clearing multiple times, clearing after log off, after reboot, and the client just isn't capable of deleting it, maybe something random locked the folder, maybe something got corrupted, either way the only solution at that point is to find the folder for the app you want to clear and manually delete it in all three locations.
Likewise if you ONLY want to clear a certain segment of the AppFS for a package you can do so manually as opposed to the client which does not give you any options.
And example of what the folders look like it: CTXAPPS-3E12E23B-2C95-4986
You will notice after looking at a few that they tend to have the 8.3 folder name you used when you sequenced them, followed by a semi-GUID (semi because the first block is user generated and not random, therefor not TRULY globally unique).
Quick note that seems to be escaping a few people.
In App-V Standalone Server you can set access permissions (i.e.: who recieves the application) at two levels, the Application Group (folder) level, or at the Application level (each individual program or shortcut INSIDE the package).
There is inheritence and it SHOULD always inheret folder level permissions, but unless you have a specific need to grant or deny access to a single appication without a sequence you should avoid setting access permissions below the folder level.
Have an App-V app that creates shortcuts you don't want? You have two options.
First Option:
In the sequencer, on the Customize Applications screen, you can expand the application, right-click on Edit Shortcut and uncheck everything. This will leave the application (and thus the .osd, which is needed to suite, say a plug-ing, with another sequence) intact but not display a shortcut.
Second Option:
If you use the App-V standalone server you can modify, anytime, on the fly, what shortcuts are displayed and where they are. For instance, our users wanted Office Communicator 2007 to run on startup, I simply went into the console and added a shortcut to %CSIDL_STARTUP%
PS Kill:
Stop-Process -processname notepad.exe
PS List:
Get-Process * | sort ProcessName
There are a few possible problems here but I find the most common is that the OSD is not pointing to either the right location, deployment method, or both.
Check the OSD's (or go in via the Sequencer if you wish, but that will typically generate a new version of the .sft, though I haven't tried in 4.6SP1, maybe that was one of the two things they got right) to ensure the correct method and location are specified.
Remember that typically speaking it will be something like:
":<port>/<appsubfolder>/<pathtosft>"
And seldom if ever:
":<port>/<pathtosft>"
If you have an App-V app that complains about elevation but SHOULDN'T really need it, try adding this:
<ENVIRONMENT VARIABLE="__COMPAT_LAYER">RunAsInvoker</ENVIRONMENT>
That goes inside the <IMPLEMENTATION><VIRTUALENV><ENVLIST> tag. As always, location inside the tag doesn't matter, just that it's inside the tag. You can also use the same trick to set "process level" environment variables. Say, adding something to the PATH variable.
Retrieving and setting Environment variables in Powershell.
Get:
.\ Get-ChildItem Env:
$Env:Temp
Set:
Process Level:
$Env:TEMP = "C:\Windows\Temp"
User/Machine Level:
[Environment]::SetEnvironmentVariable("Temp", "Test value.", "User")
Environment]::SetEnvironmentVariable("Temp", "Test value.", "Machine")
Delete:
[Environment]::SetEnvironmentVariable("Temp", $null, "User")