RexP0wer's Posts

I was able to fix this issue. The problem was the scheduled (logon-triggered) tasks running under the Admin.NBName account. Once one of these tasks started, the SID of the Admin.NBName would be loade... See more...
I was able to fix this issue. The problem was the scheduled (logon-triggered) tasks running under the Admin.NBName account. Once one of these tasks started, the SID of the Admin.NBName would be loaded under HKEY_USERS and AppVol virtualization would capture both HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileGuid & HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileGuid. Since the Admin.NBName SID already existed on the master image, a SID-bak key would be created and the SID key would then get one of these new TEMP paths. The solution was to convert the scheduled tasks to run under the SYSTEM account, which took some work for the task that was accessing UNC paths and changing AD attributes. After I had converted the tasks to SYSTEM tasks, I was able to completely remove the Admin.NBName profile from the master image.  No more problem.
Thanks popvm.  We considered FSLogix about a year ago, but got too sweet an offer not to go with App Volumes.  I have seen others echo your sentiments in forums like this.  But for now, the overall p... See more...
Thanks popvm.  We considered FSLogix about a year ago, but got too sweet an offer not to go with App Volumes.  I have seen others echo your sentiments in forums like this.  But for now, the overall performance we've had with AV Writable Volumes has been good. For though moment, I'm confident that there's a workaround (should one be necessary). But I do appreciate your input.  Thanks
We are in the process of migrating from roaming user profiles to VMware App Volumes (ver. 4.3) writable volumes and we are also using VMware DEM (ver. 2009) with View 7.13 (linked-clones, floating as... See more...
We are in the process of migrating from roaming user profiles to VMware App Volumes (ver. 4.3) writable volumes and we are also using VMware DEM (ver. 2009) with View 7.13 (linked-clones, floating assignment) I have a case open for my question below with VMware but they haven't been helpful so far. On my View Master Image, I have a domain admin account, Admin.NBName (in this example, NBName is the NetBios domain name) that I use for scheduled tasks that run after a user logs on to the View desktop. (one of these scheduled tasks checks for the successful load of the user's roaming profile and the successful attachment of their Writable Volume, logs this to a UNC path file and then removes the user's roaming profile attribute from their AD account). What I'm seeing with some of my users, is an accumulation of very small (2.9 MB) directories in their Writable's SVROOT\Users directory along with their SVROOT\Users\<username> directory. For example, SVROOT\Users\Admin.NBName, SVROOT\Users\Admin.NBName.000, SVROOT\Users\Admin.NBName.001, SVROOT\Users\Admin.NBName.002 etc, or SVROOT\Users\TEMP, SVROOT\Users\TEMP.NBName, SVROOT\Users\TEMP.NBName.000, SVROOT\Users\TEMP.NBName.001, SVROOT\Users\TEMP.NBName.002, etc. These directories will have the Admin.NBName's NTUser.Dat Some users will have combos of both, some might jsut have lots of TEMP directories. If I mount their writable, I can see that snapvol.dat has references in MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileGuid to these Admin or TEMP directories. The SID of this domain admin (Admin.NBName) will instead point to C:\Users\TEMP or one of the other variants listed above. I'm assuming that this is partly due to the line, virtualize_registry=\REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileGuid which is in my snapvol.cfg file. I feel like this line is not doing me any good, but I can't find any guidance one way or another about whether to lose this. I've only been using AppVolumes for about 6 months, but this seems sub-optimal. Should I be concerned about this? My snapvol.cfg file virtualizes \Users I'd like it to only virtualize \Users\<username> but all my tests with this (virtualize=\Users\%USERNAME%) have been disasters. I am also aware of AppVolumes custom batch scripts capabilities but I can't find any examples of these and don't know whether I could even use them to clean up directories like these. I also have not found anything in the svservice.log to show my why this is happening, is their some means of capturing this info? Has anyone else encountered this?
Thanks Ivan. I have been using Application Profiler and some of the other links you've provided (last week a VMware engineer pointed me to https://www.ivandemes.com/uemtemplates/alluemtemplates.p... See more...
Thanks Ivan. I have been using Application Profiler and some of the other links you've provided (last week a VMware engineer pointed me to https://www.ivandemes.com/uemtemplates/alluemtemplates.php ) . I guess I was hoping for the migration from roaming profiles to DEM to be less labor intensive for me. We've got 1500 users who've got all sorts of wild customizations in their Ntuser.dat and their %appdata% directories and to date (the last 4 years I've been working at this place) I haven't had to worry about that. Now the bill is coming due.  Thanks for all your help and patience, I think it's on me now. Mike
Wow, that really does help, Ivan.  All of VMware's guides tout local profiles, but none explicitly mention the default user profile. I keep thinking of questions, so here's another.  One of th... See more...
Wow, that really does help, Ivan.  All of VMware's guides tout local profiles, but none explicitly mention the default user profile. I keep thinking of questions, so here's another.  One of the pluses of our roaming profiles, was that if a user made a change or customization that wrote to their HKCU, this would get saved in their NTuser.dat, and said setting would persist across View desktops.  It seems counter productive to save all the user's HKCU (or even HKCU\Software) in DEM, so short of figuring out all the various registry locations (like HKCU\Software\ODBC\ODBC.INI) that I'll need to explicitly import\export in DEM, is there some other method for DEM to grab these sorts of user customizations? getting closer, Mike
Thanks Ivan.  Each day I'm starting to understand more.  I figured out, shortly after my post, that I could not use the ntuser.dat at all in DEM. I also know how to use ntuser.man but we don't wa... See more...
Thanks Ivan.  Each day I'm starting to understand more.  I figured out, shortly after my post, that I could not use the ntuser.dat at all in DEM. I also know how to use ntuser.man but we don't want to use mandatory profiles.  I am familiar as well with VMware's OSOT.  But when you and others say use a local profile, it seems you don't mean the equivalent of a local profile living on the linked-clone floating assignment View desktop (Or do you, by enhancing the Default User local profile?). When users log on with their roaming profile, the roaming profile folder structure and the ntuser.dat are used to build that profile and that profile is not treated as new by the OS.  However, if I log in with my current DEM configuration (still a work in progress) (no ntuser.dat or ntuser.man), then, after the welcome message, I see "Preparing Windows" and my profile on the View desktop is treated as a newly created profile, so, for example, OneDriveSetup.exe runs each time (I know there's a post in this forum about that issue) with DEM but not with roaming profiles. Is there a way around the "new profile" issue? Or is that part of DEM and as long as you build your DEM configuration correctly, it shouldn't really matter. Thanks Mike
HI all, we're starting out with DEM (5 days ago) in our Horizon View (7.10) Linked-Clone, Floating Assignment Pool. Right now most of our users are still using roaming profiles with it's accompan... See more...
HI all, we're starting out with DEM (5 days ago) in our Horizon View (7.10) Linked-Clone, Floating Assignment Pool. Right now most of our users are still using roaming profiles with it's accompanying NTuser.dat file.  We've got a small test pool where we've installed DEM.  So far it's working as advertised regarding Office 365 and LocalAppData settings.  But I can't for the life of me figure out how to get the same functionality of roaming profile\NTuser.dat.  I tried creating an NTuser.dat app in DEM to pair down and import\export a modified ntuser.dat but the logs show that this is failing and all the reading I've done indicates I shouldn't be doing this. I understand that as I create more and more application templates in DEM these will help replace the ntuser.dat, but how do I get there in a timely fashion.  Also we've got over 1500 users, so I've got to have a way of streamlining and automating this.  Can anyone help me? Thanks, DEM Newbie