今年 (2020) 因為 Work from Home (WFH) 的快速興起，微軟 Teams 服務也是一個 WFH 的重要利器，對於一般使用者可能沒有什麼太大的問題，只要申請註冊成 Microsoft Account (利用如: hotmail、outlook、gmail...等 Email 帳戶都可以註冊)，即可開始享受微軟 Teams 服務種種強大的便利性。
但問題來了，因為微軟 Teams 服務本來的設計是給工作或教育帳號使用的，在設計上是綁定 Azure Active Directory (文後簡稱 Azure AD) 來做為驗證、授權...等管理的基礎。
在微軟將 Teams 服務提供免費版本給一般大眾使用的時候，在 Azure AD(目錄) 中就會根據註冊的 Email 帳號再產生一個隨機的 Azure AD(目錄) 來作為處理的機制。
(此為目前自己的認知，若有錯誤會再改正)
近期微軟將旗下的 Power 系列產品: PowerBI、Power Apps、Power Automate、Power Virtual Agent，整合成一套 "Microsoft Power Platform" 的解決方案:
(上圖取自微軟 Power Platform 官網介紹)
有需要了解更多的朋友可以直接到微軟的 Power Platform 的網頁 來觀看介紹。
光陰似箭歲月如梭，一年過去了...SSL 憑證剛好要更新，順便(?)也更換到另外一個網域中。
如果不知道如何設定網域 SSL 的捧友，請看:
今天要處理的問題是，把已綁定到某個網域的 SSL 憑證，綁到另外一個網域上，所以...就開始來動手做吧😎
自從 Microsoft 推出地圖服務到目前為止，曾歷經了相當多的改朝換代的地圖服務方式，在此不論過去的功過，先把目光投向 Azure 上近期推出的其中一項雲端的 PaaS 服務: Azure Maps。
Azure Maps 所提供的服務當中，也提供了室內地圖 (Indoor Maps) 的部分，讓地圖的應用不再侷限於室外資訊的使用，而是可以朝向室內來發展，例如: 在停車場當中車道與車位佔用資訊、展場或市集的攤位販售資訊、辦公大樓的各會議室資訊是否使用中(或其溫度、濕度狀況監控)...等，這些都可以進一步協助應用廠商，完成在某個室內地域中處理其資訊的最後一哩路，讓使用者在獲取地域資料上能更加透明與便利。
其詳細介紹可參閱微軟提供的 Blog:
https://azure.microsoft.com/zh-tw/blog/azure-maps-creator-now-available-in-preview/
自從 Microsoft 推出地圖服務到目前為止，曾歷經了相當多的改朝換代的地圖服務方式，在此不論過去的功過，先把目光投向 Azure 上近期推出的其中一項雲端的 PaaS 服務: Azure Maps。
Azure Maps 所提供的服務當中，也提供了室內地圖 (Indoor Maps) 的部分，讓地圖的應用不再侷限於室外資訊的使用，而是可以朝向室內來發展，例如: 在停車場當中車道與車位佔用資訊、展場或市集的攤位販售資訊、辦公大樓的各會議室資訊是否使用中(或其溫度、濕度狀況監控)...等，這些都可以進一步協助應用廠商，完成在某個室內地域中處理其資訊的最後一哩路，讓使用者在獲取地域資料上能更加透明與便利。
其詳細介紹可參閱微軟提供的 Blog:
https://azure.microsoft.com/zh-tw/blog/azure-maps-creator-now-available-in-preview/
自從 Microsoft 推出地圖服務到目前為止，曾歷經了相當多的改朝換代的地圖服務方式，在此不論過去的功過，先把目光投向 Azure 上近期推出的其中一項雲端的 PaaS 服務: Azure Maps。
Azure Maps 所提供的服務當中，也提供了室內地圖 (Indoor Maps) 的部分，讓地圖的應用不再侷限於室外資訊的使用，而是可以朝向室內來發展，例如: 在停車場當中車道與車位佔用資訊、展場或市集的攤位販售資訊、辦公大樓的各會議室資訊是否使用中(或其溫度、濕度狀況監控)...等，這些都可以進一步協助應用廠商，完成在某個室內地域中處理其資訊的最後一哩路，讓使用者在獲取地域資料上能更加透明與便利。
其詳細介紹可參閱微軟提供的 Blog:
https://azure.microsoft.com/zh-tw/blog/azure-maps-creator-now-available-in-preview/
有一天，突然某個手上的專案上線後需要提供部分資料給 End User 下載，放在 Azure 的 Storage 中 Blob 裡的資料也是都有供外部直接存取的 URL 沒錯，但直接給 End User 類似 "<xxxxxxx>.blob.core.windows.net" 網域開頭的網址來下載檔案好像也怪怪的(個人心理因素，資安上有無風險考量不確定)。
於是就查了一下資料...
結論是可以在 Azure 的 Storage 中綁定自訂(子)網域的，於是不囉嗦...就是開始動手進行綁定了😅
在 「替 Azure 的 App Service 網站設定自訂網域後掛上 SSL 憑證 (上)」 的篇章中，有提到如果購買憑證跟購買網域的單位、組織、或負責處理的人是不同的，會遭遇到驗證網域控制權的問題。
上圖黃標字寫了特別提醒，結果...有一天就遇上了😥
就說做人不要鐵齒了吧!
如果 AppCenter 的額度預算能有 "半無限大" 的話(?)，在 Xamarin 的開發上為了能夠 "感謝飛天小女警的努力，開發的世界又和平的度過了一天" 🙆♀️
通常可以在 Android 的開發過程中，選擇讓 iOS 能讓 AppCenter 自動化建置，以便確認在某些環節上 iOS 的版本是否有遺漏了什麼，才不會導致於後面要補 iOS 的部分時，不知道該從何處下手。
畢竟會選擇使用 Xamarin 技術開發 App 的話，通常是伴隨著希望雙平台的 App 的誕生。但由於一切的資源都是有限的，開發上會先選擇單一平台先進行到某種層次上的段落後(又通常會先選擇 Android 來進行)，再來補上另一個平台的部分。
此時有 AppCenter 來協助進行相關的建置紀錄的話，會讓開發上有著相當程度的追蹤過程，本篇文章就是在這樣的觀點下而生的~~~
AppCenter 除了很多好處之外，更是一個讓 App 在佈版上更為方便的平台。若是在開發團隊能導入使用的話，就能讓開發好的 App 在要佈署給測試人員時能更加的便捷。
本篇就來看看 AppCenter 在開發端這邊針對 Android 的環境設定，要如何做最基本的自動建置與更版，快速地讓測試人員取得新版本的測試 App 吧~~~
AppCenter 除了很多好處之外，更是一個讓 App 在佈版上更為方便的平台。若是在開發團隊能導入使用的話，就能讓 App 要佈署給測試人員時更加的便捷。
本篇就來看看 AppCenter 在 Android 的測試人員這方面，如何做基本的接受邀請，快速地進行測試 App 的取得部分吧~~~
因為在測試使用 Microsoft EM + S 的 E5 試用時，要測試 Office 365 中的 Excahange Online 功能，這才發現 Microsoft EM + S 的 E5 授權不包含其相關功能...冏
難怪怎麼在 Outlook App 當中登入帳號都無法連線到 Exchange Online 呢(菸~~~
後來再認真的看了看相關的授權，如果選擇 Office 365 的 E1、E3 或 E5 授權，又或者選擇使用 Microsoft 365 的 E3 或 E5 授權，跟原本已啟用 Microsoft EM + S 的 E5 授權有 Office 365 服務的功能重複。
在這兩篇文章當中有
一個必要條件:
兩個網址要使用:
三個觀念要知道:
以上都捧友都清楚的話，即可繼續閱讀本文...
在這兩篇文章當中有
一個必要條件:
兩個網址要使用:
三個觀念要知道:
以上都捧友都清楚的話，即可繼續閱讀本文...
若網站是 Host 在 Azure 的 PaaS 服務的 App Service 中，要綁定所指定網域到該 "App Service" 的 "Web 應用程式" ，可透由本篇文章所記錄之步驟完成。
要繼續閱讀本文並完成的必要條件:
還有已閱畢 "替 Azure 的 App Service 網站設定自訂網域後掛上 SSL 憑證 (上)" 的內容，那就可以繼續了，Go!
現在網站不掛上 SSL 憑證作網路加密安全性連線的話，那你的網站只會被檯面上列的出來科技龍頭們(如: Microsoft, Google, Apple, Amazon...等)排擠。
原因很簡單，因為沒有掛上 SSL 憑證替網站作加密安全性連線，那對使用該網站的用戶們來相對來說就是屬於高風險網站，為了保護用戶的資料安全性，替網站掛上 SSL 憑證作加密連線是網站自身一件責無旁貸的事。
但對於一些小企業主或小規模網站來說，要買 SSL 憑證掛到網站上做加密連線確實是一筆不小的花費，如果每年真的擠不出這樣的預算購買憑證，是可以考慮使用 Let's Encrypt SSL 等服務，佛心提供的 SSL 憑證方式來處理。
而若網站又剛好有 Host 在 Azure 的 App Service 上的話...
