How to "promote" Internal application to higher level Organization? - mdm

We're currently using AirWatch to deploy an internal enterprise iOS application. The group deploying the application is set-up as a sub-organization in the parent (something like Parent -> R&D). The R&D organization is only assigned a couple of devices from the parent organization (who has many devices).
The problem is that any Internal applications from the R&D team can't be assigned to devices at the Parent organization level (even by administrators in the Parent organization).
Is there some way that the R&D organization can have the ability to publish new versions of the application and also have it target all devices in the Parent organization?

We have been able to find a way around this by granting additional permissions ("Application Management") at the top level of the organization.
It seems as though it is not possible to distribute an app created by a child organization to the parent unless the account uploading the app is at the top level of the organization (and thus can see and assign to all devices).

Related

Limiting what a team can see and access in Azure DevOps

I am very new to managing Azure DevOps. I have two, what are for me related, questions.
When I create a team within a project - either the first default team or a later added team - what determines the users that are available for me to add to the team?
Within a single project, can I create a team that can see its own area path/board work items, but is not able to see the area paths/boards of other teams in the project? I have an outside firm working on the project and I want them to be able to see the work I assign to them, but not all the rest of the work assigned to internal members of the team. Can I do that within a single Azure DevOps project?
When creating a team, you specify the default level of access (I believe it's normally "Contributor").
Work item access can be limited based on area path.
Keep in mind that Azure DevOps permissions have an order of precedence:
"Allow" means "Allow unless explicitly denied"
"Not set" means "Deny unless explicitly allowed"
"Deny" means "Always deny"
So if you have a user in both Team A and Team B, and you set Team B to have a "Deny" permission for something, that means that the user who is a member of both teams will not be able to access it.

"Blank tabs" on Teams App update deployment (Teams Toolkit)

My Teams app:
multi-tenant
deployed using Teams Toolkit to Azure Storage, CDN enabled with a Custom Domain
in alpha use by internationally distributed organisation (third party, not me), users around the world
the app functionality works fine including multi-tenant
in rapid development so frequent code updates. Very rare manifest updates.
Problem:
I frequently update the app's code and deploy the update to Azure using Teams Toolkit
when I do this users often report 'blank tabs' for a period of time, can be many hours. They see the tab menu but the tab contents are simply blank. Purging the CDN doesn't seem to help.
seems most common using Teams desktop app but also reported using browser and mobile Teams app
I think this may be an issue of code deployment .js files (each of which gets a new filename) not being available to the install, I can sometimes reproduce but very unreliably. Other times I can access the app, using a user account on the client's AAD, successfully from different locations (using a VPN to emulate location).
Previously the app's Custom Domain was managed on Cloudflare's proxy.
I disabled this and implemented Azure CDN.
Users continue to report the problem.
This is very poor user experience.
Does anyone have experience of this or hypotheses on what may be happening?
Thanks.
Would suggest to test one thing first: manually deploy a new code change to Azure storage, with the same storage-CDN-custom domain setup.
See if this also causes the hours delay symptom.
By doing this, if the issue is reproducible, it may indicate that the Azure Storage-CDN configuration needs to be optimized.
Otherwise please share the result and it will help narrow down the root causes.

Setting Shared Query Permissions in Azure DevOps

My team is implementing Azure DevOps 2019 server on prem. There is a requirement to give all valid users permission to create shared queries in all projects. Is it possible to set permissions for shared queries at the collection level?
The permissions for shared queries are managed within the queries itself, and whilst the default permissions allow for the built in Project Administrators (and Project Collection Administrators) group to contribute shared queries, you probably don't want to move everyone into one of those groups.
Instead, you would have to go into each team project, go to the queries, and edit the security on the root:
]
You can then grant permissions by group (built in or custom):
(So above, I've changed the built in "contributors" group to allow them to Contribute to queries, which allows them to create new)
Depending on how many team projects you have or create, will depend how manageable the is as a workaround, but it is safer than making everyone an admin 😉
Query is a project-level function, so if you want to access Shared Queries in Peoject B from Peoject A, it may not be possible.
To access Shared Queries, you need to be a member of the team that has permission to access the query, but the team is limited to the project, so shared queries cannot cross projects.
If you really want to share queries between projects, you can make a feature request here:
Developer Community

Is there a way to create an organization dashboard in Azure DevOps?

Our team is currently using DevOps and are very pleased with how everything is working. We've setup Dashboards in each project that tracks work items and sprints and would like to do the same at the Organization Level. Is there a way to create a master overview of multiple projects in an organization?
Unfortunately we cannot create an organization level dashboard, it's not supported.
We can only create the Team Project level dashboards for teams, please see Add and manage dashboards for details.
However there's already a user voice submitted here to suggest the feature and it's in planned, but based on the response seems no plans to store a dashboard on organization overview. So you can vote it up and add your comments on the existing user voice or submit a new one to suggest the feature...
In our VSTS Feature
Timeline(https://learn.microsoft.com/en-us/vsts/release-notes/), you
see a feature called “Dashboards – Create dashboard separate from a
team” under “Reporting”
This feature will allow you to create a Dashboard that has no
association with the team. This means you don’t need to create a team,
to make a Dashboard. You can create any number of these Dashboards and
share them with who you want.
However, Dashboards will still be stored with a Team Project. So to
address your scenario (cross-team-project Dashboard), you’ll just have
to pick a team project to store the dashboard.
We don’t have immediate plans to store a dashboard outside a team
project.
Our team was dealing with the same problem as yours, and we decided to develop our own dashboard solution at the end.
After using it as an internal tool for several months, we recently made it available as a SaaS.
You may check it out on meercode.io for more information.
Your feedback will be greatly appreciated.
Behind the dashboard widgets are queries, and it is possible to execute those queries across multiple projects.
When you open the query editor, there is a checkbox:
"Query across projects" checkbox (imgur)
This way we created a project in Devops that only contains a dashboard that shows all work items in any project, assigned to or followed by the current user.
That and some nifty colored tiles =)

How can I limit feature visibility in SharePoint 2010?

I have a SharePoint 2010 (farm) solution that contains exactly feature:
The feature is site-scoped.
The feature's visibility is set to "true".
The assembly deployment target is set to "Web Application".
The feature contains one webpart.
After adding this solution to the solution store I can deploy the solution to a specific web application. However, after deploying the solution to exactly ONE web app, the feature is actually visible on ALL site collections! I would assume that the feature should only be visible in site collections hosted by that ONE web app?. Trying to activate the feature and add the webpart to a page will (expectedly) fail in all site collections of other web apps (the assemlby cannot be loaded).
Is that a SP2010 bug? Is there a workaround? I just want to limit the visibility of a feature to specific site collections...
Please help!
Thanks
Jan,
Are all your web apps running on the same WFE server? If you have multiple WFEs, you can do this:
Deploy feature to web app A in WFE A.
You should see the feature in the Site Collection Features of web app A.
Now, go to a web app B in WFE B. When you look at the Site Collection Features in web app B, your feature shouldn't be there.
If your web apps are running on the same server, then they are using the same 14-Hive/TEMPLATES/FEATURES folder. Once you deploy the feature to just one web app on that server, the features-folder is sitting in that server's TEMPLATES/FEATURES folder, which will make the feature visible on the Site Collection Features of all apps in that server.
If you have multiple apps running on the same WFE and if it still your requirement to limit the visiblity of the feature, you may have to look into sandboxed solutions.
Another possiblity is you make the feature hidden (visiblity off--it will never be shown on any Site Collection Features) and just have the SP administrators do command-line/cmdlet deployment of your feature for that one web application.
-Gabe