Software Deployment

Er...isn't that what I did? And Owen did? Hey! Why not go REALLY wild and use AppDeploy's Search facility? Or this new-fangled search thingy called Google. It's getting quite popular, I understand.

ORIGINAL: turbokitty
aogilmor brought up an interesting topic in a previous thread that I believe needs more discussion. Vista shims. How are people using them in relation to packaging? Are people having pain with them? Tell us your experience.

Thanks for bringing this up as I'd be glad to hear of any special prerequisites for it. I am still not packaging for Vista, but realistically how long can xp go on? 4-5 more years maybe. There is no more 32 bit hardware being sold, and really, wouldn't it be nice to run virtual machines in all that memory? My hope is that it'll spur the production of lots of memory and the price will come down. Anyway, re: shimming my understanding is that this is the default behavior of the OS, the packager need do nothing for it to happen, and thus a program which used to require users:c access to ProgramFiles\somedir will no longer have to have those permissions applied - thus, it will make the packager's life easier (although those of use that have to deal wth this on a routine basis probably have scripting workarounds) :-) I'd love to hear anything first hand about shimming. Thanks!

I'd imagine that anyone looking at shimming with regards to permissioning will be looking with equal vigour at SoftGrid/AppV. My current client is...

ORIGINAL: VBScab
I'd imagine that anyone looking at shimming with regards to permissioning will be looking with equal vigour at SoftGrid/AppV. My current client is...

Hmm, I don't see the relationship. shimming comes with Vista by default, or can be easily turned on, whereas softgrid/AppV is a whole new way of installing (or NOT installing) software and would seem to require more servers, infrastructure etc.

Well you don't necessarily need a back-end infrastructure to run App-V. You can run the virtual apps without a server.

That said, I agree that App-V isn't the answer to Vista incompatibility. Kidero would be.. which is slated to be called "Med-V". Med-V isn't even in beta yet so it's a long way off.

Getting back to Shims, for those that don't know what they are, this virtual lab does a decent job of explaining them (only works in IE):
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032373037&EventCategory=3&culture=en-CA&CountryCode=CA

the packager need do nothing for it to happen, and thus a program which used to require users:c access to ProgramFiles\somedir will no longer have to have those permissions applied - thus, it will make the packager's life easier ORIGINAL: aogilmor


can application shimming also be used for giving restricted users access to registry hives such as HKLM or HKCR???

ORIGINAL: mohit_advani
can application shimming also be used for giving restricted users access to registry hives such as HKLM or HKCR???

I think it does work for registry keys as well as files, yes, but it does not actually grant access but "fakes out" the application into thinking that it is writing to hklm when in fact it is writing to the user profile. I found this on microsoft, here is a good passage the bold part especially of which seems to imply that most of the time the packager won't have to do anything,

"Implement an operating system with an automated process for running software as standard users.

Windows Vista and Windows Server® 2008 both have the ability to run software even if it was not written for standard users. Through UAC, file and registry virtualization, system shim databases (a built‐in layer between the operating system and applications to help non‐compliant applications access required resources) applications can run in the context of a standard user even if they were designed with administrative privilege requirements.

Manually develop and apply custom application shim databases.
If applications do not run automatically in the new operating system, cannot be recoded to comply with standard user context, or there is not a supported version, you can use custom shims as a solution to mitigate incompatibilities. Tools such as the Microsoft® Application Compatibility Toolkit 5.0 can help identify why the application is not compatible and expose which non‐compliant resources are needed by an application. With this information you can develop custom shim databases and map operating system shims to specific application instances."

Of course, we welcome, indeed seem to be rather starved, of first hand accounts of shimming. Maybe it that is because it is so successful -- indeed, maybe it was being done and the packager didn't even know it, as it seems to be the default behavior of the OS!

can u please advise if application shimming can be used for msi or is it only for legacy applications???

can u please advise if application shimming can be used for msi or is it only for legacy applications???Holy Moly...MSI is a technology for installing applications, not an application in itself. If you actually read the posts and the articles pointed to by links in those posts, your question would be answered.

VBScab would u mind answering the question in straight words...i am new to this technology n trying to gain knowledge on my own so would appreciate if my questions can be answered directly...

no point asking u anything it seems.....let it b m sure i'll get d info i need frm sum whr else...cy@

True. Every single one of my 2,700-odd posts has contained nothing of value to anyone, in particular post # 7 in this thread http://itninja.com/question/gnu,-freeware-and-shareware-programs-to-cloning3566. I honestly don't know why I bother. Ah well..I'll soldier on, I guess.

ORIGINAL: VBScab
Er...isn't that what I did? And Owen did? Hey! Why not go REALLY wild and use AppDeploy's Search facility? Or this new-fangled search thingy called Google. It's getting quite popular, I understand.


Ian, I think I may have to flag this post....I mean really, for you to suggest that Mohit actually READ what has been posted so far, actually type in WORDS in a search box, or (heaven forbid) even open a window to google.com and create his own search -- well, all I can say is that I've never seen such insolence, such disrespect, on this board or any other. We are here to do this work for Mohit, so that all he has to do is type in questions. And if the questions seem unclear, that is NOT his problem, but ours. It is our duty to find out what he means, do the research, and report the answer back to Mohit. Please, let's get back to the basic mission of appdepoy. Is that too much to ask?

Owen

I know it's frustrating for the senior members of the board that answer a lot of questions, but I think the key is to remain friendly but firm with people that don't use search.

I think a couple of gentle reminders about the search function is necessary before getting too upset.

Back to shims...

I'm interested in hearing how shims and packaging cross paths. Has anyone out there in a packaging role also had to author shims.. and how do the two relate or don't relate?

Are shims deployed with the package.. IN the package? Can some shims be avoided by repackaging an app? Etc.

ORIGINAL: turbokitty
I know it's frustrating for the senior members of the board that answer a lot of questions, but I think the key is to remain friendly but firm with people that don't use search.
I think a couple of gentle reminders about the search function is necessary before getting too upset.


Well, I was trying to be funny. Guess that didn't work....:-)

ORIGINAL: turbokitty
Back to shims...
I'm interested in hearing how shims and packaging cross paths. Has anyone out there in a packaging role also had to author shims.. and how do the two relate or don't relate?
Are shims deployed with the package.. IN the package? Can some shims be avoided by repackaging an app? Etc.

From what I've been able to read, they don't - cross paths, that is. AFAIK, shims aren't deployed in a package, although perhaps they could be in a CA (the microsoft source above is pretty sketchy on the specifics of manually creating a shim). I don't think they can be avoided by repackaging (and why would you want to? After all, it's less work packaging, and I've never heard of any problems arising from shims). I have also heard that you can turn shimming off - but again, why would anyone want to?

Well avoiding deploying and maintaining a shim (in addition to the package) would be one benefit of packaging to avoid a shim.

ORIGINAL: turbokitty
Well avoiding deploying and maintaining a shim (in addition to the package) would be one benefit of packaging to avoid a shim.

No disrespect, but did you read the Microsoft article? Packaging or not packaging, has nothing to do with the existence or non-existence of a shim. The shim refers to the process of redirecting application output from privileged areas of the file system and registry to the user profile. And as I've said before (probably to the point of annoyance, but nobody's proven me wrong) this is a default feature of the operating system and has nothing to do with the way an app is installed.

It just doesn't seem like this is anything the packager needs to worry about, as a rule. You're not going to "deploy" or "maintain" a shim most likely. It's just part of the OS. You don't deploy or maintain page files, right? I mean, other than maybe a scheduled OS tuning job. It "just works" as part of the OS. One possible exception may be if you manually create a shim but I've never seen anything even on microsoft about how to do that.

Actually manually creating shims is very common and they must be deployed to the target system although they can be managed centrally. The above virtual lab takes you through the process. A shim is not built into the OS per se.. it's a set of instructions for the OS to handle badly behaving apps. Now that could be an app that tries to write to a protected OS space.
By creating a package that changes the installation directory of an app... or maybe localizing a bad dll.. perhaps a shim could be avoided.

That's what I'm wondering about.

I know it's frustrating for the senior members of the board that answer a lot of questions, but I think the key is to remain friendly but firm with people that don't use search.Turbs, my problem with this post was that the question had already been answered - or, at the very least, pointed to, in another post (a link to which I posted). I think Owen was spot on in his faux remonstration with me for not questioning the poster at length, doing his research. and then reporting back. As you know, I'm more than willing to help people but when posters want ALL the work done for them, that's when I get ratty.

What was that link, again?

That was a joke, BTW... Just pushing VBScab's buttons. Can someone lock this thread all together before it causes mental meltdown for its members?

ORIGINAL: turbokitty
Actually manually creating shims is very common and they must be deployed to the target system although they can be managed centrally. The above virtual lab takes you through the process. A shim is not built into the OS per se.. it's a set of instructions for the OS to handle badly behaving apps. Now that could be an app that tries to write to a protected OS space.

Wait, are you saying that shimming is NOT the default behavior of windows Vista? The above link/passage would indicate and everything I've heard and read up to this point, says that manual shimming is not necessary most of the time. It kinda sucks that they don't some good detailed technet articles, I really hate watching instructional videos, but maybe I'll check it out :-)

ORIGINAL: turbokitty
By creating a package that changes the installation directory of an app... or maybe localizing a bad dll.. perhaps a shim could be avoided.

I don't think either of those are good solutions. And what do you mean localizing a bad dll? making a copy in the user profile? can you say kludgy?.....
Again, if the above article is at all accurate I don't understand why avoiding a shim is at all desirable. Are you trying to create some strange form of packaging job security? [;)]

Creating custom shims will be a mandatory part of the Vista upgrade process for large organizations. I started this thread because I believe many organizations will look to their packagers (application experts) for guidance in this area.
I have no real-world experience with shims yet, but I've got several projects on the horizon that will involve shimming and packaging for Vista. My hope was that someone out there had already encountered this and we could all learn from them. I wasn't aiming to have two guys who know almost nothing about the topic argue about it... [:D][:D]

ORIGINAL: turbokitty
Creating custom shims will be a mandatory part of the Vista upgrade process for large organizations. I started this thread because I believe many organizations will look to their packagers (application experts) for guidance in this area.


I'm wondering whether it is indeed true that "Creating custom shims will be a mandatory part of the Vista upgrade process for large organizations." Again, using the above mentioned links as a source, it should not be required for most apps. If it is, it would certainly weigh against MY decision/recommendation to upgrade, I'd be inclined to wait until Windows 7.

ORIGINAL: turbokitty
I have no real-world experience with shims yet, but I've got several projects on the horizon that will involve shimming and packaging for Vista. My hope was that someone out there had already encountered this and we could all learn from them. I wasn't aiming to have two guys who know almost nothing about the topic argue about it... [:D][:D]


Like you, I was also hoping for some specifics and/or real world experience, but it is a new OS so not surprising that there would not be a lot of experienced people in Vista deployment given its initial lukewarm reception and the budget climate these days. I do find it disappointing that MSFT hasn't done more to document/point out the way. I didn't mean to argue, just questioning some of the statements/assumptions that have been made. And as you can see from some of the posts, some are even more clueless than we are [:D][:D] [:D][:D] good luck in your upcoming projects, let us know what you learn.

Microsoft has some pretty good guidance out there now. They're really focused on trying to sell Vista.
If you look at the Application Compatibility Toolkit, there's a free tool that analyzes all the workstations in your environment and compiles a list of apps and what shims are required for that app to work properly on Vista. It contacts a Microsoft server that populates that data. It's pretty slick.
It obviously wouldn't be any help on oddball or in-house apps, so that's where custom shim building would come into effect.
I'll let you all know if I get any traction with this.

I hope they don't make you use the ACT to use shims - that would suck. I thought Vista had the native intelligence to do shimming without all that rigamarole. Major disappointment if it does not.

Hi folks,
interesting thread.
As i understand it, with ACT (or some other app), one generates an SDB-file, which then is applied to the target system with "secedit.exe".
Personally, i try to avoid virtual stores at all costs in a managed environment.
Other stuff is quite interesting too.
Especially LUA Buglight, see: http://blogs.msdn.com/aaron_margosis/archive/2008/11/06/lua-buglight-2-0-second-preview.aspx
Just my 2 cents...
Regards, Nick

I'm going to step in here and ask a question. I've googled and googled for a good reference on the compatibility shims. At Briforum 2008 I saw Rick Mack do all sorts of great stuff (http://www.brianmadden.com/blogs/gabeknuth/archive/2008/08/21/briforum-video-my-applications-won-t-work-presented-by-rick-mack.aspx) but what I've been left with is a yearning for real documentation from MSFT. Is anyone aware of some half decent documentation on each shim and what parameters can be fed into them?

Kevin, the somewhat recently released version 5.0.5428.1080 of ACT has a MUCH better help file that details each of the shims.

That video link is great.. I'm going to go through it all this week. I need to go to Briforum this year.

In regards to deploying shims.. shim info is stored in a database. You can either deploy a number of one-line, per-application shim databases with each application (in the MSI or otherwise) or you can maintain one large shim database for all your environment's shims and deploy that to all the machines... and update it when a shim is changed or a new app is added. Microsoft suggests the latter approach.

Yep, that's definately an improvement. Thanks!

If anyone have missed the "Shim Database to XML" tool then here it is: http://blogs.msdn.com/heaths/pages/sdb2xml.aspx

Maybe I'm thick headed but what is the use of the Shim Database to XML other than making XML files? I seem to be missing the greater purpose.

I was wondering that too. Is it just for reporting on a large shim database?

well, i thought shims were something that would make packagers' lives easier, but evidently not - according to most posts here, they require creation by the ACT (barf!), management, deployment etc. Ugh! I thought they were just supposed to work.

Maybe I never will play with vista and just jump to Windows 7 [:D]

Good luck!

Windows 7 = Vista SP2

I had Oracle 10 barf up some bad dll calls on installation with Windows 7. I personally think if you have issues with Vista today Windows 7 isn't going to be any easier.

Shimming shouldn't be seen as a headache, but an opportunity. If everything in Windows "just worked", we would be digging ditches.
[:D]
Shims are a great new revenue stream for packagers. Shimming requires a deep understanding of Windows, applications and deployment. Those are skills unique to application packagers.

I remember reading some posts here from people wondering if there is a future in packaging. In the past couple of years we've seen virtualization and now shimming as great new ways to stay relevant.

good point, but it was somewhat of a disappointment to me to read that shims MAY require a lot of mgt (I'm still hoping this isn't true, most of the time). I thought it was just something to help stupid apps that still try to write to program files, that it would fool them into writing to the user profile. Mind you, I've not heard anyone actually testing this theory but it wouldn't be hard to do:

1) get a stupid app that requires lockpermissions in XP
2) install it on vista WITHOUT the lockpermissions entries or the ACL custom actions without doing anything special to "install" or "manage" the shim.
3) run the app on vista and see if it works!

WRT virtualization, softgrid etc. of course those are great things to know, but I dont' think real hard disks with big bad installs are going away either. I've always been skeptical of those calling for or predicting "diskless workstations" Sure, there's security risk. But disk space is so ridiculously cheap, and most network connections robust these days, if users want or need big programs with rich interfaces to do their jobs better it's totally ridiculous to stick them with a citrix/web/softgrid/virtualization solution that's half-ass. And we know msft isn't getting rid of Windows Installer. Just my $.02

ORIGINAL: kkaminsk

Maybe I'm thick headed but what is the use of the Shim Database to XML other than making XML files? I seem to be missing the greater purpose.

I just thought to post the link if someone was interested Kevin.

However there is a -extract switch to extract ;) the content of a sdb file. In the "C:\Windows\AppPatch" folder you'll find some default ones, the "msimain.sdb" just about only contains transforms for known MSIs. Havn't looked that mutch on the tool but found it while searching for ACT and shimming for a year or two ago.

Take it or leave it

Well I did think of something that would be cool to do if I had the time. Use this tool to dump the database to XML then tranform the data into a custom mif so that SCCM can inventory the database configuration on your client. [8D]

Let me know when you've got that mof done. [:)]
I've never been able to get a custom mof to work properly.

Well MOF is a bit different because it's for WMI inventory. You need inventory manager!

http://www.dudeworks.com/Products/InventoryManager/tabid/57/Default.aspx

I almost bought that product once after fighting with a MOF for the better part of a week. I decided against it because the company is called "DudeWorks". They need to seriously consider rebranding.

I appreciate the endorsement. The next time I'm working at an SCCM/SMS shop and doing inventory, I'll pick it up.

I got the pointer from a large Western Canadian Telco so its probably half decent. I haven't implemented it so I have no first hand experience.

I do have to admit the name Dudeworks brings to mind hippie programmers from California coding apps for a living.

:P