Does Roaming profiles copy in-use program settings?

I support a software company that has run into an issue with roaming profiles.  We store computer specific settings in ini files for our program that are loaded upon launch of the program.  We found that in environments supporting Roaming Profiles, if they leave our program running when they logout of one station and move to another station, the settings for the original station are still in use on the second station.

Is this behavior consistent with how Roaming profiles work and is there any way for us to avoid this without simply training users not to do this or disabling Roaming profiles completely?
James_ClementsAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

DavidPresidentCommented:
Disable the roaming profiles.  Even if they worked perfectly, they won't work perfectly.   Temporary files can be saved anywhere, and MSFT does not require developers to put such information in any particular spot.

Open files and applications that are still running compound the problem, because you could even end up with data corruption.   What if an INI file is opened, and the developer caches part of it to update a counter during program operation, and then they rewrite the counter based on some arbitrary state?    If the user logs on somewhere else, then how can that application that is still running possibly detect and rewrite the same info?

(Well, there are programmatic means to do that, but developers aren't expecting to have to record lock what should be exclusive use files on individual machines.

Turn of roaming profiles, if for no other reason, to maintain operational integrity.
0
David Johnson, CD, MVPOwnerCommented:
I support a software company that has run into an issue with roaming profiles.  We store computer specific settings in ini files for our program that are loaded upon launch of the program.  We found that in environments supporting Roaming Profiles, if they leave our program running when they logout of one station and move to another station, the settings for the original station are still in use on the second station.

Computer Specific (machine settings) should go into programdata and not the users appdata

Users settings should go into the users appdata folder only.. Why do you hold the file open? open/read/close.. settings change open/write/close.

Is this behavior consistent with how Roaming profiles work and is there any way for us to avoid this without simply training users not to do this or disabling Roaming profiles completely?

Yes it is consistent so that the user has the same experience no matter which computer they use their settings follow them around.
0
DavidPresidentCommented:
Ve3ofa is correct ... this is what SHOULD happen.  but I know that it doesn't, because it can't possibly work.

What if the user modifies a setting on computer A that says nothing more than to use D:\ for the test database.   Then user goes to another computer.  He wants to re-populate the test database with live data for whatever reason, checks and verifies that it says D:\ is the test database disk.

User clones the database, and everything is blown away.  Why?  Because that computer originally had E:\ as test D:\ as live.    Turns out that that was a user setting.  

Just an example. The point is that whether something is a user or system setting is subjective. One can make a reasonable case that this particular example should be either system or user.  

The only way to prevent such problems is to not allow them to happen in the first place.  (Granted stale cached data is going to be the more likely contributor to data corruption, but application vs user settings are simply too open to misinterpretation to be trusted.
0
Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

David Johnson, CD, MVPOwnerCommented:
File location data is machine specific

 this is what SHOULD happen.  but I know that it doesn't, because it can't possibly work.

I disagree because it does work, which is why we have programming best practices and guidelines.  When a user logs in their drive mappings should also follow them. if on one machine
J: is mapped to \\production.server\database &
K: is mapped to \\test.server\database

it should be the same on ALL machines that the user logs into..  as defined in group policy for that user.
0
DavidPresidentCommented:
ve3ofa - You are confusing real-world with best practices.  We have already established that users don't log off.

Even if every programmer that ever wrote a line of code that is installed on these systems programmed to the same best practices, that still would not do the job.  A user is supposed to log off.  If they don't, files aren't closed.  This is NOT part of a normal test plan, so developers can't be expected to implement this.
0
David Johnson, CD, MVPOwnerCommented:
It should not matter whether or not the user logs off or not in this case.. on load open the ini file read the settings, close the .ini file and execute program..

user goes into settings and selects save, open the ini file, save the changes, close the ini file. We are not back in 1990 where making network aware programs was not known, and memory was short so you would keep the file open and read in the value when needed rather than keep it in memory.

In a best case scenario, if a user just shuts down remote desktop and goes to another machine and then logs in via remote desktop they should be back in the same session as they were in before they changes machines and the network shares should be exactly the same.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
James_ClementsAuthor Commented:
The answers provided weren't as solid as I would have hoped.  We implemented a workaround whereby we set an environment variable via batch file to a point to the folder that holds the ini files.  We then launch the program with that batch file and the program will look in the "alternate" path for the ini files.  At this point I consider this a workaround but it would be nice to know exactly how this is designed to work by Microsoft.

I'll accept multiple solutions to thank you two for your attention.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows OS

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.