Share PowerApps Apps & Connections With Groups - sharepoint

We have a suite of apps we are developing. We have already rolled the app out to about 50 users and have over 200 more. Sharing connections (custom connection & connector) and the apps have become super cumbersome. Long story short, this is a lot of time. Each time we have a new user we have to share 3 apps, 2x connections, and setup access on an internal method we have. We are using SQL, not CDS.
This has been misery. Is there a way to create 1x address that I would share with the Apps/Connection and I would just add users to this group? Would save us time to just add users to the one list. Then access is just shared via this common group. Does anyone know a better method to deploy powerapps like this? We can't share to "everyone". Thanks.

If you have an Azure Active Directory Security Group you can give them access to the connector and powerapp. See: https://powerapps.microsoft.com/en-us/blog/sharing-powerapps-with-multiple-users/
There are some kind of distinctions between Security Groups, Distribution Groups, O365 groups, and on prem vs Azure. I couldn't tell you the difference between them all, but you can follow Microsoft's instructions on how to share a canvas app which will go through some of these different methods of sharing.

Related

MS Azure - Can a single organization have multiple organizations under it?

I'm looking into transitioning all our company systems to MS Azure from our current on-premises setup. We have multiple affiliates operating using their versions of the same system (i.e. a custom built application that is fundamentally the same but is tailor fit to specific business cases/industries.
Is it possible for our mother company to register for MS Azure, and the affiliates exist as separate organizations on that plan? or is each organization required to have its own Azure subscription?
Many Thanks,
Jevb
I saw many different implementations of Azure for companies. Mostly based on per-separate-subscription model, sometimes I saw working with 1 subscription and then splitting teams to Resource Groups, I think it is all up to the company, budgets and goals.
I would recommend to read first these, maybe this will give you some hints how to start and migrate :)
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/reference/azure-scaffold
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/decision-guides/subscriptions/
https://learn.microsoft.com/en-us/azure/governance/management-groups/overview
You can have one tenant for your whole company, and individual subscriptions for each business case. The way that Azure does billing it is nice to split your industries into separate subscriptions until you have a solid tagging strategy in place.
I would highly suggest looking into management groups within Azure as you start to implement policy and RBAC for your individual subscriptions so that you can adhere to security best practices and avoid repeating yourself.
https://learn.microsoft.com/en-us/microsoft-365/enterprise/subscriptions-licenses-accounts-and-tenants-for-microsoft-cloud-offerings?view=o365-worldwide
https://learn.microsoft.com/en-us/azure/governance/management-groups/overview

Should I create a resource group or subscription?

We are a software company so we setup solutions for the other companies. I guess we are not unique in this regards :) so I would like to know if we should create a new subscription each time or just a resource group.
Requirements:
We should be able to bill each customer/project separably
They should be able to take control of their resources easily and move to another company
Managing them should not be a headache
What we have tried
We've tried adding a subscription for each customer. This way, we could just change the admin profile and they could completely move away from us.
The billing is also OK, since we receive a different email for each subscription, but managing them is becoming a real headache.
What I guess could work
From what I read, I guess we could work with resource groups instead of subscriptions and handle the billing part with tags (haven't tried it yet. can we?) but then I'm afraid of not being able to move it to another subscription when they've asked us.
Is it even possible? How easy is that? Does it envolve contacting support?
Has anyone tried it?
I would advise against billing using resource groups and tags. The reports are a real mess and 100% unusable. Also, its a lot of extra work for nothing (seriously, do you care if you have 1 subscription or 10?) and adds no real benefit.
Also, you can move resources across subscriptions of different tenants. Best way of handling this is doing a subscription move. That way you dont have to do anything else. They just link your subscription to another tenant and you are good.
I'm talking from a perspective of administering dozens of subscriptions, and believe me, if you move away from subscriptions to resource groups (as a billing\security boundary) you will get completely devastated by the increased complexity of what you are doing.
In my experience working with organisations that provide similar hosting services to customers, I'd say resource groups is the way to go to avoid too much segregation. It's easier for you to keep control of the resources as well as keeping the cost low if you decide to use shared compute resources such as Application Gateway, DDOS protection, etc.
Bear in mind that depending on what level of permission you're giving to your clients, they might have access to information from other clients, so it's important to come up with a good security and governance plan for the Azure environment and strictly limit what they can access.
Moving things from one subscription to another is easy as long as you're using resources within the supported move list. Check the list below:
https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-move-resources
You don't have to open a ticket with Microsoft to move these resources and the move can be easily done through the portal interface as long as you select all the resources and it's dependencies and you have access to both subscriptions. If your client decides to move their stuff to their own Azure subscription, they will have to give you permission on that. If the resource you're trying to move is not in the supported list, not even Microsoft can move that.
From a billing perspective, I'd say separating by RG and using tags is the way to go as that can be easily filtered in your exported Azure consumption usage report.

How can i transfer the cost of a resource to one of my Bizpark's team member?

We have three developers in my startup and we are members of Microsoft Bizpark.
I am the only back-end developer so i create and control all the resources in our azure portal.
Even though i made the other members as owners of our resources (settings->users) i am still the only one losing credits. I always reach the limit and they always have 150$ left.
Is it possible to transfer the cost of a resource to another member or do i have to create it again from theirs accounts?
Thank you in advance for any response!
I've been using bizspark also, and there is no way to transfer elements between accounts. Depending on the objects you are planning to move, some of them, you will have to create a backup and restore them in the new account.
Basically, you have to create them again. It's a pain, but if you order your components you can get the most out of the 5 accounts wiht 150 usd.

Share data between users in metro application

I would like to create a Metro application that allows a group of people to interact. One person would create data and serve as the owner, and multiple others would be invited in and be allow to modify that data. I heard from Build talks that each Metro application will get per-user Azure storage, but will it be possible to share that data between multiple users? Does anyone have a link they could share where I could research this?
I think that you are confusing SkyDrive with Azure Blob Storage.
SkyDrive
Personal to a Live ID
Not really meant as a base for collaborative work
Azure Blob Storage
You can have public files that anyone can view and update
You can have a lease on file that only allows certain people to edit it
Since you own the Azure account you also control the content
You can learn the basics here
If you want to share private app data between users, the best way to do so would be via a shared server of some sort. You should have a server (running on Azure, Amazon EC2, or anything really) that exposes a REST-ful web service which each application connects to. The shared state then lives on that server.
This is better than trying to use skydrive or some file-based system for storing shared data. With a file on skydrive and multiple users trying to access it, you would run into concurrency issues when more than 1 person tries to write to it.
You don't get Azure with Metro.
With Live you get a free SkyDrive that is a personal cloud storage. Like 10 GB. Can share files but it is via sending an email link. It is not file storage that would readily support a server type application to manage that sharing.
Azure is a cloud platform for file and data sharing. Azure is not free but storage cost is only $0.125 / GB per month. 10 GB = $1.25 / month. Using SkyDrive as shared storage you are giving up a lot of developer and hosting tools that come with Azure to save $1.25 / month.
It looks like there is a more formal definition of this with the updated help now available. They were referring to roaming application data. I found the following links that provide guidance:
http://msdn.microsoft.com/en-us/library/windows/apps/hh464917.aspx
http://msdn.microsoft.com/en-us/library/windows/apps/hh465094.aspx
The general is that a small amount of temporary application data is provided on a per-app, per-user basis. The actual size you get is not detailed, but the guidance is pretty clear - app settings only, no large data sets, and don't use it for instant synchronization. Given this guidance, my plan is not a good one and will change.

Liferay - Choosing Organization vs Portal Instance

We are trying to create a SaS based portal using Liferay 6 for multiple (non related) organizations. And we want to go for a approach where we can generate these organization setup automatically based on user information.
We may require to have separate domains/websites for each organization.
As of now I have thought about two options for this
Portal Instance
Organizations
As per my understanding, i think this can be achieved by both of the above approaches. I would like to know your experience on both of these approaches on following points.
Which one would be easy to administer in long run
Which one can be easily programmed to create new setup automatically.
What about data security related to keeping in one portal instance vs multiple instance (is there any such thing?? not sure)
Any other approach to this?
Simple answer would be Portal Instances, since it was built for multi-tenancy.
Benefits to this approach would be that there would be segregation of data. Each instance maintains its own collection of users, communities, blog entries, etc.
Administration wise, there will be 1 account, the omni-admin, that can access all of these instances. On top that, each instance could have its own administrator that admins that particular instance.
Also, I don't believe using organizations will allow you to have separate domains for them.
Also going forward in Liferay 6.1, Organizations don't have pages only Sites have them, though we can mimic the behaviour with Sites.
Hope this helps.
I'm using Organizations for multiple sites, none of them sees each other, each one have their own users, roles, sections and communities.
Apache and Liferay virtual hosts url's makes the proper redirects to each organization home page.
For the admin I think is easier because in one control panel you can manage everything, or just the "scope" you want.
About using Instances, check the procedure to configurate them and see if you find it possible to create new ones automatically. Not very sure about that for organizations either, but having to touch portal-ext.properties may be worse towards automatization.
Regards

Resources