Re: Vista - User Directory

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

See below...
On Thu, 05 Nov 2009 13:00:08 -0700, DanB <abc@xxxxxxxx> wrote:

Joseph M. Newcomer wrote:
Here is the rub. If a second user were to log on they would want to see
the software set up like the first user had set it up, not our defaults.
That is the nature of our product. We have site/user data that Joe was
talking about. The only things that would be user specific are the MRU
and win positions.
****
What you have here is a shared-data problem. There are several ways to handle this:

1. Make the data accessible via a service, using a named pipe or TCP/IP connections. The
service "owns" the data and the clients just use/update it.

2. Create a single, common directory with the correct permissions and put the file there.
Then you have to make sure the issues of what happens if two users just happen to be
logged in simultaneously arises. Note that under multiuser scenarios like terminal
services this is a common situation. If nothing else, you have to open the file exclusive
when the program starts. The file is never closed until the program exits. This prevents
*anyone else* from modifying it hwile it is active. A bit extreme for some situations, it
might fit yours.

Now note: it *might* be possible to create a shared folder under the CSIDL_COMMON_APPDATA;
I haven't looked to see how protections are set to inherit in those directories. So while
CSIDL_COMMON_APPDATA/Manufacturer may be set read-only by default, you might be able to
create a CSKD_COMMON_APPDATA/Manufacturer/SharedData folder which *is* accessible to a
selected number of users (at this point, you have to look at what your installer can do
with directory protections, whether or not the solid protection is mandatory so you can't
even create a shared folder, who you wish to allow to share it, etc., etc.) Alternatively,
you might create a simple top-level shared folder as you describe below (d:\Studies). I
don't do a lot with sharing protection, so I can't suggest the best strategy to use here.

3. Put it in a database and use a database server (a generalization of the first option)

It should not come as a surprise to a user to log in, run the program, and find that
*nothing* is as they left it yesterday. Therefore, you are running against the "principle
of least surprise" that governs most designs. The users need to understand that this is
what is going to happen.

Alternatively, you can split the data into three components: site-default, user-specific
and shared. So the user-specific settings remain (simple things like what printer to use,
for example), and shared settings involve things like the total picture of the data after
it has been updated. Then you look at the most appropriate mechanism to implement this
strategy. But lumping everything into a single file is probably not a good strategy,
because you will find that eventually it breaks down into the three categories. More
commonly two categories, but for you the third, per-site defaults, is important.

Databases do this implicitly. Generally, they simplify things because there are no
per-site settings, so there are only per-user (stored in the Registry, a config file in
CSIDL_APPDATA, or a config file someplace else user-specific) settings and global (the
database information) settings; that was what made the exercise I did a while ago to get a
database with per-site settings a bit unusual; that doesn't usually happen.

Once you realize there are three kinds of data, then you can approach the problem of how
to represent the data more readily, because you have a model you can use to break the
problem down.

Hi Joe,
Thank you.
I have been muling this over for quite some time. I know I need to
extend my 'server' concept, (that certain configurations need to be
shared). This has not been a major issue as these configurations remain
fairly static. Like the instance where my wife sets them up for a client
and then they are almost never changed. When I did the 'sever' thing I
had the files privileged locked.

I really have two issues on the table now and I do have a grip on the
second, sharing a configuration. That, as long as I can obtain proper
permissions across the network, and I have yet to have a problem with
that. As far as the per machine login, this should not be an issue if I
evolve the product configuration. File, folder, locking is a simple
enough implementation, I've done it before.

As far as the 'data' goes, what is in c:\Studies, it is not often that
two individuals will work on the same study at the same time. At that,
they know that the 'project info' is last close wins. But I have
considered locking to avoid misunderstandings. A project consists of two
files, and some dozen report files that never get modified by two
people. An xml with the project parameters, 'project info', and an mdb
with the components of the study. Most work is done on the components
and this works out nicely as two people can share the work and locking
is done at the record level.

As far as my original problem, getting out of the virtual store, I'm
doing two things. building a test msi and installing as guest on my
laptop. And the laptop is downloading VS 2010 beta right now so I can
see what the latest deployment tools look like.

The 'share configuration' thing is mostly a pita when a client gets a
new computer and wants to copy from an older machine. That's what
started this. My 'open settings folder' kicks off a windows explorer in
the APP_DATA/MyData folder. And because I've been installing in the
virtual store on Vista, I have no way to find this folder
programmatically. I have had to search the hard drive to find it.

Once I find it, I put a short cut to the folder on the desktop, but this
is just a hack I'm trying to fix.

****

But it would be very, very rare to find more than one user on a machine
using our product. So even when I do address this it is back burner to
getting that one user right first.

But out of the gate, I will take your advice and create the APPDATA
folder on first use rather than letting the installer do it. And this
may be the answer to my last challenge! Thanks.

There is another thing I'm starting to wonder about, I took it for
granted as I've never had a problem. Our clients store there data,
(different than settings), typically in a root folder like:
C:\Studies
(A few use a server, so F:\Studies, And one where I actually picked up
the look of the product from the server. But once they settled in they
didn't need the 'server switch'. Turtle's all the way down for me!)

They share this folder on the network so others in the office have
access to the Studies. I had not heard of a 'logo certification' until
Joe mentioned it. Is this in my future!?
****
If you want your product to have the Microsoft logo "Designed for Windows Vista" or
"Designed for Windows 7", then you need to go through logo certification. And while some
people need this (they sell their product in boxes), custom developers can usually ignore
it. BUT: the requirements for logo certification are good-practice guidelines, and are
designed to keep you from creating software which won't run, or which, in order to run,
has to open up security which creates potential hazards (for example, if your product is
accessible via the Web, could a malicious organization send your program an "ill formed"
packet which can grab control from the machine?).

Yes, I've researched the logo and came to the same conclusion. I should
comply with the guidelines, but I don't need to fork out the money for
it. And that it has nothing to do with application access across the
network.


I spent six weeks developing a solution for a company that had been selling XP-based
solutions that no longer worked in Vista. They required logo certification (if you are
logo-certified, you can also make your product available through microsoft marketing Web
sites on something.microsoft.com, I forget what the something is). I spent three weeks
becoming an expert in Vista integrity levels, and three weeks rewriting their code to not
require admin privileges while still doing what needed to be done. And three weeks later
I had forgotten most of what I knew about integrity levels...

Well, thankfully I have never written in code that required more than
user privileges. Like I said, we install and run fine on Vista/7. The
UAC is never triggered. The crumb thing is something else, settings are
tagged 'Not Installed' and this seems to keep the folder in place on an
uninstall. I have to do this or the clients settings would get wiped out
on a major upgrade. I'm sure I can find a way to ask to delete this
folder on an uninstall and will look into doing it. But I have to ask
rather than assume someone's work should get wiped.
****
The problem is that you have to keep a "reference count" of how many users have the
program installed, which is hard because you really don't know, for a network server, how
many machines might have access to that network folder. So sometimes the safest thing is
to leave the directory alone.
****


So logo certification is purely an option, but because it represents good-practice
guidelines, lets you avoid the kind of pitfall you just fell into, and can give you
marketing opportunities, it is worth reading the requirements and insofar as possible
adhering to them. I review them every couple years because I build my software as best I
can to follow them; it saves my clients from having problems if their product is installed
in a site that is serious about security (I started doing this with Win2K, where the
client was selling to Fortune n00 companies, and we had to fit within their security
guidelines, which were often as restrictive as Vista is. The difference was in Win2K, you
had to modify the out-of-the-box (OOB) settings for every install to enhance security;
with VIsta, the security is implicit in the OOB installation).
****
My primary mission is to make all this as seamless as possible for our
clients. They should not 'have to know' what they don't need to know.
Otherwise, I'm not doing my job properly. I'm getting itchy and why I'm
asking these questions.
****
As part of the install, you would ask about the shared directory for the common data
files, and have a default (e.g., c:\Studies) and an option to create one.

With a "new install, create new project", we detect that the 'data'
folder has not been set for the user. We ask and offer a CFolderDialog
to set, (and if needed, create), this folder parameter so the next time
they go for data we start them in this folder.
****
The person who does the install on their machine can only create a folder for their own
login account; you can't really go off and create folders for other users. A sysadmin
doing an install for a set of users can create a shared directory, but as each startup
occurs, the individual user has to set any custom settings.
****

I'm less
certain of how you might want to handle access. The write access should be limited to the
users who are actually doing something, otherwise, any program from any user at any time
[read: malware] can overwrite the data. If the data is "sensitive" in any way [e.g.,
HIPPA or equivalent] you would need to limit the read access. Law and corporate policies
begin to be more and more important these days; I did a system a while ago where we had to
deal with serious security issues based on the client security policies (it was a shell
extension that had to be very limited in what it was allowed to do, and the way it created
new entitites was constrained by the security policies). So while logo certification may
or may not be part of your future, security is very real and very now.

Yes, here we have not done anything. If the client does not have a
decent firewall, they are vulnerable. I will have to address what is
within my scope of responsibility where security is concerned. Usually
anyone with a network have an IT that deal with security as our data is
small fry compared to the rest of the data on their network. Studies are
distributed publicly so there really is nothing secret in our data.
Networked clients usually backup daily.
****
It isn't always a firewall issue. If you have seven users, but only three are supposed to
access the file, what are you doing about the other four? There are legal implications if
you do something that can cause an information leak of what might be "personal data". Or
proprietary scientific data.
****

The major difference between XP and Vista/Win7 is that Vista and Win7 do OOB enforcement
of what used to be optional policies.

I'll keep this group up to date on how the manifest thing and 'new'
install goes.

Thanks, Dan.
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Going about a fresh reinstall
    ... Copy this folder to ... specific programs' settings. ... >the install. ... >those you don't have a clue how you'll restore later. ...
    (microsoft.public.windowsxp.moviemaker)
  • Re: install oem version of XP Mediacenter 2005
    ... Settings without a huge can of worms. ... The warning about moving a special folder is there every time you move one ... except for the Media Center parts. ... I can't believe M$ forces you to install things ...
    (microsoft.public.windows.mediacenter)
  • Re: Vista - User Directory
    ... even create a shared folder, who you wish to allow to share it, etc., etc.) Alternatively, ... So the user-specific settings remain (simple things like what printer to use, ... Our clients store there data,, typically in a root folder like: ... has to open up security which creates potential hazards (for example, ...
    (microsoft.public.vc.mfc)
  • Re: Going about a fresh reinstall
    ... specific programs' settings. ... I'll know which applications I want to redownload and install. ... latest virus definitions. ... My c:\Data folder remains untouched throughout the ...
    (microsoft.public.windowsxp.moviemaker)
  • Windows Update Server question/problem
    ... the clients Windows Update was set to ... DOWNLOAD, notify but do not install. ... I can make no changes to these settings on the client. ...
    (microsoft.public.windows.server.sbs)