This message was deleted.
# microsoft-fslogix
s
This message was deleted.
r
Depends. If you are going between different profile versions, i would either build new profiles, or use something like VUEM to export the data and import it into the new profile. Otherwise, I have had good success with David Ott's script from citrixirc.com
d
Same profile versions, just a straight migration from UPM to FSLogix, if I end up going down that path. Been having tons of issues with UPM and Windows Search Roaming and hoping that FSLogix will be better behaved since everyone seems to use it and have better experiences with it. New profiles may help solve some issues, but users may revolt having to reset things.
r
Yeah, user revolt is a real thing. I've had success with this script https://www.citrixirc.com/citrix-upm-profiles-to-fslogix-profiles-conversion-powershell-script/
What OS? Because if 2019? fuggedaboutit.
d
2016 and 2019. What do you mean? I'm reading that as there is no fixing Roaming Search issues. šŸ™‚
o
Try the direct conversion and see. In my experience we had users having issues with the WIndows 2016 Start Menu, but everything else was fine.
r
Ah yes, sorry man, I forgot about yours @Osiris Amanpour. Yours probably has more development.
@Dennis Parker It's supposed to be fixed in OS 2022
We've had a couple confirmations here. @Kasper Johansen I believe was the first one to test it?
šŸ‘ 1
d
Don't use the start menu, everything is published apps, so that shouldn't be terrible here. @Osiris Amanpour I saw it and it does look the most complete. Looking at it a bit closer again now and it looks like it should work. Mostly pathing changes from what I see. @Ryan Gallier Thanks for the feedback on Windows Search. Microsoft and Citrix claim it should work and there are no issues.
o
just note that the script must run locally on the server hosting the FSLogix profiles, as diskpart won't accept network paths for mounting VHDs.
d
Yep, I read that. Makes sense. Shouldn't be an issue.
I'm gonna give is a shot on a couple co-workers and see how it turns out. šŸ™‚
o
It should work out of the box. But if you have any issue let me know.
d
Thanks. I will let you know.
Servers where I need to run this from don't and won't have ActiveDirectory module so I worked around by adding/changing like this:
$ADDC = "<http://DC.LOCAL.COM|DC.LOCAL.COM>"
$cred = Get-Credential
Foreach ($user in $users) {
#Variables definition - please note that the samaccountname must be in lowercase!
$sam = $user
$sid = Invoke-Command -ComputerName $ADDC -ScriptBlock { param($sam) Get-Aduser $sam } -ArgumentList ($sam) -Credential $cred
o
Do you get the SID from this?
d
Yes the next line pulls the SID out of the return. Nothing changed there.
$sid = $sid.SID
o
Ok good
d
If we weren't using UPM profile containers, this works great. Now to figure out how to merge them in at the same time..
o
this would require an extra script. never used the UPM containers but can you open them with diskpart?
If yes then I would use a script to copy the container locally, open it, and robocopy the content out
d
Yeah, it's going to be the same basic mount the VHDX via diskpart and robocopy the content out process.
o
yes, I would do that
so you need to have the FSLogix mounted on one side, and the UPM mounted on the other side, and robocopy. I use a mount folder so you can mount multiple disks.
d
IIRC I'll need a second mount folder for the profile disk to mount to but I think I understand the process.
o
yes that's why I don't use drive letters, I use folders instead.
d
Yeah, drive letters caused issues in the past because they didn't clean up until restart when I was working on a different script. That script didn't use diskpart to do the mounts though so it may not have the same issue.
o
there is an fslogix executable to just mount disks IIRC, but at the time it wasn't working well and not reliable.
d
The diskpart isn't so bad. Just had to figure out that CUPM uses partition 2 for the data in the profile container and Profiles with the s instead of Profile like FSlogix. Then getting the data out via robocopy was easy enough.
šŸ‘ 1
j
@Dennis Parker search is a jerk and has been for a long time. You might get better support from Citrix on resolving those issues with Citrix profiles than you will from Microsoft - looping in @Anthony Shi for visibility. Fslogix no longer do anything with windows search as Microsoft have made it OS native for roaming, but Citrix still play around with the original method as well I believe
d
We have been feeling the pains of Search for quite some time. Microsoft keeps making changes to it with patches as well and it breaks. A good many of may be with UPM dismounting and corrupting the search index. 2019 Server search using Microsoft native has been slightly more stable than Citrix Roaming Search. I haven't been able to get good support from Citrix because issues with the recent (not the most recent at this time) VDAs prevented us from being at a current and thus supported level and Citrix Support wasn't really willing to assist when not current. I have been running FSLogix on a few users for a few days and the dismount/mount and logoff/logon times compared to Citrix UPM with Profile Containers and roaming files are significantly improved. I am hoping that Search is somewhat improved. Also FSLogix appears to actually have a Search Reset tool that, assuming it works, will help when there is corruption in the search DB. Maybe I'm wrong on that part as well...I'm just looking to make things better as users are suffering. FSLogix does 2016 Search Roaming as well, so I think I'll be slightly better off than Citrix there as well. Maybe I'm going about things the wrong way but it seems that the community prefers FSLogix over Citrix UPM and there must be a reason for that in the long run, right?
But the current known issue does give me pause for FSLogix as well. It's a pretty huge issue, and is/was discussed in another thread already. https://learn.microsoft.com/en-gb/fslogix/troubleshooting-known-issues#azure-ad-authentication-for-applications
j
So I don't think for a second you are going about it the wrong way, anything you can do to make users life better is where we all end up heading. A couple of points though • FSLogix was so crazy popular and safe because they were the first to do what they did - and search roaming was a massive part of that. Since the Microsoft acquisition however, it is not the FSLogix of old and things are slow to get fixed/dignified/dealt with - Search is in that pile • FSLogix has it's fair share of windows search roaming issues, profile bloat due to indexes going nuts, corruptions on logoff - but on server 2016 you should be able to get it working smoothly - Server 2019 I gave up making promises and haven't been in the field dealing with it for a few months now - i was still putting in the eventID 2 trick across projects • The reason Citrix UPM has some traction and focus at the moment is that it is actively developed, supported and they are very responsive if you can get to the right people (Leverage the CTA and CTP community here). In the container world, they were late to the party, but they are focused and they listen. I don't know if we are far enough along in the journey with Citrix containers to have a preference yet, FSLogix is tried and proven, but Citrix release cadence is bananas - my money is in that camp, but that doesn't mean FSLogix became any less awesome at its core Here are a few links that might help in your Journey • https://jkindon.com/fslogix-containers-search-index-considerations-and-troubleshooting/ (community effort) • https://jkindon.com/windows-search-in-server-2019-and-multi-session-windows-10/ (captures some 2019 BS) • https://jkindon.com/the-evolution-of-citrix-profile-management/ (Tracking UPM)
🄰 1