This message was deleted.
# citrix-cloud
s
This message was deleted.
r
Storefront store’s favorites. By the name of the entry for delivery controllers. So you would need to change the name of the controller entry to what you used before w the onprem controllers
Or you coukd export all the favs modify them and import again
c
Pretty sure the Name of the controller entry is unchanged on the SF store I only edited the values of the controllers eg removed ifvmonprem01.corp.com and added ifvmcloudcc01.corp.com
this the entry you are on about ? if so i purposely left that unchanged as had issues in past with replication of stores if name doesn't match
r
Yes
c
Not sure what has happened then as the name is exactly how it was as i didn't modify it 😞 i have confirmed from citrix storefront documentation / backed up storefront configuration the name is exactly the same
The only other i thing i did was onboard the on prem storefront servers to citrix performance analytics using the provided PowerShell script
o
As far as I know those are stored as local files or the SQL Express method but either way i set expectations of resubscribe to manual favs after migration. Keeping tha display name the same was key on prem when swapping out as that is tied to those local XML files I think they are where those "favorites" are stored but don't think I have seen workspace look at that even if using storefront for access plane after migration.
c
Yeah it strange how it lost the user subscriptions when the display name of the controllers on the store didn't change
r
If you export the favorites does the data still look like it should work
c
Will give it a try now
data looks ok over 100k entries (24MB txt file) with Sid/Name label /Appname / Guid / Subscribed and position here is an example from the export S-1-5-21-966205532-1977663930-808559644-8591 Suez712.Windows Explorer C5D6F80FE5E0A4C23DE033F214476662 subscribed dazzle:position S
r
wiht your account add a favorite and compare it to whats in the data you have
might let you know whats different
the data can be manipulated and re importted if you need to
c
So export , add a new favourite on SF for a app I haven't subscribed to, export again and look for the newly subscribed app for my sid to see if anything is different than what is in the 1st export?
r
yes see if for exampel the guid is different or the app name
👍 1
will hopefullyy show whats different/changed
j
@Oz Zy didn't we have this issue on a project after moving the apps to cloud with ACT? Could have sworn there was an ID change on the actual app itself when migrating to Cloud or something like that, it's at the edge of my brain and I can't pic what it was - @Shane Kleinert do you recall? Some AppName specific something or other?
o
Yes pretty sure we ran into it and I have it on another as well so basically just been positioning that this would happen at this point as they are seen as different apps or something.i cant remember exactly what it was
j
Yeah subscriptions have always been a pain. Supposedly better when in SQL but I never went that path
c
I added an app called Mailcfg to my favourites and exported the subscriptions from Storefront The farm name/delivery controller name "Suez712" is identical to my other subscriptions and was the original name (I never changed this i only removed the on prem controllers and added the Cloud connectors). Unfortunately i dont have a subscription export prior to the change for comparison S-1-5-21-966205532-1977663930-808559644-62765 Suez712.Mailcfg 4A29EC5298C249D2C8EF19330AC5157E subscribed dazzle:position n position n S-1-5-21-966205532-1977663930-808559644-62765 Suez712.Manage Printers D1EB4D781147B85AC56EA7E8F0302375 subscribed dazzle:position 7
this is only phase 1 of the project (keeping SF/ADC on prem ) phase 2 i am getting rid of the on prem Storefront servers and moving to workspace service so they would of lost their subscriptions anyways as never heard or seen of a migration from SF to workspace service for the subscriptions
r
Look for another user wiht the same favorite
👍 1
c
just did that and nothing standing out it looks like all user have different GUIDS for the same app it doesnt look like it has anything unique apart from the Farm name/Delivery controller name on the Store "Suez712" in my case Line 56369: S-1-5-21-966205532-1977663930-808559644-39425 Suez712.Clear-net BB5DFC6486FFB41E21C03B2CA23478A1 subscribed dazzle:position S position S Line 56439: S-1-5-21-966205532-1977663930-808559644-39426 Suez712.Clear-net 10046F692582FFFD44518F2C827279BF subscribed dazzle:position U position U Line 56617: S-1-5-21-966205532-1977663930-808559644-39458 Suez712.Clear-net 6496131878291EF6494A7D88E0B40E90 subscribed dazzle:position O position O
r
Im not sure what you are saying but the Farm Name/Delivery Controller name needs to be the same which I think you said it was. I dont think the guid is used for anything so it really doesnt make sense why if the arm name has not changed nd the resource-id is the same why it woudnt work. Maybe all the resource ids have changed? If thats the case you may be able to script an update
c
yeah farm name/delivery controller name was untouched on the storefront stores and not changed while cutting over storefront from on prem DDC's to citrix cloud connectors. The applications was imported into citrix cloud with the same names and config using the ACT i didn't add a prefix ect. The resource-id in the subscription export file for all apps is called "Suez712" which is the same name as the Farn name/Delivery controller name which i didn't change on the storefront stores. I dont have a export of the subscriptions prior to the change or a historical export so i cant check if they had a different resource-id name but presume its the same as it gets it from the farm name/ delivery controller name so i would expect it to be "Suez712"
r
Yea the app part in your example would be the "clear-net" and assuming that is the same along wiht the Suex712 i would think the favorite should work.