Production deployment of MS Teams Bot and Azure AD App Registration via TeamsFx Toolkit
Hello, community! Could you please help me to solve the puzzle? I'm developing a multi-tenant SaaS teams bot which I'm going to publish to the Teams Store. This bot will support SSO, we need to get access to some of the Graph resources on behalf of the users (calendar specifically). So the default behavior of Teams Toolkit Extension for VS Code is to use two accounts for: Computing. Where all execution logic, BotService, etc will be deployed M365 account. Where the AAD App Registration is created and the teams bot is sideloaded to the specified teams account. And for the M365 account during development, the recommended way is to use Microsoft 365 Developer Program. And as far as I understand for single-tenant applications the right way is to use the account of the administrator of that tenant. We don't find any documentation on the right way to configure the TeamsFx toolkit for the multi-tenant production bot, as far as: developer account will expire in 90 days and it's non-sense to rely on the idea it will be auto-prolonged we don't need to install automatically our bot to this single-tenant as far as its purpose is to be used within any organization, not within ours. And we have multiple ideas on how to solve it: Create an M365 account for our organization and deploy the App Registration via Teams Toolkit. What's the reason we need additional account for only AAD App Registration, isn't it just another resource within Azure Cloud? Deploy everything to the single Azure Account, the same where computing occurs. Does it require us to avoid TeamsFx deployment strategy and build our own? Or there're some options to make it work out of the box? What's the recommended way and tools for multi-tenant SaaS bot with SSO production deployment ? Is there any documentation that I missed?
Azure IoT development and production environments
Hi, My Azure IoT platform is currently running successfully and before the official launch I would like to make the most appropriate changes in order to set up a development/test environment in parallel to the production one. Our current system is based on DPS, IoT Hub, CosmoDB, Azure SQL, different App services and function apps. My question is: apart from replicating the required services either based on subscriptions or resource groups, is there any other more optimal approach I could follow? Thanks!Exchanging Experiences - Overview Practice Licensing Windows Server Core LTSC CBB LTSB
Originally Written in Brazilian Portuguese General Objectives of the Article Discuss observations and what would be the best licensing channel options considering critical mission environments. Introduction From Windows Server 2016, Microsoft has made available until the writing year of this article, 3 licensing channels of the Windows Server product family. Looking in general, the items below analyze from the operational point of view the available licensing models to choose from the point of view. LTSC - Long Term Service Channel The mode of licensing and support of products that many organizations are already used to. 5 years of dedicated support + 5 years of extended support. 5 years of dedicated support including support for new feature updates, functions, fault correction packages, improvements, and security with Microsoft through contract or loose call. Near the end of the 5-year period of dedicated support for a product version, a new product version is released. 5 years of extended support, with limited fixes support and support only for critical security features, without caller support with Microsoft. Products from the Windows Server, Windows 10, System Center, Office Server, Developer Tools families are available on this channel and virtually all others that are not "Product as a Service". CBB - Current Branch for Business Focused on fast-released scenarios, served on the Semi Annual Channel model. 6 months of dedicated support + 6 months of extended support. Windows Server, System Center, Windows 10 family products are available on this channel and other products offered in the "Product as a Service" model. LTSB - Long Term Service Branch Focused on scenarios that are not necessary or have limited possibilities for product updates, such as ATMs, Hospital Machines and embedded systems electronics. Update support has a longer delivery range, such as Windows 10 LTSB, updates are delivered at 2-year intervals, without immediate support for DirectX updates and other common resources for daily use, but unusual to limited scenarios. Products from the System Center, Windows 10 families are available on this channel and others to support embedded equipment solutions. Notes Before Using Windows Server Core in Production Before installing the Windows Server product in core mode, a careful observation of the licensing type is required, since depending on the "WorkLoad" that is allocated to the server, application, module, or system, the type of licensing can require applications for build updates that can operate, technically or financially the solution allocated on the server. A licensing version that requires constant updates not supported by the application can compromise the performance or availability of the application or solution, as well as vendor support. A large-period feature upgrade veto may not bring new features or support to essential application APIs. The best scenario is to align product usage with application teams to identify the best appropriate licensing version, analyzing the compliance of the current scenario. Taking into account experiences of operations production environments in critical missiles, services based on solutions such as Microsoft ADDS infrastructure services, Microsoft ADCS Subordinate (Non-Root), Microsoft DNS StandAlone, or Active Directory Based, when allocated to dedicated servers can take advantage of better control and less impact of "Server Core" installation mode with lower support period licensing and fast releases, CBB licensing, provided in High Availability. Implant products with larger scopes, even if they are infrastructure, and that have a higher level of knowledge, specialized companies for the provision of support, may not be good canditadas in the mode of rapid releases, but rather to the channel of longer support period, products such as the System Center family, recently Exchange Server,SharePoint Server, are examples, given the need for documentation and compatibility analysis in heterogeneous environments. Another observation is that the "Server Core" installation mode targets a "Client->Server" consumption model, that is, the server allocates the active load, as expected, but the management tools are executed and allocated, installed, on the client machines of the administrators or remote management infrastructures. "WorkLoad"s, applications that require management via Microsoft RDP for the server that hosts it and that do not have remote-management consoles or that are unable to manage remotely, may not be good canditades to hosting on servers in mode " Server Core." This is an open discussion channel share below the observations and options. Referece: docs.microsoft.com/en-us/windows/deployment/update/waas-overview Originally Written in Brazilian Portuguese
