View 4.6 to 5.0 Upgrade LocalMode desktops

[mobcdi]

I'm starting to plan my upgrade from View 4.6 to View 5 and I have a number of localmode desktops that it would not be practical to have them check in before the upgrade. They are running view agent 4.6. My enviroment is all 4.6 servers

On pg 9 of the View 5.0 upgrade document (EN -000699-00) it says to ask users to check in their local mode desktops before I upgrade the connection server and the transfer server.

Is it possible to upgrade without having to check in localmode desktops?

Would upgrading the agent on the local-mode desktops to view 5 avoid the need to check in the desktops?

What is the reason for checking-back in the local-mode desktops?

[mittim12]

Given that your going to go away from what the upgrade document says I think it would be best to discuss potential issues with VMware support.   You will also probably want to do a dry run yourself to see if you have any issues. 

My thoughts on your questions

1:         I'm sure it's possible and that the installer will simply just upgrade the environment.   I would test to see what the behavior is going to be with the checked out clients.  

2:          I wouldn't do this. 

[mobcdi]

I will open a call with VMware support but also wanted to hear from others who may have been in a similar position.

My reason for asking is that local-mode pool users are not expected to check-in their desktops, they are in essence disposable so if I can avoid checking in desktops it would be a bonus

[mittim12]

Yeah if they are disposable to you then maybe there isn't a need to check it in before the upgrade.   Let us know what support says.  

[mobcdi]

Further Update:

After discussing it with vmware support. The reason for checking back in desktops before upgrading is to avoid issues related to the repository level and avoid issue with data management at the transfer server level.

The recommended procedure is still to check in the desktops before upgraded but  in my case since my desktops policy is to disable replication and disable user check-in there is less risk of corruption as the check-out process is one way. That doesn't negate the risk and support recommended testing before trying it for real. So for my setup its still flying against recommended upgrade procedure but if  I were to carry it out it may work.