?
Solved

Does Roaming profiles copy in-use program settings?

Posted on 2012-08-16
7
Medium Priority
?
481 Views
Last Modified: 2012-09-18
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?
0
Comment
Question by:James_Clements
  • 3
  • 3
7 Comments
 
LVL 47

Expert Comment

by:David
ID: 38303418
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
 
LVL 84

Expert Comment

by:David Johnson, CD, MVP
ID: 38303460
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
 
LVL 47

Expert Comment

by:David
ID: 38303503
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
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
LVL 84

Expert Comment

by:David Johnson, CD, MVP
ID: 38303537
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
 
LVL 47

Assisted Solution

by:David
David earned 500 total points
ID: 38303627
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
 
LVL 84

Accepted Solution

by:
David Johnson, CD, MVP earned 500 total points
ID: 38303805
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
 

Author Comment

by:James_Clements
ID: 38409862
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

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Mailbox Corruption is a nightmare every Exchange DBA wishes he never has. Recovering from it can be super-hectic if not entirely futile. And though techniques like the New-MailboxRepairRequest cmdlet have been designed to help with fixing minor corr…
Most folks would know the basics of how Dropbox works, so that’s not the purpose of this article. Security is what it’s all about, so here I’ll share how I choose to secure my Dropbox Account and the Data it contains.
Monitoring a network: why having a policy is the best policy? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the enormous benefits of having a policy-based approach when monitoring medium and large networks. Software utilized in this v…
If you’ve ever visited a web page and noticed a cool font that you really liked the look of, but couldn’t figure out which font it was so that you could use it for your own work, then this video is for you! In this Micro Tutorial, you'll learn yo…

850 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question