MicrosoftCDeeethe private store is functionally dead for users since it doesn't exist in the store app anymore. Restricting users down to private store only will result in the store being blocked for them. No apps whatsoever. The other option is to remove restrictions and they can install any public app. We didn't want that.. so moved on with the below to get the Company Portal out there.
In our situation, we had 2/3 of our environment already enrolled in Intune (and co-managed with SCCM) by whiteglove deployment.
We've had to expedite a change to get the legacy fleet enrolled in Intune. That was easy in SCCM; just expanding the co-management scope to include the additional devices. There are other mechanism to get the corporate Intune enrolment done, as long as all the prerequisites are in place.
Following that was simply creating a Azure AD dynamic security group to include the correct device scope, and assigning the Company Portal app to this group as required from Intune. When adding the store app in Intune, I'd recommend using the app type "Microsoft Store app (new)", and not the "Microsoft Store app (legacy)" which is being deprecated.
Clients automatically receive the Microsoft Intune Management Extension. It can take a while for store apps to flow through and I'd recommend a reboot after the Intune enrolment is done to move things along.
One last thought I had.. If you're using a dynamic group and your devices are registered in autopilot, check your dynamic rule config. Autopilot devices have 2 device records in Azure AD; One is specifically for autopilot and the other is the actual device record which will be enrolled in Intune for example. You want to ensure the correct device is in scope.
Other than that, you can drill down on a device in Intune, go to managed apps and see the app deployment status (and any returned errors). Locally on a device you can check the Intune Management Extension logs.
