Transfer ownership of a PowerApp using PowerShell

PowerApps administration capabilities have considerably evolved from where it was and now we can easily transfer the ownership of a specific App using a simple PowerShell command. This article will cover that specific task.



However, If you look at the latest Power Platform Admin center (https://admin.powerplatform.microsoft.com/) you’ll figure out there’s nothing much we could do there as admins, so PowerShell comes again for the rescue.



PowerApps offers two separate PowerShell packages for Creators (a.k.a Makers) and Administrators respectively. Before you can do anything, you need this Admin module installed in your machine.

you can download the NUGPKG manually from the first link, or run the command below to install it directly.

• Microsoft.PowerApps.Administration.PowerShell (For Admins)
• Microsoft.PowerApps.PowerShell 1.0.1 (for creators)

Install-Module -Name Microsoft.PowerApps.Administration.PowerShell -RequiredVersion 2.0.1

Once you have the module installed, the following command will give you an idea of the number of apps created in your environment. This is important so that you can standardize the permissions and accessibility for all your Apps via proper governance.

Before we begin, here’s the first command to login to PowerApp service. Run PowerShell as admin and then execute this.

Add-PowerAppsAccount

This command will list-down all the apps in your environment with basic information for you to understand the App Name, Display Name Current Ownership etc..

Get-AdminPowerApp

To retrieve the current permissions for a specific PowerApp:

Get-AdminPowerAppRoleAssignment -AppName <APP ID>

This will list down the deep down information of a specific app including all assigned permissions for that particular app.

So now that we have all the information, to change ownership, we can either run this simple command and input the details as prompted, or use the full command below. To run this, ensure that you login from the new owner.

Set-AdminPowerAppOwner

If you get this error (Conflict) it means that the app is opened and being edited. Close all the session for this app and try to execute the command again.

This is the full command with all the parameters and inputs are predefined. The new Owner must run this command as it uses the current logged in user to execute the change.

Set-AdminPowerAppOwner -AppName '895a38f1-f3c3-4cb6-a2d4-64b199badb3d' -AppOwner $Global:CurrentSession.userId -EnvironmentName 'Default-f50d5133-e13c-4359-85f6-ef76484f4c32'

That should easily run and change the new Owner. However, the previous owner will still remain as a normal user which allows the new Owner to decide whether to keep remove. As new owner can use the User Interface to manage the app, he can simply manage the permission there.

Resources:

• https://docs.microsoft.com/en-us/power-platform/admin/powerapps-powershell
• https://docs.microsoft.com/en-us/power-platform/admin/environments-overview
• https://www.powershellgallery.com/packages/Microsoft.PowerApps.PowerShell/1.0.1
• https://www.powershellgallery.com/packages/Microsoft.PowerApps.Administration.PowerShell/2.0.1

Advertisement

Implementing Multi-tenancy Infrastructure with SharePoint 2013 (SAAS) – Part 2: Planning for Deployment

– The Step by Step Guidance for Creating SharePoint 2013 Based Multi-Tenant Infrastructure,   Part 2 Planning for Deployment –   

Planning Your Deployment

Seems you are continuing to read from Part 1 of my Article Series.

For sure you will need few days to test the entire Multi-Tenant functionality properly. All the below perspectives are entirely depends on the Product Knowledge and the past experience. Performance is ofcource a major concern as this isn’t a generic setup where a single Web Application and few Site collections will serve requests. In this case we are talking about a Hosting Vendor who will be Providing a Stable, reliable and well performing SharePoint online service for its Clients.

It’s also goes more deeper when we think of Intranet Scenarios. Customer may host their Web Portal or may be Intranet Portal. Intranets needs robust environments as it will be heavy with lots of Services and content. Performance, Storage and Security is a big concern here.

However, there’s no environment stays static so you might need to scale up-out based on the utilization of resources. Specially the storage you won’t be able to stick to the initial when it becomes popular. So the improvements has to be done for sure.

You need to read more on SharePoint Hosting Guides given by Microsoft as I stated in the Part 1.

Test (POC)

Prior to the Production Deployment, It would be a great idea to run this and try out in a POC (Proof of Concept) Setup. A Single Server would be sufficient but multi-Server environment is ideal so you get the real world experience. Unlike generic SharePoint Farm deployment, Multi-tenant Farms are more tricky. You need to Plan a lot which is extremely goes in to the deep dive as down as Hardware, Software, SharePoint Services Allocation, Service Segregation across Servers, Performance Considerations such as Storage (IOPS), Security Requirements (Publishing Through Proxies) etc..

Hosting Tenants – Where the customer Tenants (site Collections) will sit on.

A Single Web Application for all the Site Collections (Tenants) ? Or a dedicated Web Application for Each ?. Well, This thing is entirely depends on how far you will go. Microsoft Does not recommends to Host more than 20 Web Applications per farm. This is a threshold not a Limitation. Yet it is considerable since you are not supposed to exceed the recommended level in these kind of critical real world scenarios.

Planning Backend for Tenants

Basic Idea of this is, whether we are isolating our customer’s site collections Databases or not.

Single Content Database for all ? Not a good idea. Data isolation is a prime concern when we talk about Multi-tenancy and a Dedicated Content DB per tenant would be ideal. When it comes to the scaling perspective, Isolated DB is ideal.

Site Collections and Database Limitations and Recommendations

Isolation is all about Site Collections and Databases. You have to go through Software Boundaries and Limits for SharePoint 2013 during your planning.

Active Directory Perspective

The Isolation also comes from Active Directory side when we talk about Security. Tenant A (Customer A) should not be able to see the users of Tenant B (Customer B). When a user of Tenant A trying to Search another user through the People picker, he should be only able to see the result within his tenant. This is a Security practice which will be implemented via Active Directory Organizational Units (OU).

Users

Where we store our Users is not a matter here. Yes you got it right ! We can use the Active Directory as I have shown in the diagram above. You could use somewhere else to store the users but you got the best place to store them, why somewhere else is depends on your requirements. I would straight go with AD through dedicated OU Concept which is too easy and centralized. I will only need to look after the AD Objects so the windows authentication is way smarter.

URL Considerations

The other Key point to make decision is, URL. How you are going to let your customers to access the site. There are two choices as 1. Ordinary Addressing and 2. HostHeader Site Collections.

Also there can be below possibilities. In this scenario we have to consider that we will provide all these for our customers.

1. Allowing Customers to Create Site Collections under their root
2. We Will provide Content Type Hub, My Sites, Tenant Administration Site

E.g. scenario – Above features may depends on the level of Subscription (feature packs you are setting for the tenant). Yet you need to make sure how these sub site collections are addressed. Take below sample scenario to get an understanding.

Web Application – Root (http://HostingProvider.com/)

Tenant URL – /TenantA

Other Sub Site Collections

/TenantA/CTHUB

/TenantA/MYSites

/TenantA/MySites/Personal

/TenantA/Admin

/TenantA/Sites

Per Tenant There going to be Lots of site collections where each stands there for a specific purpose. This is a hassle to manage with path based concept isn’t it ?. And the critical point is, Performance. Having lots of Managed Paths in a single Web Application will give you performance overhead. The recommended number of Managed paths per Web Application is 20. we can ofcource exceed the number and go for more in here but more you have will more overhead on performance.

Host-header Site Collection is the ideal way to achieve this point. Except few minor drawbacks, it gives excellent capability over the each site collection you can have multiple managed Paths. Even though the Site Collections sits on a single Web Application, doesn’t matter the number of Managed paths (in terms of Web Application wise) per web Application because you are dealing with a separate host-header Site Collection. I would recommend to go with Host Header Site Collections at this point.

Custom Stuff

Why Not !. having a Centralized service portal which allows users to visit and create a tenant themselves will be a handy thing just like Microsoft’s O365. having an armed super-duper backend to run the provisioning of tenants through automated scripts etc.. There’s lot more to talk on this thing so for now let me finish what I started under this topic.

 

Stay Tuned for Part 3 – 6 soon to be Published !

—————— Part 3 – Functionality Tech Preview (What It Really Gives You) ———————————-

—————— Part 4 – Deploying Core Infrastructure (Platform) ————————————————–

—————— Part 5 – Creating Partitioned Service Applications ————————————————-

—————— Part 6 – Creating Tenants and Do some real stuff ————————————————-

Unable to Run PowerShell Scripts on Windows PowerShell–“Execution of scripts is disabled on this system” Error Occurred.

Tried to execute a PowerShell script in one of my test server (windows server 2008 R2) and got an error saying Execution of scripts is disabled on this system.

Note : Basically this policy helps you to prevent untrusted scripts which can be affected to Production/critical environments. you may revert back to default once you done with your scripts if it is and critical server on production in order to prevent untrusted affections.

Running below line on PowerShell fixed the point and PowerShell was back to work.

1. Set-ExecutionPolicy Unrestricted
2. Type ‘Y’ and Enter to agree and proceed

Note : Run below line to revert back the policy setting to default.

Set-ExecutionPolicy Restricted