App-V: Excel 2010, DDE, and variations on installation type.

Here is a fun one.

If you  are like me you've had some VERY sketchy results with Office and DDE. There are several bits of information floating around about this and here is my updated current understanding of the issue.

During installation of App-V 4.6 (in this case SP1, not sure if the same applies to RTM) the following keys are written with different values based on, apparently, the type of method used to deploy the client.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\UserInterface\DDELaunchCommand

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\UserInterface\DDELaunchMSICommand

When delivered via SCCM as part of a task sequence during an SD deployment DDELaunchCommand points to sfftray.exe and not sftdde.exe, and there is a different string for the MSI launch command as well.

Strangely, taking office 2010 as an example, word used to require ADDING DDE or it would present a "problem sending command to program" error, then at some point it stopped being broken.

Then, Excel stopped working with DDE, the most common search results provided a fruitless suggestion to disable the "Ignore other applications DDE" that doesn't appear to be checked by default in 2010 anymore.

The problem with this is that stripping DDE from the FTA's for excel fixes double clicking on a file locally or on a network share, but when launching a spreadsheet via SharePoint you get an error saying '%*.xslx" could not be found.

Uninstalling and reinstalling the client WILL fix this in almost every case (just make sure to reboot after the uninstall, even if it doesn't prompt you) but the idea is to fix the client for in-production machines.

The default values for SP1 for those two keys are as follows:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\UserInterface]

"DDELaunchMSICommand"="-0Ej4Sf'k=UZDv3uJ4{IRelease_Merge_Modules>OO5hSGuIH?xoVn&wQ(Ex \"<APP>\" <DDE>"

"DDELaunchCommand"="\"C:\\Program Files (x86)\\Microsoft Application Virtualization Client\\sftdde.exe\" \"<APP>\" <DDE>"

This is from a Win7x64 machine with App-V 4.6 SP1 (no HF's applied).

Update on 2011-12-07 00:30 by Paul Fulbright

Ok, so I sadly do not have nearly enough time to really get to the bottom of this so the following is pure speculation.

I THINK the difference in this case between Excel and, say, Word is that Excel seems to be tripping a MSI self-repair check, it's blink-and-you'll-miss-it fast but I THINK the MSIDDELaunchComand not being fixed was why just changing DDELaunchCommand didn't solve the problem.

Something doesn't set right with me about that but the net result is, setting both keys correctly, works.

REALLY love to hear the excuse for why this happens.

App-V: Error 00000007

Been asked this a lot lately.

This error most likely means you have the wrong OS type specified. You can leave the supported OS blank and it will run on any platform. Which can be helpful if you have control over who gets the App-V client to begin with.

App-V: Swapping Office 2010 Streams In a Live Production Env.

I think I alluded to this problem either here or on the official forums, but there is a slight hiccup when trying to swap out new streams for something that has items that run in Startup. Namely, it doesn't work.

The problem exists because, big shock here, an oversight in the way App-V works. How it SHOULD work is, if set to refresh the server On Login, it halts software launches until it's software inventory cycle is completed and then proceeds to load whatever applications are still valid. What it ACTUALLY does is goes ahead and lets the apps launch, completes its cycle, removing the old app and importing the new one, but because the application is locked it ends up leaving the client in a state where until the NEW product is cleared it wont work.

The Scenario: Rolling out Office 2010, we don't want to be in a jam if we ever need to re-sequence Office 2010, in case a req. change occurs, or, whatever reason.

The Solution: Use SCCM to run the following commands. Note that the collection needs to contain MACHINES and not users, as it needs to perform operations regardless of machine state.

SFTMIME UNPUBLISH PACKAGE:<packagename> /GLOBAL /LOG <pathname>

SCCM reboots machine

SFTMIME DELETE PACKAGE:<packagename> /GLOBAL /LOG <pathname>

SFTMIME REFRESH SERVER<servername> /LOG <pathname>

C:\Windows\System32\timeout.exe 300

SFTMIME LOAD PACKAGE:<packagename> /LOG <pathname>

Breakdown: The initial UNPUBLISH doesn't do much, it SHOULD unpublish the package but the main problem here is that if a user is logged in, it's probably in use, this is mostly to provide SCCM an entry point to reboot the machine. You could run shutdown -r -t 1 instead and set the package to "package reboots machine" instead of "SCCM reboots machine" but honestly it feels like six of one, half a dozen of the other.

The second command DELETES the package off the machine when the computer comes back up, before a user can log in and put the package into an "in use" state.

The we refresh the server, pause for 5 minutes to make sure the refresh completes, and then load the package. The reason for this is to control the deployment. I can run this at a maint. window when I know network traffic will be light instead of waiting for monday morning and praying I don't get unlucky. This way too by the time they show up monday they shouldn't see anything. In our case AppSense will carry over their account information and settings so if the package is already cached there should be no way, other than the reboot, for the user to tell something happened.

In the case of laptop users or users who don't leave their machine on, they merely have to wait the first time they power on/connect for the SCCM package to arrive and run.

None of this is anywhere NEAR as ideal as the client being intelligent enough to not step on it's own toes, but so far it's been working. I don't anticipate this being an every day affair (hopefuly it's very rare), but we were not comfortable using it until we were sure we wouldn't be locked into using the same sequence for the lifetime of Office 2010.

Update on 2011-11-22 15:52 by Paul Fulbright

After a bit of testing it appears you MAY not need to use machines in the collection after all, as if it is working properly the machine will have received the entire package chain and once it is done rebooting should have the remainder of the advertised packages queued up to run.

App-V: SFTMIME.EXE REFRESH SERVER

SFTMIME.EXE is one of the two primary command line utilities you will find yourself using to programattically control App-V. SFTTRAY.EXE being the other.

SFTMIME's main purpose is controlling the client, as where SFTTRAY's main purpose is launching applications. It goes beyond that but in a nutshell those are their jobs.

One problem you may see with SFTMIME is a lack of response. In this instance REFRESH SERVER, when when used with /log provides no response unless there is an error. Most people go into the Client Console and refresh to see if the server status changes to "Ongoing", and if it doesn't change assume it didn't work. The only way to ensure it kicked off a refresh is to check C:\ProgramData\Microsoft\Application Virtualizaton Client\sftlog.txt

If you see it cycling in the log, you know it worked. This doesn't do wonder for programattically checking, as even looking at the modified date of sftlo.txt doesn't tell you anything other than SOMETHING happened. You have to actually parse the log file to get a clear result.

If you intend to run SFTMIME via scripts or something like SCCM don't forget to specify /LOG <pathname> otherwise if it fails, you are left to scratch your head and wonder why.

App-V: Unable To Import SFT, ERROR Code - 0000C81E

Since most of the old bugs are patched the most common cause I've seen for this is having a special character in the package name. For instance:

Notepad++ 4

C++ 2008 x86 SP1

etc. etc.

It is important to note that the sequencer will not save you from yourself. If it isn't a letter, number or period (.), don't use it. It will save you a lot of trouble in the long run.

App-V: Office 2010, The Phantom Icons.

Had a really fun occurence, sequencing Office 2010 I found when I put it into the staging environment that none of the FTA shortcuts existed.

Sadly due to project deadlines I cannot tell you WHY it suddenly opted not to capture those shortcuts, but I can give you a dirty fix.

If you have an old copy of Office 2010 sequenced with working shortcuts, copy them all over to the Icons folder under your new sequence, 99.9% chance they will all the named correctly, and your problem solved.

My suspiscion is that with Lync and UC and IronPort in the sequence, I really do think this is just approaching the limit of complexity that App-V can happen. I can sequence Office 2010 by itself in 25 minutes (including SP1 and the Aug. CU's) all day long, the slowest part is the LOCAL_INTERACTION_ALLOWED, but I can do it reliably.

With these four included? It gets VERY spotty. I can do it three times over and get three different results, one might work.

So if you don't have an old copy lying around try doing as vanilla a sequence as possible (don't worry about the local interaction or version syncing, you are just after the icons) and use them to fix your working, complex, version.

App-V: Structural Limitations.

This post is a little different, it isn't a tip, trick or solution. This is a commentary on App-V, specifically a couple of it's more irksome qualities as regards enterprise use.

The Scenario:
You have Office 2010 deployed, it's been a year, your patches are starting to accumulate, something goes wrong or a new configuration is needed (maybe you didn't include Access and now you need to). Whatever the case you are left with one real option, re-sequencing.

In and of itself this isn't a major issue, re-sequencing office (if you've done it as many times as I have) is, monotonous but not too taxing. But know you are left with a problem. How to cleanly get Office 2010 to the masses.

The Problem(s):
The first problem is the ADK, notoriously finicky, with a flat out awful installer. If you have a background in repackaging software into MSI's you will be appalled to see how kludgy it is, and how many things are hardcoded. The fact that you cannot even use a transform tells you something, and MSI's are M-S technology, see it right there in the name? M-S-I...continuing the long, not so proud, tradition of MS being one of the worst abusers of it's own technology.

They give you very little useful information about the nuts and bolts functionality of the ADK and opt instead for a birds eye view of "understanding proxies". End of the day this part of the problem SEEMS solved easily enough by changing 8 registry keys in: HKLM\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\CVH

How you change them is another story. You can try using GPO, but it is about as reliable as GPO's usually are. You can try using AppSense Env. Manager, which is only marginaly more reliable than GPO if it's in a bad mood. You can run an MSI or WiseScript or other method via SCCM, but then you are stuck waiting for it to go down to the machine and there will innevitably be issues with users who have gotten the fix and some who haven't yet, so some portion of the population will be without working proxies.

And now we get to the real problem. The pointlessness of GUID's in App-V and the lack of segregation of data.

To start with the first point, GUID's being useless, you have to understand that App-V does not store things intelligently. It relies heavily on plain text files, OSD's, SPRJ's, even SPRT's are all XML files, and that is great and fine as an open method of transfer. As a data store it's flat out awful. There is no intelligence to it, no normalization, a lot of small file parsing, they could have used the registry to better effect! And that's saying something, something bad. But the real problem lies in HOW it organizes the data, not how it transmits it.

If you've used App-V for very long at all you have undoubtedly realized that no two applications of the same name and version can be either in the App-V server or client. Why bother having this limitations when you have GUID's? You can say it's a design choice and it's subjective as to whether it was right or wrong, but the truth of the matter is, it's a needless restriction.

Take for instance Adobe applications. Oh how they love Adobe Bridge, and Extension Manager, and the oh-so-annoying Air that seems to install no matter how many boxes you tick saying not to.

If I sequence DreamWeaver, Flash Pro and Fireworks I WILL have three versions of Air, three of Extension Manager and three of Bridge. I can't sequence them seperately because a) that is a lot of added work for no reason, b) they behave horribly when attempting to make three different Adobe apps share the same suited sequence c) it adds a lot of uncharted overhead to managing App-V, someone has to write down "oh and if the user gets dreamweaver they also need Bridge, Air and ExManager" and then if one updates the others need to update.

Essentially as it is right now the datastore looks something like this:

----Root
--------Application 1
--------Application 2
--------Application 3
xxxxxxApplication 4
--------Application 4
--------Application 5

Everything is under the root, and the primary ID is the app name/version. Worse still is FTA's, where EVERY FTA controlled by any application is grouped together in one big lump. On the server it CAN be seen by application but not in an intelligent way, instead of doing it like they do in the sequencer, where it's hived out under the individual application (which is still an EPIC pain if you are trying to find out what took over a specific FTA as there is no search, you either go through the main list with thousands upon thousands of entries, or you go app by app, having the data in two places makes no sense, it's an option you use when building in a simple search ability seems, I don't know, too hard, not worth it, overlooked).

Why doesn't it look like this?

----Root
--------GUID
------------Air 1.0
----------------FTA
----------------FTA
----------------FTA
------------Bridge 1.0
----------------FTA
------------ExMgr 1.0
----------------FTA
----------------FTA
--------GUID
------------Air 1.0
----------------FTA
----------------FTA
----------------FTA
------------Bridge 1.0
----------------FTA
------------ExMgr 1.0
----------------FTA
----------------FTA

Problem solved, no conflicts, no issues...well, you didn't think we'd get off that easy did you? FTA's are the next problem. There is no way to set an applications FTA priority. For instance if I have Dreamweaver CS4 and Dreamweaver CS5 both on my machine (something App-V kindly makes doable) I have no way of telling App-V to ignore CS4's FTA's in favor of CS5's. Sure I can strip the FTA's off the machine, but unless I prevent them from refreshing (kind of a problem) the next time they refresh, back come the FTA's. I could take them off the server, but if I have some users licensed for CS4 and some for CS5 I will be leaving all the CS4 users without FTA's.

I appreciate the simplicity of App-V's console, it spares you a great many of the needlessly complicated and hidden problems of, say, SCCM, but it's a bit TOO spartan, and lacks any real sense of organization.

So lets go back to Office 2010.

Even I sequence it with a different version (say 14.0.4756.1000 instead of 14.0.4755.1000), which WILL let me have two versions of Office 2010 in App-V at the same time, I now have to change the regkeys before a person could be switched over. So if I take, say, 100 users, put them in a transition group and assign an SCCM package to run to update their registry keys, I have no way of ensuring it happens at a specific time, at best I can run it overnight and hope they all complete timely (and nobody is on a laptop off the network).

But even this doesn't work because doing this wreaks holy hell and havoc with the FTA's, the most noticeable of which are "Could not send command to program" and a lot of missing icons on Office file types.

So even if I use a pre-launch script in the OSD to change the regkeys, I'm still in a lurch.

Oh and making it worse still is that if you have any of the components in Startup (which their own prescriptive guidance and another KB tell you to put MSOCache and the Sharepoint Proxy in startup, and most users wants Communicator/Lync in startup) the odds of it CORRECTLY polling the server and swapping out the old version for the new is slim at best, on average it takes us four reboots before it will finally be timed right and discard the old version. That is ridiculous.

So now you have to write something that shuts down App-V, as you can't shut down JUST the office components because even though you CAN tell what apps are running virtual you cannot easily (at all?) tell what apps are running in what environment. So if a user manages to get IE or Explorer hooked into you have no way of knowing. Once App-V is shut down programatically delete the package using SFTMIME.EXE and THEN refresh the server toget the new package.

All because there is absolutely no collision prevention in a platform that's entire purpose is to eliminate support costs, make software conflicts a thing of the past, and more intelligently manage your software. Yet it lacks basic organization and control functionality.

It is for reasons like this that I get SO frustrated when I see things like 4.6 SP1 come out, where they make the easiest part of sequencing more convoluted but, I guess, easier to people who PROBABLY shouldn't be sequencing to begin with (I'm sorry but if it made the difference for you, you probably shouldn't be doing it professionally) and more cumbersome for the more advanced users. While introducing plenty of frankly inexcusable bugs (can't set settings without exporting them as a template because it triggers a New Project, which now means you cannot use them with accelerators because the two aren't supported together).

I was once told by one of the App-V people that they had to make choices between "released in time to be relevant" and "perfect". My sincere response to them is that App-V is not relevant, nor are any of their competitors yet, nor would fixing these problems make it perfect. And 4.6 SP1 did not go in either of those directions, it was just a pointless and tangential side trip, wasting time they could have been using to make some of these fundamental changes.

My biggest concern about App-V? Whether or not the people who use it know enough about what is wrong to have any idea how to fix it. Right now, it doesn't seem like they do.

/rant

App-V: Cisco UCIntegration for Microsoft Lync 8

Here is a really fun one, made ten times worse by Ciscos complete and UTTER lack of interest in helping their customers out AT ALL.

A quick opinion here: STEER CLEAR of Cisco. Their support is notorious for being a joke, if they have an excuse to tell you to take a hike, they will do exactly that. Their software is poorly written, pathetically supported, and just generally not worth much. And no matter how many millions of dollars you just handed them they wont lift a finger to help you with a problem they KNOW the solution to (or imply they do) and would have been easily solvable by any one of the developers in an INCREDIBLY short period of time.

Avoid Cisco at all cost.

Now, on to the show.

This one gets a little hairy in that when you sequence CUCIMOC (the not so short name for the atrociously long "TM" included product mentioned in the header) and try to launch it on a client machine you get an error saying an unhandled exception has occured. Dig through the poorly laid out and nearly useless PRT result log and you find it is because the listening port of 44442 cannot be accessed. The full error is in the report but the net result is...it doesn't work.

In order to solve this problem you need one key thing from the CUCIMOC installer. NewBinary24. This is a binary (and this is poor form because all it seems to do is run netsh, this just seems to obfuscate the exact tasks) that uses netsh to reserve ports and quite possibly register listening ports for the CUCIMOC plugin. Without these being setup (and the sequencer fails to capture them) you will get the, as intended by MS, error that it doesn't have rights.

In my case I used Wise Package Studio 7, clicked on Setup Editor at the bottom of the Windows Installer Editor (after loading the MSI of course), clicked Tables, then on the Binary table, found NewBinary24, double clicked on the data field (sometimes takes three clicks) and wrote the contents out to c:\cisco.dll

On the target machine you then copy the cisco.dll to wherever, in this case c:\ and open an elevated command prompt (this can all obviously be automated by either a WiseScript or MSI and deployed via the task sequence or SCCM deliverable) and type the following:

RunDLL32 c:\cisco.dll, _netshOperations@4

This will call the DLL with the "_netshOperations@4" entry point and perform the functions from the install that were not captured, as the name implies this just runs netsh commands, it's hard to tell how many but there are at least 6 (which is why simply trying to reserve the 44442 port and setup the listener on 0.0.0.0:44442 didn't solve the problem, even though doing so didn't cause the PRT to move on to the next error, which leads me to believe the specific netsh command is not the obvious).

I've verified on a VM three times now that before running this DLL I get an error, and after, it works. This is a TREMENDOUS boon as if you intend to use this software with MOC 2007 then you know that MOC2007 has poorly thought out two-way communication with Outlook, which means you need to sequence the two together, well if you need the UC plugin for cisco you are stuck either taking ALL of office out of App-V, breaking the MOC integration (which is a bigger inconvenience than the ones added by UC) or ditching the UC plugin altogether.

Hope this helps!

Oh also there is a cert in the installer too that if you've gone this far you should be able to find (you can get it and the cdpinstaller.exe in the common files\cisco systems subfolder. I haven't determined yet if it is needed but...if so, it's in there, and the command line is in the MSI. Might as well post it I guess.

certmgr.exe -add -all "CDPCert.cer" -s -r localMachine trustedpublisher

I would include some of these files but who the heck knows how annoyed that might make cisco. If you have specific problems you can post below and I'll do my best to get you through.

App-V: WebEx Productivity Tools Outlook Integration.

The app itself is pretty simple and straightforward, however the way they add the plugin (you have to launch the WebEx Settings app and login to a webex site, and THEN it adds the plugin) is goofy and I could not get the sequencer to pick it up to save my life. The solution is fairly simple.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\WebExOI.Addin]

"CommandLineSafe"=dword:00000000

"Description"="ATLCOM Outlook Addin"

"FriendlyName"="WebEx Productivity Tools"

"LoadBehavior"=dword:00000003

Import that into the sequence (I used Kalles awesome AVE) and tada, should work fine when suited with Office 2010.

App-V: Visual Studio 2010 Cannot Create Window

Seen this a couple times.

The solution is very simple. Remeber to install the .Net 4.0 Full and the patch.

.NET 4 Full

KB2468871

App-V: Visual Studio 2010 Recipe Addendum.

Just a quick update to point out a couple things that need to be added to the VS2010 recipe.

When creating the exclusion list add the following:

%CSIDL_WINDOWS%\Installer, VFS

Also convert all teh registry operations into command line behaviors. Create a .reg file for the IEXPLORE.EXE step (encapsulate it in quotes like the guide says then export the key to a .reg file), then while monitoring use the Run button to "run" the .reg file and add the key to the registry.

Use "reg add" and "reg delete" for the other registry operations. Make sure to call these from an elevated command prompt.

And finally save the sequence to the local drive and not a network location, as doing so has created instability for several people I now who have sequenced this.

The App-V Blog Drinking Game.

Everytime you see some variant of the following explaining some random, erroneous, or just plain silly App-V behavior...take a drink.

This behavior is by design.

App-V: Scripting Multi-Line Batch Files.

Adding a script to an App-V package is all fine and good (even though it doesn't support anything beyond batch file era scripting languages) but if your script consists of multiple lines and you are adding it after the fact (especially for testing purposes) you may very well find it likes to butcher the script, condensing it all down to one long line.

The solution is very simple.

\r\n

Put that at the end of each line. It is the equivalent of a carriage return (enter...ish), and a new-line.

Is this a bit duct-tapey? Why yes, yes it is. But I suppose pointlessly "enhancing" the UI is a lot more important than making a sophisticated product, so get used to duct taping App-V together.

XenServer: Add/Remove Network Interface.

Remove:

• xe vm-list
• Copy the uuid for the VM you want to remove the interface.
• xe vif-list vm-uuid=<vm-uuid>
• Copy the uuid for the vif you want to destroy.
• xe vif-destroy uuid=<vif-uuid>

Note you will need to know which device you want to remove if there is more than one interface attached to the VM.

Add:

• xe list-network (you can add "name-label=<label>" if you know the networks name, in my case Bond 0+1)
• Copy the networks uuid.
• xe vif-create network-uuid=<network-uuid> vm-uuid=<vm-uuid> device=#

See above for how to find the VM's uuid, for device replace # with the device number, you can find a list of supported VIF devices by typing "xe vm-param-list uuid=<vm-uuid> | more" and looking for allowed-VIF-devices, if theres no interface currently on the VM you will most likely use 0.

As for why you would want to do all of this...well, sometimes you either don't have access to XenCenter, or it decides it doesn't want to play, it's always a good idea to bring your own ball.

App-V: Error Code 0000C800

Along with the other information floating around I have also found that if you install the App-V server on a different server than the SQL DB is hosted you need to ensure you have delegation enabled on that machine.

Failure to do so will result in the username/password that you connect to the server with being lost on the next hop to the SQL server. The resulting Access Denied will be a result of the SQL server, not the AVS, denying access to what is essentially an anonymous NT Authority account.

App-V: Using ProcMon in a package.

Not exactly hard to find information, but there is a reason I called it The Collection...

Insert this into the OSD of the offending app, once CMD runs, execute procmon (which you will obviously need to download to the machine) and close the command prompt, the app will then proceed to load and, presumably, error as usual, while procmon watches.

<SCRIPT EVENT="LAUNCH" TIMING="PRE" PROTECT="FALSE" WAIT="TRUE" TIMEOUT="0">
<SCRIPTBODY>cmd.exe</SCRIPTBODY>
</SCRIPT>

App-V: Merge Local.

Another question I've gotten a lot lately.

The example situation I'll give is HP Service Manager, I want to create secondary sequences to suite with the main install to lay down additional .launch files (that not everyone needs).

The files in question go to: Q:\ITSM.711\profile\ServiceManager\workspace\.metadata\.plugins\org.eclipse.debug.core\.launches

As an aside this is NOT where you want your secondary sequence to go, in this case I'm monitoring to Q:\ITSMDEV

Anyway, there are two ways to do this, if I create the folder path BEFORE I start monitoring the resulting path will show up as Merge with Local. If I create it AFTER I start monitoring it will be set to Override Local.

The difference between these two is, even though the primary package is not "local", one will BLOCK everything in Q:\ITSM.711 and the other will just add its contents on top.

Now lets say I WANT to block out the Development.launch file that may already exist in the package, but I don't want to block out the entire path. You wont be able to set JUST the file but you can create everything in the path UP TO the last folder, then create the last folder during monitoring and place the new .launches inside. Just bear in mind that it will block everything in the folder, so if you want them to still have Production.launch available you will need to include that as well, not ideal in my opinion but whatever.

Doing so will save you from being forced to click every folder in the path and set it to Merge with Local, while still picking up the Override Local on the .launches folder.

App-V: I click a shortcut and nothing happens.

Been getting this one a lot. If you click a shortcut for a sequenced app and it appears to do nothing, you have a hung sfttray.exe process that is blocking new instances. It can be kind of a crapshoot as to which one is actually blocking, but as no other apps are technically open it should be safe to end process on all instances of sfttray.exe

App-V: SharePoint proxy shuts down immediately.

Most common cause is MACHINE\Software\Microsoft\Office\14.0 is not set to Merge with local.

I know what you are saying "oh but I made sure it was before I saved my sequence.

Yeah, check it again, and once you do, BE CAREFUL, make a backup and modify the setting because it likes to each your sequence.

As always make certain you make your changes on a sequencer as close to the original as possible (i.e. 4.6 RTM, not SP1) to increase your odds of success.

XenServer: Manually Set Memory Range.

xe vm-list

Grab the uuid for the VM you wish to modify.

xe vm-param-set -uuid=<uuid> -memory-static-min=1024MiB

xe vm-param-set -uuid=<uuid> -memory-dynamic-min=1024MiB

xe vm-param-set -uuid=<uuid> -memory-static-max=1024MiB

xe vm-param-set -uuid=<uuid> -memory-dynamic-max=1024MiB

You will most commonly use MiB to specify the memory size.

My most common reason for setting this is the Windows 7 template sets the minimum RAM to 2GB, which IS the recommended minimum, but obviously not needed, especially if the VM is doing primarily lightweight testing (testing an install, etc.).