When you export (e.g. Export-Clixml, or ConvertTo-Json | Set-Content, etc) an OvfConfiguration object, and later import it (e.g. Import-Clixml, or Get-Content | ConvertFrom-Json), the resulting imported object is a Deserialized.VMware.Vim....OvfConfiguration object that fails to work when used with Import-VApp.
Suggesting a simple method to allow a Deserialized config object be usable by Import-VApp. I see a few options:
Import-VApp recognizes the Deserialized object passed as legitimate, accesses needed data anyway or takes care of converting internally, and simply works.
2. Get-OvfConfiguration can alternatively (separate Parameter than the -Ovf ?) take an existing Deserialized OvfConfiguration object and it will convert it and return a valid, working OvfConfiguration object.
3. New cmdlet (Convert-OvfConfiguration?) that takes an existing Deserialized OvfConfiguration object and returns a valid, working OvfConfiguration object.
If this process is exceedingly difficult/impossible for certain data types (i.e.g passwords or somesuch), then I'd think simply documenting that it fails to rehydrate select datatypes would be sufficient. So all simple string/number based Ovfs would still be simple to convert, and any that contain difficult datatypes would just rehydrate with those fields blank and simply have to be set via an extra command before passing to Import-VApp.