My app got bumped from the Chrome store and it looks like it needs to be moved to the g suite marketplace. I started the configuration process and right away at the top it says "your account does not belong to the same domain as this cloud project or app". This application was written under my incubator company then a new company was spun up and the app was moved over. But the operations and startup of the application for many years was under the original domain. I can't migrate the google side of the application/oauth/etc over without seriously impacting my business customers. But I own both domains. I can't seem to proceed and I'm thinking this may be why. What can I do? I need to get this app installed at several new customer's locations.
Related
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.
I have a SAML-enabled web app, and many of our customers use G Suite as an identity provider. We have been working with each of them to set up a custom SAML app so they can use G Suite to SSO onto our app, but we would really like to be listed as a pre-integrated app, as described in the blog and the support docs.
After hours of independent searching and chatting with G Suite support, I've been unable to find any sort of application form to get my app listed. This process was really straightforward with IdPs like Okta, Azure ADFS, etc... and I can't for the life of me figure out how to do it for G Suite. Any guidance would be greatly appreciated.
After cycling through 3 different G Suite support reps, eventually one connected me to a different G Suite support rep who emailed me a link to a Google form where I submitted the details of my request. Evidently I'll hear back sometime in the next month. I would link the form here but I don't want to run afoul of the powers that be while my submission is still under review ;)
I have a quite extensive application running under Azure.
As part of the operational management of the application, I have a set of Application Insight instances to provide monitoring, tracking and logging.
The overall application consists of three ASP.NET MVC websites and a Worker Role. Additionally, I have three instances ("environments") of the application overall deployed (QA, UAT and Production).
I noticed a while back that for one of the App Insight instances (for the same MVC website across all environments) it was quite heavy on the number of Dependency data points that is being collected. Specifically, this is causing me to exceed the 5 million data points included in the monthly quota.
Noting this, I changed the Web Tests (for availability) to hit a different endpoint (one that doesn't invoke the dependencies).
However, I am still seeing the old endpoint being hit.
Digging a little further into this, I believe that I have an old rogue Web Test that is still active, and still hitting the old endpoint.
Issue is - I can't find it.
Is there a way to query, even if via the Powershell Cmdlets, the subscription in an attempt to find this? I've trawled through the portal and cannot see it anywhere.
Could this be the "Proactive Detection" feature? If so, can you change the endpoint it monitors?
You should definitely open a support ticket with us. Check out the dev support options and look at either option 3 or 4. It's preferred you open a support ticket via Azure with a support plan (option 3) if you have one. But, if you don't have a support plan check out option 4 and you can get in contact with us that way.
I've been ramping up on Azure Mobile Services over the past week. There are definitely some PROs and CONs in using them over a standard Azure Web Site where I can write APIs that hit SQL DB, etc.
One of the biggest negatives I see is developing the server side code and DB structures ON THE SERVER. I've watched lots of videos from launch and beyond, read lots of blog posts about tips and tricks around WAMS, but nobody seems to talk about the downside of developing the code (server scripts) and database structures on the server, at your live URL.
This is all great for developing the first version of your mobile app and associated mobile services. But once it's all deployed, how do you ever build version 2? Real apps hitting real APIs and data, but now I want to develop/change/play with the server scripts and database schema?
With Azure Web Sites, I can develop locally and only publish code and DB changes to the server on my schedule.
Have any of you seen or heard of the "v2 development story" around Azure Mobile Services?
Only thing I can think of would be to create another set of tables and APIs around them, most likely "virtual tables" that allow me to write APIs against the original set of data. Seems like a huge hassle, since the client code would now have to know about the original set of tables and the new set of tables... that's only for v2...
Thanks for any thoughts / insight.
You should have two services, one dev and one production and use scripts to promote your code from dev to production (pretty similar to how most workflows go, in moving from a test setup to a production one).
http://channel9.msdn.com/Events/Build/2013/3-511
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