none
Future of Roaming Profiles RRS feed

  • Question

  • This was from a separate thread, but I think it deserves its own topic, not least because others may have an interest in this and may not have seen the other thread.

    In that thread, Jeff Patterson - MSFT wrote:

    "Regarding Roaming User Profiles (RUP) support, RUP is supported on Windows 10 but we’re no longer investing in new features. We do plan to deprecate RUP in the future but the timing has not been determined.

    Our recommendation is to use our modern solutions for roaming user data:

    • For settings and application data, use UE-V or Enterprise State Roaming (ESR)
    • For user data, use Work Folders or OneDrive for Business"

    Our concern is primarily over the first of these - settings and application data.

    Roaming profiles work for us currently in addressing two main issues:

    • Slow login. Our students rarely use the same machine twice. Copying a profile down from the network is much faster in practice than going through profile creation. By using roaming profiles, our students go through the slow profile creation process just once at the start of each year rather than on every login.
    • Synchronising application settings for all applications by default. We have what we think of as a large application set (300+ traditional apps), and this changes frequently. We need settings to move with the user, without having to tailor things on a per application basis. This needs to work for applications we don't necessarily know about (academic environments are like that), and it needs to work for Java and Python (etc) applications that are not uniquely identifiable from their executable name. Roaming profiles handle this for the large majority of cases.

    We currently depend heavily on both of these abilities, and are concerned that UE-V and ESR - the proposed modern solutions - do not address them. That is, they are not in fact solutions to the problems we currently solve with roaming profiles:

    • UE-V doesn't affect profile creation on first login, requires per-application tailoring, only works for applications you configure it for, and identifies applications by their executable.
    • ESR doesn't affect profile creation on first login, and only works for universal apps (and perhaps only then if the application is written to support it).

    (Correct me if I'm wrong about either of those.)

    So, roaming profiles provide functionality that the proposed replacements do not. Removing roaming profile support without providing a replacement that can handle these cases is a major downgrade in the capabilities of windows in an environment like ours.

    Obviously, there are some third-party solutions which may offer those kind of abilities, but they tend to be expensive, and tend to break whenever a new windows version appears. We'd prefer a native Microsoft solution, as roaming profiles are currently.

    Any suggestions welcome, official or otherwise, for how to handle these requirements in the absence of roaming profiles...

    I'll post below about why our students rarely use the same PC twice but, to pre-empt some responses, the following ideas aren't great: having the device move with the user (i.e. give the user a laptop), or having the user connect to a desktop hosted elsewhere (i.e. VDI of some kind). We've considered both of those at various times, and they have significant downsides or are plain unworkable for several cases. Neither of them solve the problems we currently solve with roaming profiles.

    Also, some questions on the scope of this. If roaming profiles become deprecated, where does this leave terminal services profiles which are functionally very similar (and which we also use)? What about folder redirection (which we use as a way of speeding up login with roaming profiles by reducing the amount of data to be copied at logon and logoff). What, for that matter, about the distinction between appdata\roaming and appdata\local, if nothing ever roams?


    • Edited by Mike Sandells Friday, January 6, 2017 10:18 AM cosmetic edits
    Friday, January 6, 2017 10:17 AM

All replies

  • Some background on our environment, to explain why "students rarely use the same machine twice" is a thing, and why laptops/VDI are not good answers to the problem.

    We're a University with a single main campus, geographically speaking. We have a few outposts, but most students will spend all their time within walking distance of any classroom or lecture theatre they may have a class in, and within walking distance of the two main libraries.

    Bookable classrooms of the sort we care about - rooms full of PCs, essentially, perhaps with a specific station for the tutor - are a centrally managed resource, not owned by any particular department. Any of the general bookable rooms may be used for classes for students on any course. So, these rooms will see students of all kinds, and students will find they have classes here, there and anywhere, rarely using the same room twice in succession, and without getting the same PC even if they return to a given room.

    Areas with PCs that aren't bookable tend to be in the libraries, and therefore similarly available to students from any course. There are far more students than PCs in these areas, so they get a PC on the basis of which PCs are available, not which PCs they have used previously.

    A minority of classrooms (but still a large number of PCs - several hundred) have PCs with locally attached hardware of various sorts, or have a particular spec (typically graphics cards) required for particular software (e.g. ABAQUS, Creo etc). A minority also have software licensed to the individual PC.

    Most classrooms have software that allows the tutor in the room to see / control the screens of the students taking part in the class. This depends on the tutor station knowing about the student stations that belong with it, or the student stations knowing which tutor to report to, or both. In some cases this software even knows and displays the room layout, allowing the tutor to see a view of the room with the stations in the right positions relative to the tutor.

    We also keep track of which PCs are in use at any given time, and provide students with a mobile application that allows them to find a free seat at busy times. Again, this not only knows what stations are in what centres, and the lat/long of each centre, but the room layout within the centre. This system also provides usage statistics which we make significant use of.

    Student PCs are reimaged frequently in an automated manner, to keep things tidy or change what software is installed where.

    The above requirements do not work well with either a laptop-per-student model or a VDI model. Given that the above are requirements we will continue to have, we need to find ways for students to use these systems without slow login, and with their settings moving with them between PCs.

    We may be unusual as a university in the degree of centralisation of room booking etc, but not I think in most of the other respects. I expect some of these to be relatively common requirements within academia and elsewhere.

    If roaming profiles are (some time in the future) no longer the solution to this, what is?

    Friday, January 6, 2017 10:30 AM
  • Hi,
     
    Am 06.01.2017 um 11:17 schrieb Mike Sandells:
    > In that thread, Jeff Patterson - MSFT wrote: "Regarding Roaming User
    > Profiles (RUP) support, RUP is supported on Windows 10 but we’re no
    > longer investing in new features. We do plan to deprecate RUP in the
    > future but the timing has not been determined.
     
    Long story short: Use UE-V
    It´s onboard and available in Windows 10 1607 Enterprise. Sadly not in
    Professional.
     
    Advantage of UE-V
    - process start/stop based, not login/logoff
    - only defined settings are "roamed" for that specific process
    - it can handle registry, AppData and(!) LocalAppData
    - much less data, because you do not roam the complete Profile
    ...
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Friday, January 6, 2017 11:46 AM
  • Long story short: Use UE-V

    We need something that avoids the user going through profile creation on every login, and that works for all applications by default, not just for ones we know about and can configure. We also need it to work for applications that run inside java.exe or python.exe, and can't be identified from the executable as it appears in task manager, which seems to be how UE-V works.

    Roaming profiles solve both of those issues. UE-V doesn't solve either of them.

    Friday, January 6, 2017 11:57 AM
  • Hi,
     
    Am 06.01.2017 um 12:57 schrieb Mike Sandells:
    > We need something that avoids the user going through profile
    > creation on every login,
     
    There is no technical reason, thats only your point of view.
     
    If the /new/ profile is shortend to a small one, it cause not much more
    time, than the sync takes you need in RUP, especially if you roam 1000+X
    small files in AppData.
     
    > and that works for all applications by default, not just for ones we
    > know about and can configure. We also need it to work for
    > applications that run inside java.exe or python.exe, and can't be
    > identified from the executable as it appears in task manager, which
    > seems to be how UE-V works.
     
    Even than, you can configure them to "roam" then when explorer.exe
    starts. Which executable you watch an witch settings or synchronized by
    this start process is completly up to you.
     
    you can watch "explorer.exe" or any other to sync Office, CMD settings,
    notepad++ and your firefox bookmarks. Benefit: All settings are there.
    Disadvantage: tons of data, that are probably not used in this session.
     
    Watch only specific executables and /their/ settings is just a
    performance argument. All other settings can be taken from the NEW
    CREATED Default user profile. You define, which settings are worth to be
    saved.
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Friday, January 6, 2017 1:12 PM
  • Am 06.01.2017 um 14:12 schrieb Mark Heitbrink [MVP]:
    > If the /new/ profile is shortend to a small one, it cause not much
    > more time,
     
    ... remove apps of course. (Get-AppxProvisionedPackage -Online ...)
     
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Friday, January 6, 2017 1:29 PM
  • Hi,
     
    Am 06.01.2017 um 12:57 schrieb Mike Sandells:
    > We need something that avoids the user going through profile
    > creation on every login,
     
    There is no technical reason, thats only your point of view.
     
    If the /new/ profile is shortend to a small one, it cause not much more
    time, than the sync takes you need in RUP, especially if you roam 1000+X
    small files in AppData.

    Which is why we redirect Appdata\Roaming to a network location, and similar folder redirections to limit the amount of data copied on login. We also do what we can to speed up profile creation by stripping down the default user profile. We're also using LTSB (for student PCs) which avoids a lot of the slow down from modern app provisioning.

    Profile creation is still considerably slower than logging on with an existing roaming profile. Profile creation being slow is not a new problem (although it seems worse in 10). The prospect of being unable to avoid it is what's new.

    Aside from the slow login question, yes we could use UE-V to track explorer or other exe that spans the entire user session. If redirecting appdata etc is still an option, it would only have the current user registry changes to sync, plus any stray folders (usually unix ports that create a .whatever folder directly under %userprofile%).

    That may all be possible. But it's nowhere near as good a solution as we have now. We could do something like that with some fairly simple stuff in the logon/logoff script, without needing UE-V.

    This is still a significant loss of core windows functionality.

    Friday, January 6, 2017 2:10 PM
  • Hi,
     
    Am 06.01.2017 um 15:10 schrieb Mike Sandells:
    > Profile creation is still considerably slower than logging on with an
    > existing roaming profile.
     
    right, but accaptable with all APPs removed :-)
     
    > If redirecting
    > appdata etc is still an option,
     
    For sure! Sorry if I point you in the wrong direction. UE-V is not a
    replacement for Folder Redirection.
    UE-V is a reducement of necessary informations.
     
    > But it's nowhere near as good a solution as we
    > have now.
     
    Hm, actually you loose all bookmarks in Firefox or Chrome, in their
    default configuration, because they are stored in LocalAppData and you
    need to script the sync of LocalAppData. FF and Chrome can be configured
    to change there profile path, but what about all the other usefull
    information in LocalAppData? (even if there should be none ;-)
     
    > We could do something like that with some fairly simple stuff
    > in the logon/logoff script, without needing UE-V.
     
    Logon/Logoff is a time and Last Writer Wins Problem ... think of having
    huge RDS farms with different sessions. If the programs settings are
    synced by process start they are available in all sessions, not only
    after logoff/login.
     
    To me, the only "Do always recommandation" is folder redirection.
    RUP is easy to handle, because the technic is old and most admins are
    familiar with it.
    UE-V is a good idea, if only little information is necessary and the
    biggest benefit is it can handle LocalAppData and is processbased.
     
    To reduce profile creation time, do not delete local user profiles at
    logoff, delete them by time with a tool like delprof2.exe
    Profile deletion is "common sense" when using RUP, but when using UE-V
    it´s not needed to have stable and functional profiles. Because of the
    missing sync of the profile, they do not get corrupted ...
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Friday, January 6, 2017 2:45 PM
  • Hm, actually you loose all bookmarks in Firefox or Chrome, in their
    default configuration, because they are stored in LocalAppData and you
    need to script the sync of LocalAppData. FF and Chrome can be configured
    to change there profile path, but what about all the other usefull
    information in LocalAppData? (even if there should be none ;-)

    Firefox stores its bookmarks and other config in appdata\roaming here...

    Chrome is the one application where we've had to do something to deal with the local appdata problem. We started handling that at the start of last academic year and haven't had to touch that since.

    Our other 300+ apps are well behaved, and either store their data in the current user registry, or in appdata\roaming, or failing that in %userprofile% somewhere.

    Mostly we consider data in appdata\local to be either temporary, or specific to that user+PC combination, and so not suitable for syncing to other PCs. That's how it should be, at least.

    Meanwhile, I've dug out some stats from last academic year. A typical student PC saw 600 different usernames across the year. PCs in our libraries see around 1,000 different users per year. The worst case was some of our PCs intended for quick walk-up use - one of these saw as many as 7,500 unique usernames across the year. Given that most of these would be within term-time, that's 35-40 users per day, average. That PC saw 103 unique users in a single day last April.

    That's a lot of logins. If logging on with no existing local profile gets slower, and without roaming profiles that looks unavoidable, that's a lot of accumulated wasted time...

    Friday, January 6, 2017 3:19 PM
  • Hi
     
    Am 06.01.2017 um 16:19 schrieb Mike Sandells:
    > Our other 300+ apps are well behaved,
     
    lucky you are :-)
     
    > [...] that's 35-40 users per day, average. That PC
    > saw 103 unique users in a single day last April.
     
    Wow, thats a lot. Sadly, there is no "100% fits all" solution.
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Saturday, January 7, 2017 1:06 PM
  • Mike,

    Thanks for the feedback! I've forwarded your feedback to the teams that own these scenarios.

    Regarding slow logon due to profile creation, I would recommend evaluating the login improvements that were made in Windows 10 version 1607. These improvements are documented in the following article: https://technet.microsoft.com/edu/windows/use-set-up-school-pcs-app

    Thanks,

    Jeff


    Sunday, January 8, 2017 5:26 AM
  • Hi Jeff,
     
    Am 08.01.2017 um 06:26 schrieb Jeff Patterson - MSFT:
    > These improvements are documented in the following article:
     
    to be honest, that does not work. You do not walk to 300 PCs or even 30
    and insert a USB stick to start a "Lite Touch Deployment".
     
    If it can´t be deployed by "DISM.exe /Add-ProvisioningPackage" its
    worthless.
     
    Ther "improvements" or not the one I want ... Where is the technical
    intersting part to speed up login performance, to customize it and make
    it work in my environment?
    The topic "What does this app do?" leeds me more in the direction to NOT
    use this tool.
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Sunday, January 8, 2017 10:11 AM
  • Hi Mike,
     
    Am 06.01.2017 um 15:45 schrieb Mark Heitbrink [MVP]:
    > [...] To reduce profile creation time, do not delete local user
    > profiles at logoff, [...]
     
    Are you running on Windows 7 or 10?
     
    I totally forgot, deleting Local profile at logoff is a bad idea in
    Windows 10. If you delete "%LocalAppData%\Packages", you loose the
    functionality of all the APPs, even the ones that are not that obvious
    -> Date and Time, Startmenue, calculator. photos, edge etc.
     
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Sunday, January 8, 2017 10:37 AM
  • Mike,

    Thanks for the feedback! I've forwarded your feedback to the teams that own these scenarios.

    Regarding slow logon due to profile creation, I would recommend evaluating the login improvements that were made in Windows 10 version 1607. These improvements are documented in the following article: https://technet.microsoft.com/edu/windows/use-set-up-school-pcs-app

    Thanks for responding!

    Some of the questions that were in my original post at the top of the thread are still unanswered - could you shed any light on these, please?

    • Terminal services profiles - these use the same basic mechanism as roaming profiles. If the roaming mechanism itself goes, do terminal services profiles go with it?
    • Likewise folder redirection. Is this also for the chop at some point?
    • Finally, the distinction between appdata\roaming and appdata\local doesn't make much sense in an environment without roaming profiles. Will that remain anyway?

    As for the "Schools PCs app", I'll just say that that looks a little lightweight compared to our requirements. Most of what we do is not mentioned or not possible as described on that page (e.g. fully unattended reimaging / deployment, where the PC works out which station it is in which centre). Most of this is not particularly relevant to this thread, but to get some idea of the facilties we currently offer, this is the web app we provide to students to allow them to locate a free PC at busy times: http://pcseats.liv.ac.uk/ This includes all the centre details and pre-installed software (but doesn't include some departmental centres with special equipment or similar that aren't public access).

    We also use the student PCs for various forms of grid computing when idle using HTCondor.

    • Proposed as answer by coppell07 Tuesday, April 16, 2019 4:06 PM
    Monday, January 9, 2017 9:17 AM
  • Hi Mike,
     
    Am 06.01.2017 um 15:45 schrieb Mark Heitbrink [MVP]:
    > [...] To reduce profile creation time, do not delete local user
    > profiles at logoff, [...]
     
    Are you running on Windows 7 or 10?
     
    I totally forgot, deleting Local profile at logoff is a bad idea in
    Windows 10. If you delete "%LocalAppData%\Packages", you loose the
    functionality of all the APPs, even the ones that are not that obvious
    -> Date and Time, Startmenue, calculator. photos, edge etc.

    We do delete profiles at logoff, but the problem you describe does not apply because we're using LTSB for the student PCs, so there are no modern apps as such. The start menu is indeed a problem, and we use ClassicShell instead to work around that.

    We use LTSB because we need (policy decision) to stick with a consistent windows, office and IE version across the academic year. This means that someone doing a re-sit exam in August is doing so on the same basic version of things as went live in our centres the previous September (and that we had been working on since the April/May before that). We can't guarantee that that's possible with CBB.

    More generally, usage patterns mean that there is very little chance that the user will ever return to that PC, so retaining local appdata doesn't really gain anything - it will never be used. The numbers of logins mean that we would fill up the local disk pretty quickly if we didn't do something to delete old cached profiles. How exactly we do the deletion is a different question, and we could explore various options.

    Also, the fact that the new start menu puts data in local appdata, expects it to persist, and falls on the floor if the user doesn't have those files was a bit of a hint that MS maybe no longer care that much about or properly test the roaming user scenario. The question was whether they would fix the the start menu so that it works properly for roaming users, or abandon the roaming user model.

    This thread implies the latter, but other threads indicate the former - see the post from Jools86 in this thread:

    "Hey all, I raised a Premier support call regarding this very same issue. [...] They said this will be fixed (Roaming Start menus) on the next Anniversary release of Windows 10, so approx Summer 2017. It is in their list of new features for the release."

    So maybe they'll fix it to work for roaming users at the same time that they remove the option to have roaming users. Stranger things have happened...

    Monday, January 9, 2017 9:40 AM
  • This was from a separate thread, but I think it deserves its own topic, not least because others may have an interest in this and may not have seen the other thread.

    In that thread, Jeff Patterson - MSFT wrote:

    "Regarding Roaming User Profiles (RUP) support, RUP is supported on Windows 10 but we’re no longer investing in new features. We do plan to deprecate RUP in the future but the timing has not been determined.

    Our recommendation is to use our modern solutions for roaming user data:

    • For settings and application data, use UE-V or Enterprise State Roaming (ESR)
    • For user data, use Work Folders or OneDrive for Business"

    Our concern is primarily over the first of these - settings and application data.

    Roaming profiles work for us currently in addressing two main issues:

    • Slow login. Our students rarely use the same machine twice. Copying a profile down from the network is much faster in practice than going through profile creation. By using roaming profiles, our students go through the slow profile creation process just once at the start of each year rather than on every login.
    • Synchronising application settings for all applications by default. We have what we think of as a large application set (300+ traditional apps), and this changes frequently. We need settings to move with the user, without having to tailor things on a per application basis. This needs to work for applications we don't necessarily know about (academic environments are like that), and it needs to work for Java and Python (etc) applications that are not uniquely identifiable from their executable name. Roaming profiles handle this for the large majority of cases.

    We currently depend heavily on both of these abilities, and are concerned that UE-V and ESR - the proposed modern solutions - do not address them. That is, they are not in fact solutions to the problems we currently solve with roaming profiles:

    • UE-V doesn't affect profile creation on first login, requires per-application tailoring, only works for applications you configure it for, and identifies applications by their executable.
    • ESR doesn't affect profile creation on first login, and only works for universal apps (and perhaps only then if the application is written to support it).

    (Correct me if I'm wrong about either of those.)

    So, roaming profiles provide functionality that the proposed replacements do not. Removing roaming profile support without providing a replacement that can handle these cases is a major downgrade in the capabilities of windows in an environment like ours.

    Obviously, there are some third-party solutions which may offer those kind of abilities, but they tend to be expensive, and tend to break whenever a new windows version appears. We'd prefer a native Microsoft solution, as roaming profiles are currently.

    Any suggestions welcome, official or otherwise, for how to handle these requirements in the absence of roaming profiles...

    I'll post below about why our students rarely use the same PC twice but, to pre-empt some responses, the following ideas aren't great: having the device move with the user (i.e. give the user a laptop), or having the user connect to a desktop hosted elsewhere (i.e. VDI of some kind). We've considered both of those at various times, and they have significant downsides or are plain unworkable for several cases. Neither of them solve the problems we currently solve with roaming profiles.

    Also, some questions on the scope of this. If roaming profiles become deprecated, where does this leave terminal services profiles which are functionally very similar (and which we also use)? What about folder redirection (which we use as a way of speeding up login with roaming profiles by reducing the amount of data to be copied at logon and logoff). What, for that matter, about the distinction between appdata\roaming and appdata\local, if nothing ever roams?


    Mike I am really glad you've raised this concern. I have been working in enterprise environments for 16 years with Microsoft technologies, and never have I felt that Microsoft is abandoning its enterprise customer base the way it is at the moment.

    I understand there is a rally around cloud technology for software vendors, and I understand Microsoft wants a slice of the action, but at the moment, Microsoft should be catering for those customers who don't feel the need to adopt cloud as much as it should those that do, and it just isn't.

    Roaming profiles have been neglected for a long time by Microsoft, I understand this is because of profile redirection and a host of other technologies that were designed to replace it, but frankly, none of them were ever good enough. The frustrating part is that it should be so simple; update the roaming profile services and create a dedicated 'listener service' on Windows service which uses DFS-R technology to efficiently and quickly replicate files from the workstation to the server, but not in a pick-n-mix fashion as configurable in UE-V, just sync the entire profile please.

    This is a repetition of many other products within Microsoft from my experience, progress only ever seems to involve neglecting one product in favour of its replacement, rather than growing both or providing a like for like replacement or supporting both. It's a crying shame.

    Monday, April 10, 2017 9:58 AM
  • Roaming profiles work for us currently in addressing two main issues:

    • Slow login. Our students rarely use the same machine twice. Copying a profile down from the network is much faster in practice than going through profile creation. By using roaming profiles, our students go through the slow profile creation process just once at the start of each year rather than on every login.
    • Synchronising application settings for all applications by default. We have what we think of as a large application set (300+ traditional apps), and this changes frequently. We need settings to move with the user, without having to tailor things on a per application basis. This needs to work for applications we don't necessarily know about (academic environments are like that), and it needs to work for Java and Python (etc) applications that are not uniquely identifiable from their executable name. Roaming profiles handle this for the large majority of cases.

    We currently depend heavily on both of these abilities, and are concerned that UE-V and ESR - the proposed modern solutions - do not address them. That is, they are not in fact solutions to the problems we currently solve with roaming profiles:

    • UE-V doesn't affect profile creation on first login, requires per-application tailoring, only works for applications you configure it for, and identifies applications by their executable.
    • ESR doesn't affect profile creation on first login, and only works for universal apps (and perhaps only then if the application is written to support it).

    (Correct me if I'm wrong about either of those.)

    So, roaming profiles provide functionality that the proposed replacements do not. Removing roaming profile support without providing a replacement that can handle these cases is a major downgrade in the capabilities of windows in an environment like ours.

    Obviously, there are some third-party solutions which may offer those kind of abilities, but they tend to be expensive, and tend to break whenever a new windows version appears. We'd prefer a native Microsoft solution, as roaming profiles are currently.

    Any suggestions welcome, official or otherwise, for how to handle these requirements in the absence of roaming profiles...

    I'll post below about why our students rarely use the same PC twice but, to pre-empt some responses, the following ideas aren't great: having the device move with the user (i.e. give the user a laptop), or having the user connect to a desktop hosted elsewhere (i.e. VDI of some kind). We've considered both of those at various times, and they have significant downsides or are plain unworkable for several cases. Neither of them solve the problems we currently solve with roaming profiles.

    Also, some questions on the scope of this. If roaming profiles become deprecated, where does this leave terminal services profiles which are functionally very similar (and which we also use)? What about folder redirection (which we use as a way of speeding up login with roaming profiles by reducing the amount of data to be copied at logon and logoff). What, for that matter, about the distinction between appdata\roaming and appdata\local, if nothing ever roams?


    Hi Mike.  Thanks for bringing this up.  I agree 100% with all of your concerns as we too (being a UK University) have exactly the same concerns about the future of RUP, and need to make some decisions around what compromises we will need to make in trying to move away from them. 

    We are planning to continue with them with our migration to Windows 10 this summer, but will be forced to push through the pain of inconsistent user experience and will have to educate users around the things that still remain broken with RUP in Windows 10 (almost 2 years down the line since it was released!).

    I know a lot of multi-user environments like University's, schools and colleges rely on the benefits that RUP gives it's users, and it's a shame that experience will suffer as we move forward without a "proper" replacement.  As I said above, at the moment it seems the alternatives all require some form of compromise, which WILL affect user experience.

    I will watch this thread with interest and hope that it gains some momentum over the coming months and maybe Microsoft will be able to address some of the issues that we'll be faced with when RUP is deprecated.

    Regards,

    Chris McEvoy
    Keele University


    Friday, April 28, 2017 11:49 AM
  • This is a repetition of many other products within Microsoft from my experience, progress only ever seems to involve neglecting one product in favour of its replacement, rather than growing both or providing a like for like replacement or supporting both. It's a crying shame.

     "It's a crying shame" sums up Microsoft's behavior with everything they're doing to the enterprise over the last few years. It's amazing to me how they can have such a large & sophisticated development organization and yet they don't do the proper research and homework when making change decisions. From Mike Sandells description at the beginning of this thread, it is clear there are real world needs met by technology previously developed and provided and that the new replacements do not address these needs.

    Shame on you Microsoft. 

    Wednesday, May 9, 2018 2:49 PM
  • Given that this thread has been resurrected, I may as well post an update on how we've handled this.

    In short, finding nothing very helpful in the MS offerings, and not liking the look of any of the third-party mechanisms, we rolled our own sync process, which we have been using for the 2017/18 academic year, and will be continuing to use for the forseeable future to sync settings between profiles for students.

    More details here: http://pcwww.liv.ac.uk/syncprofile/

    This solves most of the issues for us, except for the profile creation delay which we currently solve with tweaks to the image to speed things up, but mostly by using LTSB for the student PCs. We also intend to stick with LTSB for 2018/19 at least and probably beyond, as it meets our needs in a way that the other branches/channels do not.

    We did this last summer partly because roaming profiles were an increasingly large headache, but because we wanted to test out alternative approaches while roaming profiles and redirection of profile internals (appdata\roaming) were still available as a fallback position. I see from other threads that appdata\roaming may no longer be redirectable in 1803 (or at least not by GPO), so it looks like we timed this well.

    If it's the case that appdata\roaming can't be redirected any longer, that makes roaming profiles considerably less useful, even if they continue to exist.

    Thursday, May 10, 2018 12:58 PM
  • Sorry to wake this thread again, but this was an interesting approach you took and I commend your effort in creating something to fill the gaps where Microsoft has failed to.

    I was just curious how you mitigated "last write wins" with this scenario, where a user might be logged on to workstation A, then log on to workstation B, change a preference, log off workstation B, and return to workstation A, logging off at the end of the day. Wouldn't workstation A still overwrite the profile modified earlier by workstation B?
    Monday, March 18, 2019 1:10 PM
  • Hi,

    As far as "last write wins" is concerned, we don't see that as a serious problem; more just a thing to be noted. Roaming Profiles also operated on the basis that the profile on the network was a copy of the profile from the PC where you most recently logged out, and SyncProfile is not really any different in that respect.

    However, we do generally advise against logging on to more than one PC at once anyway, especially users with folder redirection enabled for key shell folders (documents, desktop, etc), as you get multiple instances of windows trying to get exclusive access to the desktop.ini files in those folders. It kind of works in the end, but you get a lot of pauses and hangs in Explorer. Given that the users whose profile data we sync with SyncProfile are also the users who are subject to folder redirection, it's best to keep to 1 PC at a time.

    For info, we used SyncProfile successfully during the 2017/18 academic year; are using it again this year with no issues; and intend to stick with it for the foreseeable future and certainly for 2019/20.

    Monday, March 18, 2019 2:19 PM