The Microsoft Partner Network offers its members a wealth of resources to help partners grow their cloud businesses, and we know navigating these resources can seem overwhelming. To help with that, the Cloud Enablement Desk offers partners a guided experience in which a Microsoft specialist identifies your business needs and connects you with the right resources and benefits to build your Microsoft practice.

What is the Cloud Enablement Desk and how can it help me as a partner?

When you engage with the Cloud Enablement Desk, you get access to a Microsoft specialist for 6 months to help you navigate the Microsoft Partner Network, decode your benefits and work toward achieving the milestones that will help you scale your cloud practice. From technical skilling, assistance going to market, or anything in between, Cloud Enablement Desk specialists are there to support the unique needs of your organization.

Examples of Cloud Enablement Desk engagements include:

• Assistance with how to earn a Gold cloud competency and maximize its benefits
• Onboarding your solution to the Microsoft Marketplaces
• Setting up and optimizing your referrals profile
• Facilitated and unlimited one-on-one access to 300-400 level technical resources for pre-sales, proof-of-concept, and deployment assistance
• Co-sell onboarding and tool setup

You’ll check in with your Cloud Enablement specialist at least once a month to facilitate reaching your goals.

Sounds great. How do I get started with the Cloud Enablement Desk?

First, make sure you meet the requirements, which vary based on the level of engagement you’re requesting. To engage with the Cloud Enablement Desk, you must have a Microsoft Partner Network ID. To meet one-on-one with technical and/or marketing experts, you must at least have an Action Pack Subscription or ISV Starter Kit. To onboard to Co-Sell Ready status, you must meet the Co-Sell Ready requirements.

Once you’ve met these requirements, fill out the Partner Nomination Form to nominate yourself for an engagement. For more information about the Microsoft Partner Network and the membership types referred to above, visit partner.microsoft.com.

I’d still like to learn more. Where do I go?

Start by hearing from one of the experts. John Mighell, a Partner Enablement Lead within the Worldwide One Commercial Partner organization, will be talking about the Cloud Enablement Desk through an MPN 101 webinar on August 15, 2018 at 9:30 a.m. PT. Register for the 60-minute session here.

You can also visit the Cloud Enablement Desk site to learn more about the requirements and submit your nomination to engage in the program.

Stay engaged with the Microsoft Partner Network

• Community call schedule
• Blog series
• Yammer group
• YouTube playlist

My grandfather said two things:

An ounce of prevention is worth a pound of manure

Death and taxes are part of life

Planning out a deployment is a good thing.

My best friend would say "No one plans to fail, they just fail to plan"

This will be a 4 part blog is the beginning, with 4 blogs to break out the high level steps, and my experience getting the solution set up.

What do we need for Service Map?

• Azure connectivity
  • Setup Log Analytics workspace on MMA/SCOM agent article
  • Troubleshooting onboarding issues KB,
    • Check for Events in Operations Manager event logs blog
• Computers in scope for visualization
  • What computers (Windows or Linux)
  • Pricing FAQ
• Dependency agent installed on computers
  • Configure
• Azure Service Principal
  • (think of it as an SSH shared key ID/password for Azure Apps to communicate)
  • Docs article

High level steps

1. Install the MMA agent blog
2. Install the dependency agent
3. Configure Azure Service Principal
4. Configure Service Map on SCOM

Maybe the MMA agent is like Venom?
Proof I've watched too many a Marvel movie...

An existential moment perhaps, but the MMA agent can be a bunch of strings stuck from one place to another, monitoring whatever its told to do.

Install MMA agent

If you are running SCOM2016 or above, the MMA agent is built-in with Log Analytics, just configure your workspace

SCOM 2012R2 agent does not have MMA, so download MMA agent from Log Analytics workspace

Azure Portal > Log Analytics > Subscription > Advanced Settings

Click on Windows Servers from Connected Sources to download Windows Agent

Click on Linux Servers from Connected Sources to download Linux Agent

From the Azure Portal (https://ms.portal.azure.com)

Click on Log Analytics, <your subscription >

Click on Advanced Settings

My view defaulted to Connected Sources > Windows Servers

Save the workspace ID and workspace key to notepad/OneNote for later

< Assuming the MMA agent is installed with Log Analytics capability >

Update MMA Agent with Workspace ID and Key

From MMA agent, update the OMS Workspace with the GUID copied to notepad

Click on Start > Control Panel, System and Security > Microsoft Monitoring Agent

Click on Azure Log Analytics (OMS) tab on MMA agent

Click Add

Add Workspace ID and Key to agent

Click OK

Click OK again on MMA properties

Look for the healthy green checkbox'd circle

Troubleshooting Errors in the Operations Manager Event Logs

Blog posts - Verify, 55002

So, this is an entry that has been long in the making.  I have had several customers over the last few years give feedback about our Data Loss Prevention's (DLP) matching requirements, mostly around how they require too much corroborating evidence (in the form of patterns or keywords) to meet their organization's very restrictive policies.

As a little background, Office 365's DLP uses an array of functions, regular expressions, frequency, and keyword matching to arrive at a result.  Many of my customers have very broad breach notification laws regarding personally identifiable information (PII), so they would much rather err on the side of caution with more false positives than let something get through that shouldn't.

For an example of this corroboration, think of a credit card number.  If someone is transmitting a credit card number, they might preface it with something like "here's my CC#".  If we detect keywords like "credit card" or "CC#" in a 300-character proximity to a number that passes the Luhn check, then Office 365 DLP will trip.  But what if someone is sending a spreadsheet of a handful names and numbers with no headers?  That may get through the default DLP templates, since the supporting evidence that the templates are looking for (namely, words like "credit card") isn't present.

This is where the problem arises.

To help resolve this issue, I have created a small rule package (which I am already currently expanding due to other customer requests) that customers can deploy to help with this.

1. First, you need to head over to my TechNet Gallery page or GitHub repo and get the rule package XML file.  It's free (as in beer).
2. Next, you need to connect to the Office 365 Security & Compliance Center PowerShell endpoint:

   $Credential = Get-Credential
   $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $Credential -Authentication Basic -AllowRedirection
   Import-PSSession $Session
   Connect-MsolService -Credential $Credential
   $ComplianceSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.compliance.protection.outlook.com/powershell-liveid -Credential $Credential -Authentication Basic -AllowRedirection
   Import-PSSession $ComplianceSession -AllowClobber

3. Then, you need to import the rule package using the New-DlpSensitiveInformationTypeRulePackage cmdlet:

   New-DlpSensitiveInformationTypeRulePackage -FileData (Get-Content .UndocumentedFeaturesRulePackage.xml -Encoding Byte)

4. After the rule package has been uploaded, navigate to the Security & Compliance Center and select Data Loss Prevention (https://protection.office.com/#/datalossprevention).
   
5. Select + Create a policy.
6. Select Custom and then click Next.
   
7. Enter a name for the policy and click Next.
   
8. Select locations you wish to protect and click Next.
   
9. To configure a basic policy, click the Edit link (you can configure an Advanced policy, too, but we're just going to focus on the basic one for now).
   
10. Under the Add drop-down, select Sensitive info types.
    
11. On the Sensitive info types panel, select the +Add button.
    
12. In the search window on the Sensitive info types panel, click the Publisher column header twice to sort the column and bring the imported templates to the top of the list.
    
13. Select one or more templates.  In this case, we're going to select the Social Security Number Only (Function) and Social Security Number Only (Regular Expression) templates.  I've configured these templates to use both the native Social Security Number function, as well as some custom rules to allow for additional character class inclusions and disapproved/canceled number exclusions.  Click the Add button when finished.
    
14. Click Done to close the Sensitive info types panel.
    
15. Click Save.
    
16. Click Next.
    
17. If you want to enable advanced actions (such as allowing DLP policy overrides), ensure the Detect when content that's being shared contains checkbox and then update the Instances spin control box.  For customers that need to comply with breach notification laws, I'd recommend that you modify the Instances control to 1 (highlighted) to ensure that even a single detection results in DLP being triggered.  Click Next when appropriate options are selected.
    
18. Choose the policy deployment options and then click Next.
    
19. Review the policy settings page and click Create.
    

After the policy has been deployed, you may need to wait 10-15 minutes for the policy to sync throughout the service.  From the end-user perspective, this is what it will look like.

1. Log into either Outlook or OWA and begin to compose a message.  In this case, our triggers were: contains a social security number and sent to someone outside the organization.
   
2. After a little bit (usually about 20-30 seconds after entering content that will trigger DLP), a tool tip will be displayed above the To recipient.
   
3. End users can click the the Learn more link in the tool tip to see what rules they tripped.
   

I've already got a bunch of other templates in the works, so be sure to check back soon!  For information on creating your own DLP templates, check out our support article: https://support.office.com/en-us/article/create-a-custom-sensitive-information-type-82c382a5-b6db-44fd-995d-b333b3c7fc30#potential

執筆者： Microsoft Japan Business Intelligence Tech Sales Team 伊藤

2018 年 8 月 7 日付で Power BI サービスのワークスペースに対する仕様変更がお知らせされました。

https://powerbi.microsoft.com/ja-jp/blog/enable-your-team-with-new-workspaces-experiences-preview/

この変更により、Office 365 管理者の方にとってもPower BI ユーザーの方にとっても、管理しやすくかつ使いやすくなると思います。

それではまずワークスペースとはどのようなものなのかこれまでの仕組みを説明し、次にそれがどう変わるのかを紹介します。

ワークスペースはその名の通り、作業スペースです。フォルダーと異なり、フラットな構造となっています。この中に Power BI Desktop で作ったレポートを発行したり、ダッシュボードを作ったりします。ワークスペースの中にはデータセット、レポート、ダッシュボードなどが格納されます。ワークスペースには 個人用の「マイ ワークスペース」と、他のユーザーと共同作業するための「アプリ ワークスペース」の２種類あります。Office 365 をお使いの方向けに言うと、マイ ワークスペースは OneDrive, アプリ ワークスペースは SharePoint のような位置づけです。

現在「アプリ ワークスペース」は Office 365 グループと連動しており、アプリ ワークスペースを作成すると Office 365 グループが自動で作成されます。

Office 365 グループについてはこちらのブログ記事をご覧ください。

https://blogs.technet.microsoft.com/exchangeteamjp/2017/10/03/manage-guest-access-to-office365-groups/

これまでの Office 365 グループと Power BI を含む Office 365 の各サービスとの関係は下図のようになります。

Power BI だけを利用している方は気にする必要ないのですが、上記の Office 365 サービスを利用していると、思いがけない影響を受ける場合があります。以下に例を挙げます。

• Office 365 グループの作成を禁止されていて、アプリ ワークスペースが作成できない
• Teams でチームを作成すると、Power BI サービスに同じ名前のアプリ ワークスペースができている。たくさんのチームに所属していると、アプリワークスペースが大量発生してしまう
• アプリ ワークスペースにアクセスすると Power BI Pro の試用やアップグレードを促される

このため「Power BI のアプリ ワークスペースと Office 365 グループを分離してほしい」というフィードバックを多くいただいており、今回のアプリ ワークスペースの仕様変更 (ワークスペース v2) となりました。

今回の仕様変更により、次のように変わります。

アクセス許可の種類について、少し詳しくお伝えします。現行のアプリ ワークスペースへのアクセス権を持つユーザーは、 Office 365 グループと同じく「管理者」と「メンバー」のいずれかに分類されます。アプリ ワークスペースの「管理者」は、「メンバー」にそのワークスペース内のコンテンツの編集を許可するかどうかを決定します。よって、アプリ ワークスペースによって同じ「メンバー」でも権限が異なることになります。またレポートやダッシュボードの共有や、アプリを発行するのではなく、アプリ ワークスペースのメンバーに編集権限を付与しないことで、閲覧のみの共有を実現している方もいらっしゃるかもしれません。

ワークスペース v2 では、メンバーのアクセス許可の種類が、管理者・メンバー・共同作成者・参照者の４つのロール (役割) となります。(「参照者」は一般提供開始時に利用可能になる予定です。)

各ロールで実行可能な操作は以下の通りです。

特にワークスペースに対する「閲覧のみ」の共有方法の変更にご注意ください。

こちらのドキュメントで詳細をご確認いただき、移行方法やスケジュールに注意して、管理方法の変更をお願いします。

https://docs.microsoft.com/ja-jp/power-bi/service-create-the-new-workspaces

こんにちは。 Azure Identity サポートの谷です。

Azure AD Connect (AADC) のアップグレード手順をご紹介いたします。
AADC の更新バージョンのリリース頻度は高く、この 3 カ月でも 3 回更新バージョンがリリースされています。
更新には、既知の不具合やセキュリティに関する修正に加えて機能強化も含まれています。

そのため、できるだけ安定して AADC を運用いただくうえで弊社としての推奨は以下となります。
- 最新バージョンの利用
- 最低でも 6 カ月毎に最新バージョンへのアップグレード

Azure AD Connect: バージョンのリリース履歴
https://docs.microsoft.com/ja-jp/azure/active-directory/connect/active-directory-aadconnect-version-history

なお、サポートという観点では、リリースされている全てのバージョンの AADC が現在サポート対象となります。
特定のバージョンの AADC をサポート終了する場合にはアップグレードを実施いただくために十分な期間を設け、ご案内いたしますので、ご安心ください。

(トラブルシューティングなどの中で古いバージョンをご利用されている場合に切り分けのためのバージョンアップをお願いする、より詳細な調査をするためにも、まずアップグレードをお願いするという可能性があることについては予めご承知おきください)

■ アップグレードの流れ
AADC 1 台構成の場合
----------------------------------------
A. バージョンアップ前にサーバーの健全性確認
B. 設定情報 / ルールのバックアップ
C. アップグレード

AADC 2 台以上の構成の場合
----------------------------------------
1 台構成の場合と同様でも構いませんが、より慎重に行う場合には、バージョンアップ時に片方ずつステージング モードに切り替え、同期処理に影響を与えないように実施することも可能です。この場合には、下記の流れで実施します。

A. バージョンアップ前に両サーバーの健全性確認
B. 設定情報 / ルールのバックアップ
C. 1 台目アップグレード
D. ステージングモードの切り替え
E. アップグレード後の動作確認
F. 2 台目のアップグレード
G. ステージングモードの切り替え
H. アップグレード後の動作確認
I. 必要に応じてステージングモードの切り替え

■ 手順
アップグレード手順
--------------------------------------------------
弊社環境にて 1.1.819.0 から 1.1.880.0 にアップグレードを行った際の手順を纏めさせていただいています。
aadc-upgrade (PDF)

ステージング モード設定手順
--------------------------------------------------
弊社環境にて 1.1.819.0 にて実施した手順を纏めさせていただいています。
staging-mode (PDF)

健全性確認
--------------------------------------------------
1. AADC サーバーにてイベント ログ (システム / アプリケーション) にてエラーや警告などの記録がないことを確認します。
2. Synchronization Service Manager にて同期処理にて success 以外の記録がないことを確認します。

設定情報 / ルールのバックアップ
--------------------------------------------------
<設定情報の記録>
1. Synchronization Service Manager を起動します。
2. [Connectors] を選択します。
3. オンプレミス AD のコネクタを右クリックし、[Properties] をクリックします。
-- 同期対象 OU/コンテナの確認 --
4. [Configure Directory Partitions] - [Containers] をクリックします。
5. パスワードを入力し、[OK] をクリックします。
6. 同期対象の OU/コンテナの画面ショットを採取するなどし、情報を記録しておきます。
-- 同期対象オブジェクトの種類の確認 --
7. [Select Object Types] をクリックします。
8. [Show All] にチェックを入れ、全項目が確認できるように画面ショットを採取します。
-- 同期対象の属性の確認 --
9. [Select Attributes] をクリックします。
10. [Show All] にチェックを入れ、全項目が確認できるように画面ショットを採取します。
-- その他構成情報 --
11. デスクトップなどにある [Azure AD Connect] を実行し、構成ウィザードを開きます。
12. [構成] をクリックします。
13. [現在の構成を表示する] をクリックして、[次へ] をクリックします。
14. 全項目が確認できるように画面ショットを採取します。

<同期ルールのエクスポート>
1. スタート画面より Synchronization Rules Editor を起動します。
2. 全ルールを選択し、[Export] をクリックします。出力されたファイルを保存します。（PS1 という拡張子で保存します。）
例) sync_rule.ps1
3. [Direction] より [Outbound] を選択します。
4. 全ルールを選択し、[Export] をクリックします。出力されたファイルを保存します。（PS1 という拡張子で保存します。）

執筆者: Lindsey Allen (Partner GPM, Azure SQL Database)

このポストは、2018 年 8 月 8 日に投稿された Announcing general availability of Azure SQL Database reserved capacity の翻訳です。

このたび、Azure をお客様のワークロードにとって最もコスト効率の良いクラウドにする取り組みの一環として、Azure SQL Database の Single Database と Elastic Pool 向けの予約容量オプションの一般提供を開始いたします。この新しい価格オプションでは、1 年間または 3 年間の SQL Database の仮想コアのリソースを事前に購入することで、ライセンス付きの価格より最大 33%¹ もコストを節約することができます。

Azure は最もコスト効率の良い SQL Server ワークロード向けクラウド

現在、有効なソフトウェア アシュアランスをお持ちのお客様は、SQL Server 向け Azure ハイブリッド特典と仮想コア ベースという SQL Database の新たな購入モデルを併用することで、最大 55% のコストを節約することができます。今回 Single Database と Elastic Pool で予約容量オプションがサポートされることで、Azure ハイブリッド特典と組み合わせてさらにコストを抑え、最大 80%² も節約できるようになります。

2019 年 7 月 9 日に SQL Server 2008 および 2008 R2 のサポート終了を迎えるお客様は、フル マネージド型の Azure SQL Database に現在のワークロードを移行して、サポート終了に伴う移行コストを削減することができます。Azure ハイブリッド特典では、既存の有効なソフトウェア アシュアランス付きライセンスを利用して Azure の費用をさらに抑えられます。そして、この予約容量の割引を適用することで、一段とお得に Azure SQL Database へ移行できるようになります。

1 つのサブスクリプションに適用するか、契約全体に振り分けるか

SQL Database の予約容量は、1 つのサブスクリプションに割り当てることも、契約やアカウント単位に振り分けることも可能です。対象サブスクリプションの数に制限はなく、割り当てるサブスクリプションも自由に選択することができます。

1 つのサブスクリプションに割り当てる場合、割引は設定したサブスクリプション内の SQL Database リソースのみに適用されます。振り分けの場合には、(Enterprise Agreement などの) 契約内、または (従量課金制などの) アカウント内の任意のサブスクリプションに対して割引が適用されます。契約に含まれる MSDN サブスクリプション、およびアカウントに含まれる従量課金制以外のサブスクリプションは対象外となります。

スケーリングが必要な場合も割引率を維持

SQL Database の予約容量では、仮想コアのサイズを柔軟に変更することができます。同一パフォーマンス レベル、同一リージョン内でスケールアップまたはスケールダウンしても、割引率は変わりません。たとえば、汎用のサービス レベルで、パフォーマンス レベルが Gen 5、仮想コア数 16 の SQL Database の予約容量を購入した場合、仮想コア数 4 の Single Database (Gen 5)、または仮想コア数 8 の Elastic Pool (Gen 5) のどちらのデータベースをデプロイしても割引は自動適用されます。Single Database の仮想コア数を 8 にスケールアップしても、自動で割引が適用されます。

同一リージョン、同一パフォーマンス レベルならば、通常運用の一環として、稼働中のデータベースを、Elastic Pool と Single Database 間で割引率を維持しながら一時的に切り替えることもできます。また、予約容量の一部を割り当てずに保持しておけば、急激に負荷が上昇した場合にも予算内で効率的に対応することができます。

SQL Database の予約容量は当面 Single Database と Elastic Pool で利用可能で、Azure Portal にてご購入いただけます。今後 Managed Instance もサポートする予定です。価格や詳細については、SQL Database の価格ページやドキュメント (英語) をご参照ください。

¹ SQL Database Managed Instance の汎用サービス レベルで、仮想コア数が 8 のデータベースを米国西部 2 リージョンで 1 か月 730 時間実行した場合を基準とし、オンデマンドのライセンス込みの正規料金と、3 年間のライセンス込みの予約容量の料金の割引率から算出。実際の割引率は、リージョン、インスタンスのサイズ、パフォーマンス レベルによって異なります。2018 年 5 月時点の価格であり、変更される可能性があります。

² SQL Database Managed Instance の Business Critical サービス レベルで、仮想コア数が 8 のデータベースを米国西部 2 リージョンで 1 か月 730 時間実行した場合を基準とし、オンデマンドのライセンス込みの正規料金と、Azure ハイブリッド特典に 3 年間の予約容量を組み合わせた基本割引率から算出。SQL Server Enterprise Edition のソフトウェア アシュアランスのコストは EA 契約に応じて異なり、この割引率には含まれません。実際の割引率は、リージョン、インスタンスのサイズ、パフォーマンス レベルによって異なります。2018 年 5 月時点の価格であり、変更される可能性があります。

こんにちは、Exchange サポートの渡辺です。
 
先日公開したブログで、Azure AD と Exchange Online 間の同期の問題に関するトラブルシューティングの基本をご紹介させていただきました。
ただ、あまり事例の紹介ができていないので、今回はトラブルシューティングによって確認できたエラー内容毎に、いくつか詳細と対処方法をご紹介できればと思っています。

事例を紹介するその前に、Exchange Online のメールボックスのおさらい

アーカイブ メールボックス (インプレース アーカイブ)

非アクティブ メールボックスと Soft-Deleted Mailbox

Azure AD - Exchange Online 間の同期の問題でよくある事例

1. 訴訟ホールド、インプレース保持、保持ポリシー(SCC) が有効な場合のエラー

 
基本的にはユーザーを削除した場合に非アクティブ メールボックスになるようなシナリオにおいて、ユーザーは削除せずにライセンスだけを剥奪したりすると発生します。
非アクティブ メールボックスになるシナリオはいくつかあるのですが、以下の 4 つのいずれかによる保持を有効にした状態でユーザーを削除すると作られます。
いずれもライセンスが必要な機能となるため、この状況下でライセンスだけを剥奪するとこのエラーが発生します。
 
  - ExO のeDiscovery でインプレース保持を有効にする
  - ExO で訴訟ホールドを有効にする
  - SCC (セキュリティ/コンプライアンス センター) の eDiscovery でインプレース保持を適用する
  - SCC のアイテム保持ポリシーを適用する
 
※ ExO の訴訟ホールドが有効な場合だけは少し違うメッセージになります。
 

 
これらの保持が有効かどうかについては、基本的には Get-Mailbox コマンドで確認できます。
LitigationHoldEnabled が True なら訴訟ホールドが有効で、InPlaceHolds に何かの値が入っていれば他の 3 つのうちのどれかの設定で保持が有効になっています。
 

 
いずれの保持が有効であったとしても対処方法は以下の公開情報にあるとおりで、ライセンスを剥奪して削除するのではなく、同期元のオンプレミスのユーザーを AAD Connect の同期対象外にして Azure AD 上から削除し、Exchange Online 側で非アクティブ メールボックスに変換します。
 
  Title : 非アクティブなメールボックスを作成する際の注意点
  URL : https://answers.microsoft.com/ja-jp/msoffice/forum/msoffice_o365admin-mso_exchon-mso_o365b/非アクティ/e82edc4b-d65f-4089-be72-ddfc91a0240a
 
なお、Get-Mailbox の結果の LitigationHoldEnabled が False で InPlaceHolds が空の場合でも、同様のエラー メッセージが記録される場合も実はあります。
しかも2パターンあります。
 
1 つ目は、SCC のアイテム保持ポリシーを個別のメールボックスに対してではなく、組織レベルで適用している場合です。
組織レベルで適用されているかなどの詳細は以下のブログでご紹介しているので、もしいずれの保持も設定されていなそうなときはご確認ください。
 
  Title : セキュリティ コンプライアンス センターで設定する保持ポリシーのメールボックスへの適用状況を確認する方法
  URL : https://blogs.technet.microsoft.com/exchangeteamjp/2018/04/17/how-to-see-which-retention-policy-is-applied-to-your-mailbox/
 
2 つ目は、削除の直前までインプレース ホールドや訴訟ホールドが有効だった場合です。
このようなシナリオで削除を試みた場合は、Get-Mailbox の DelayHoldApplied の設定を確認してみてください。
 

 
この画像のように DelayHoldApplied が True となっている場合は、意図的にメールボックスの削除が 30 日遅延される動作になり、Exchange Online 的にはその間はインプレース ホールドが有効な状態と判断するため、同じエラーが出ます。
これは、直前まで保持が有効なメールボックスであったので、誤操作などで本来は必要であったデータを間違って削除してしまうことがないように、Exchange Online が意図的に値を True に設定して削除を遅延させています。
もちろん、対象のメールボックスに誤りがなければ遅延させる必要はないので、以下のコマンドで DelayHoldApplied を False に変更してメールボックスが削除されるか確認していただければと思います。

  Set-Mailbox -Identity <対象のメールボックス> -RemoveDelayHoldApplied

2. ExchagneGuid 関連のエラー

 
エラーの内容通り、ExchangeGuid に設定されている値が、他の受信者オブジェクトと競合してしまっているために、エラーになっているようです。
 
下の絵を見ながら読んでもらえればと思うのですが、このユーザーは以前のメールボックスを削除する前からオンプレミスのリモート メールボックスに、Exchange Online のメールボックスと同じ ExchangeGuid が設定されていました。
オンプレミスのメールボックスを Exchange Online に移動すると自動的にこのような設定になりますね。
そしてメールボックスを削除するためにオンプレミスのリモート メールボックスを Azure AD の同期対象外として Azure AD 上のユーザーを削除したことで、Exchange Online のメールボックスは Soft-Deleted Mailbox になりましたが、引き続き ExchangeGuid は設定されたままになっています。
 
そして、今回メールボックスを再作成する必要がでてきたので、改めて AAD Connect によりオンプレミスのリモート メールボックスを Azure AD に同期し、新しい Azure AD 上のユーザーを作成しました。
ここでポイントになるのが、最初の Soft-Deleted Mailbox の説明に書いた、Azure AD のユーザーを削除しているため Soft-Deleted Mailbox の ExternalDirectoryObject は既に空になっている (どのユーザーとも紐付いていない) ということです。
つまり、新しく作成された Azure AD のユーザーと Soft-Deleted Mailbox は紐付いていない ≒ 別のオブジェクト であるため、別のオブジェクトと ExchangeGuid が競合していますよということでエラーになっています。

じゃあどうするのかというと、対処は簡単で以下の手順を実施するだけで、オンプレミスのリモート メールボックスの ExchangeGuid を削除すれば Exchange Online に新しいメールボックスが作成されます。
 
  1. オンプレミスでリモート メールボックスの ExchangeGuid を削除して値の競合を回避 (Set-RemoteMailbox -ExchangeGuid 00000000-0000-0000-0000-000000000000)
  2. AAD Connect によるディレクトリ同期を実行
  3. 作成された新規ユーザーにライセンスを付与
  4. 必要があれば (必須ではありません)、オンプレミスのリモート メールボックスに対して、Exchange Online のメールボックスに設定されている ExchangeGuid を付与 (Set-RemoteMailbox -ExchangeGuid xxx)
 
補足:
上に書いたとおりオンプレミスのリモート メールボックスの ExchangeGuid を空にすることが正しい手順ですが、「じゃあ競合しない ExchangeGuid なら設定しててもいいの？」と思った方向けに補足します。
これの答えは「NO」です。
なぜかと言うと、最初から ExchangeGuid が設定されているユーザーはオンプレミスにメールボックスが存在していた場合のみを想定しており、そのようなユーザーに関しては Exchange Online 上でライセンスを付与しても、メールボックスが作成されない (オンプレミスのメールボックスを移動する必要がある) からです。
※ この場合は属性値の競合が発生しているわけではないので、Get-MsolUser 上は何もエラーは発生しません。メールボックスが作られない＋エラーもないときは、リモート メールボックスに ExchangeGuid が設定されていないか確認してみましょう。

3. ArchiveGuid 関連のエラー

 
先ほどの ExchangeGuid のエラーと同じように、今度は ArchiveGuid で競合が発生しているようです。
最初に ExchangeGuid を対処した後に出てくることが多いと書きましたが、発生原因は ExchangeGuid と同じで、オンプレミスに設定されている値と同じ値を持つ他の受信者オブジェクトが存在していることが原因なので、ExchangeGuid だけ対処しても今度は ArchiveGuid の競合でひっかかってしまうからというのがその理由です。
1 回の対処で ExchangeGuid と ArchiveGuid の競合両方に対処した方が手間も少ないので、ExchangeGuid のエラーが出たら Archive が有効なメールボックスでないか (このエラーが発生しうる状態でないか) も確認しておきましょう。
 
次は対処についてなのですが、ExxchangeGuid と同じようにオンプレミスのリモート メールボックスに設定された ArchiveGuid を削除すればいいよねと思った方、少しお待ち下さい。
実はこれをやると今度は下のエラーが発生します。
 

 
残念ながら、ArchiveGuid は ExchangeGuid とは違って値を未設定にして同期を行うことができません。
最初にアーカイブ メールボックスはオンプレミスで有効/無効を管理すると説明しましたが、オンプレミス側で有効化しているのにオンプレミスの ArchiveGuid が未設定というのはそもそもおかしいのでエラーになっているというわけです。
 
では、どうすればいいのかと言うと、実は ArchiveGuid の競合の場合は ExchangeGuid とは違って、オンプレミスのリモート メールボックスに設定されている ArchiveGuid を競合しないものに変えるだけで問題ありません。
そのため、以下の手順で対処できます。
 
  1. オンプレミスでリモート メールボックスの ArchiveGuid を別の値に変更する (Set-RemoteMailbox -ArchiveGuid xxx)
  2. AAD Connect によるディレクトリ同期を実行
 
補足:
新しい ArchiveGuid を付与するときは、自動的に GUID を作成してくれる NewGuid メソッドを以下のように使うと便利です。
 
  Set-RemoteMailbox userA -ArchiveGUID ([guid]::NewGUID())
 
  -- 参考
  Title : Guid.NewGuid メソッド ()
  URL : https://msdn.microsoft.com/ja-jp/library/system.guid.newguid(v=vs.110).aspx

まとめ

 
※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

こんにちは、Azure ID チームの松枝です。

本記事では、Azure AD Connect サーバーの CPU 使用率が頻繁に 100% になる問題について、次のとおりご案内いたします。
先日より同様の事象について、多くのお問い合わせをいただいております (ご迷惑をお掛けしまして申し訳ありません)。先日修正を含む Azure AD Connect のバージョンがリリースされましたので、もし本問題事象が発生しましたら、下記の対処方法を実施ください。

本事象の概要：

”バージョン 1.1.819.0 以前” の Azure AD Connect の不具合が原因で、 .NET Framework に関するセキュリティ更新プログラムの適用が行われた後、 Azure AD Connect サーバーの CPU 使用率 が常に 100% に近い高負荷状態になります。

事象発生が報告されている更新プログラム：

• KB4338420
• KB4338606
• KB4054542
• KB4054566
• KB4054590
• KB4338814
• KB4338419
• KB4338605
• KB4345418

参考情報：

• High CPU issue in Azure Active Directory Connect Health for Sync

もし、高負荷状態にあるプロセスが ”Microsoft.Identity.Health.AadSync.MonitoringAgent.Startup.exe” の場合、本事象に該当する可能性が高いと考えられます。

根本的な対処方法：

Azure AD Connect を、本事象に対する修正を含む最新バージョン Azure AD Connect 1.1.880.0 にアップグレードします。
バージョン 1.1.880.0 における修正内容につきましては、下記の弊社技術情報をご参照ください。

• Azure AD Connect: Version release history - 1.1.880.0

暫定的な対処方法：

運用上の理由で上記の根本的な対処が難しい場合、本事象の原因となっているサービス「Azure AD Connect Health Sync Monitoring Service」を停止することでも回避できます。アップグレードするまでの暫定的な対処方法としてご検討ください。
なお、このサービスを停止した場合、Azure AD Connect Health for Sync の機能は利用できなくなりますが、Azure AD Connect の同期処理や認証処理に影響はありません。

上記内容が少しでも参考となりますと幸いです。
製品動作に関する正式な見解や回答については、お客様環境などを十分に把握したうえでサポート部門より提供させていただきますので、ぜひ弊社サポート サービスをご利用ください。

関連する記事：

• Azure AD Connect アップグレード手順

Logbucheintrag 180810:

Siemens-Chef Joe Kaeser hatte bei seinem Amtsantritt ein Versprechen mit seinem Namen verknüpft: Der seinerzeit verunsicherte Konzern sollte zurück in ruhiges Fahrwasser gebracht und gleichzeitig der Flugzeugträger Siemens in eine Flotte von Schnellbooten umgebaut werden. Dafür stand die Strategie Vision 2020, die den Trend zur Holdingstruktur für viele Nachahmer einleitete. Nach Börsengängen, Fusionen und Verkäufen gilt die Transformation als nahezu vollzogen. Nun ist es Zeit für die Vision 2020+, die auch eine inhaltliche Neuausrichtung nach sich ziehen soll: Mehr Industrie 4.0, mehr Agilität, mehr Digitalisierung – und nicht zuletzt mehr Apps für die Cloud.

Dazu hat sich Siemens jetzt ein Goldstück der Startup-Szene gesichert: Mendix ist eine cloudbasierte Entwicklungs-Plattform für Apps der neuesten Generation. Kommunikativ, Kognitiv und mit Künstlicher Intelligenz ausgestattet sollen die Apps untereinander proaktiv kollaborieren und neue, agile Geschäftsprozesse formen. Mendix ist der Weg, auf dem Siemens seine IoT-Plattform Mindsphere zu einem allgegenwärtigen Ecosystem für sich selbst und seinen Kunden aus der industriellen Fertigung ausbauen will. Und Azure ist dabei die bevorzugte Cloud-Plattform.

Mindsphere ist ein Beispiel dafür, wie Microsoft mit Azure durch das Engagement seiner Kunden wachsen kann. Azure ist dabei nicht nur die Plattform, auf der die eigenen Unternehmensabläufe abgebildet werden kann. Es ist auch de Plattform für völlig neue Produkte und Services, die Microsoft-Kunden ihren Kunden unterbreiten. Damit wächst Azure mit dem Wachstum der Kunden.

Bereits seit zwei Jahren arbeiten Siemens und Microsoft intensiv zusammen, um mit Mindsphere eine Infrastruktur zu schaffen, auf der Industrieunternehmen ihre Industrie-4.0-Strategien umsetzen können. Dabei reicht es nicht mehr, lediglich die Maschinensteuerungen zu digitalisieren und die Kommunikation zwischen den einzelnen Fertigungsschritten auf Datenebene zusammenzuschmieden. Mehr und mehr werden für agile, proaktive Prozesse Services benötigt, die die Daten analysieren, neue Planungen proaktiv erstellen und die Umsetzung auf der Fertigungsebene durchsetzen.

Das genau leistet die Kombination aus Azure und Mindsphere. „Die Integration von Siemens MindSphere und Microsoft Azure fördert Geschäftsmodellinnovationen und bietet Kunden zukünftig mehr Flexibilität und Wahlmöglichkeiten. Sie unterstützt Fertigungsunternehmen dabei, ihre digitale Transformation erfolgreich mit Public-Cloud-Lösungen voranzutreiben und die Potenziale von IoT-, Big-Data- und Machine-Learning-Anwendungen voll auszuschöpfen“, sagte Sabine Bendiek, die Vorsitzende der Geschäftsführung von Microsoft Deutschland damals bei der Ankündigung der Zusammenarbeit.

Aber Mindsphere ist zugleich ein Beispiel dafür, wie Siemens sich selbst als Transformer etabliert und dadurch auch wieder zum Performer wird. Die digitale Transformation verändert nicht nur die Geschäftsprozesse und Geschäftsmodelle eines Unternehmens – sie verändert das Unternehmen selbst. Das ist die wahre Herausforderung der Digitalisierung.

Mindsphere auf Azure ist nicht nur eine Infrastruktur in der Public Cloud. Es ist zugleich die Basis für eine Community: die Mndsphere World, die sich Anfang des Jahres aus dem Zusammenschluss von 19 Fertigungsunternehmen gegründet hat. Die internationale Anwendergemeinschaft soll jetzt den Transformationsprozess zusätzlich beschleunigen. Zum Beispiel durch die Entwicklung neuer Apps mit Hilfe von Mendix. Und wieder wächst Azure mit dem Azure dieser Community.

Azure Service principal is like a Mech ID that does work for you behind the scenes

Stack Overflow states it plainly

AAD Tenant ID

Tenant ID

App Registration ID

 

PLEASE!!!!

今回の投稿では、特定のリストに関連付けられた SharePoint 2013 形式ワークフローの各インスタンスの状態を出力する SharePoint Online用のサンプル コードをご紹介します。

SharePoint 2013 形式のワークフローの状態列は、ワークフローの状態列をクリックすれば、下記のように表示されます。

しかし、列自体に、ワークフローの実際の内部状態を表示しないため、リスト ビューなどでワークフローの状況が把握できないというご質問を受けます。

SharePoint 2013 形式ワークフローは、SharePoint 2010 形式ワークフローよりも、リトライ処理が堅牢に実装されております。

そのため、ワークフローの処理が失敗する可能性は低いですが、リトライしても成功しない処理 (例. 削除済みアイテムを削除する) をリトライし続け、リトライ回数を枯渇して一旦停止になる場合もあります。

今回の投稿では、このようなシナリオにおいて SharePoint 2013 形式ワークフローの内部状態を確認し、エラーとなったワークフローを検出するサンプル スクリプトをご紹介します。

事前準備

下記の内容を実施済みのクライアント環境においては、事前準備の項目を再度実施する必要はございません。

1 : SharePoint Online Client Components SDK のダウンロード

サンプル スクリプトを実行するための実行環境として SharePoint Online Client Components SDK をダウンロードします。

以下のリンクよりダウンロード可能です。

タイトル : SharePoint Online Client Components SDK
アドレス : https://www.microsoft.com/en-us/download/details.aspx?id=42038

2 : スクリプトの実行ポリシーを変更する

1）PowerShell を管理者として起動します。
2) 以下のコマンドを実行し、現在の PowerShell の実行ポリシーを確認します。

Get-ExecutionPolicy

3) 以下のコマンドを実行し、PowerShell の実行ポリシーを変更します。

Set-ExecutionPolicy RemoteSigned

補足 : RemoteSigned 以上の実行ポリシー (例. Unrestricted) が指定されている場合は、指定の必要はありません。

コードの実行

1) 以下のコードを GetWfStatus.ps1 として保存します。

param(
 $siteUrl,
 $listName,
 $username,
 $password,
 $outfile,
 $resume = $false
)

Add-Type -Path "C:Program FilesCommon Filesmicrosoft sharedWeb Server Extensions16ISAPIMicrosoft.SharePoint.Client.dll"
Add-Type -Path "C:Program FilesCommon Filesmicrosoft sharedWeb Server Extensions16ISAPIMicrosoft.SharePoint.Client.Runtime.dll"
Add-Type -Path "C:Program FilesCommon Filesmicrosoft sharedWeb Server Extensions16ISAPIMicrosoft.SharePoint.Client.WorkflowServices.dll"

function ExecuteQueryWithIncrementalRetry($retryCount, $delay)
{
  $retryAttempts = 0;
  $backoffInterval = $delay;
  if ($retryCount -le 0)
  {
    throw "Provide a retry count greater than zero."
  }
  if ($delay -le 0)
  {
    throw "Provide a delay greater than zero."
  }
  while ($retryAttempts -lt $retryCount)
  {
    try
    {
      $script:context.ExecuteQuery();
      return;
    }
    catch [System.Net.WebException]
    {
      $response = $_.Exception.Response
      if ($response -ne $null -and $response.StatusCode -eq 429)
      {
        Write-Host ("CSOM request exceeded usage limits. Sleeping for {0} seconds before retrying." -F ($backoffInterval/1000))
        #Add delay.
        Start-Sleep -m $backoffInterval
        #Add to retry count and increase delay.
        $retryAttempts++;
        $backoffInterval = $backoffInterval * 2;
      }
      else
      {
        throw;
      }
    }
  }
  throw "Maximum retry attempts {0}, have been attempted." -F $retryCount;
}

function EnumWorkflowsInFolder($list, $ServerRelativeUrl)
{
  do
  {
    $camlQuery = New-Object Microsoft.SharePoint.Client.CamlQuery
    $camlQuery.ListItemCollectionPosition = $position
    $camlQuery.ViewXml = "<View><RowLimit>5000</RowLimit></View>";
    if ($serverRelativeUrl -ne $null)
    {
       $camlQuery.FolderServerRelativeUrl = $ServerRelativeUrl
    }
    $listItems = $list.GetItems($camlQuery);
    $script:context.Load($listItems);
    ExecuteQueryWithIncrementalRetry -retryCount 5 -delay 30000

    foreach($listItem in $listItems)
    {
      if ($listItem.FileSystemObjectType -eq [Microsoft.SharePoint.Client.FileSystemObjectType]::Folder)
      {
         $script:context.Load($listItem.Folder)
         ExecuteQueryWithIncrementalRetry -retryCount 5 -delay 30000
         EnumWorkflowsInFolder -List $list -ServerRelativeUrl $listItem.Folder.ServerRelativeUrl
      }

      $wfic = $script:wfis.EnumerateInstancesForListItem($list.Id, $listItem.Id);
      $script:context.Load($wfic);
      ExecuteQueryWithIncrementalRetry -retryCount 5 -delay 30000
 
      foreach ($wfi in $wfic)
      {
        WriteOut -text (($listItem.Id.ToString()) + "," + (GetWorkflowSubscription -subid $wfi.WorkflowSubscriptionId) + "," + $wfi.Status) -append $true
        if ($resume)
        {
            if ($wfi.Status -eq "Suspended")
            {
                $script:wfis.ResumeWorkflow($wfi)
                ExecuteQueryWithIncrementalRetry -retryCount 5 -delay 30000
                Write-Output ("Resumed workflow on Item ID = " + $listItem.Id.ToString())
            }
        }
      }
    } 
    $position = $listItems.ListItemCollectionPosition
  }
  while($position -ne $null)
}

function GetWorkflowSubscription($subid)
{
  if ($script:wfsubhash[$subid.ToString()] -eq $null)
  {    
    $sub = $script:wfss.GetSubscription($subid)
    $script:context.Load($sub)
    ExecuteQueryWithIncrementalRetry -retryCount 5 -delay 30000

    $script:wfsubhash[$subid.ToString()] = $sub.Name
    return $sub.Name
  }
  else
  {
    return $script:wfsubhash[$subid.ToString()]
  }
}

function WriteOut($text, $append)
{
  if ($outfile -eq $null)
  {
    Write-Output $text
  }
  else
  {
    if ($append)
    {
      $text | Out-File $outfile -Append -Encoding UTF8
    }
    else
    {
      $text | Out-File $outfile -Encoding UTF8
    }
  }
}

$script:context = new-object Microsoft.SharePoint.Client.ClientContext($siteUrl)
$pwd = convertto-securestring $password -AsPlainText -Force
$credentials = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($username, $pwd)
$script:context.Credentials = $credentials

$wfsm = new-object Microsoft.SharePoint.Client.WorkflowServices.WorkflowServicesManager($script:context, $script:context.Web)
$script:wfss = $wfsm.GetWorkflowSubscriptionService();
$script:wfsubhash = @{}
$script:wfis = $wfsm.GetWorkflowInstanceService();

$list = $script:context.Web.Lists.GetByTitle($listName)
$script:context.Load($list)
ExecuteQueryWithIncrementalRetry -retryCount 5 -delay 30000

$wfSubs = $wfss.EnumerateSubscriptionsByList($list.Id);
$script:context.Load($wfSubs);
ExecuteQueryWithIncrementalRetry -retryCount 5 -delay 30000

WriteOut -text "ItemId,WorkflowName,Status" 
EnumWorkflowsInFolder -List $list -serverRelativeUrl $null

2) PowerShell  を起動します。
3) スクリプトを配置したフォルダーに移動し、作成した .ps1 ファイルを以下のように実行します。

.getwfstatus.ps1 -siteUrl https://tenant.sharepoint.com/sites/workflowsite -listName ドキュメント -username account@tenant.onmicrosoft.com -password password

パラメータ

-siteUrl ・・・ サイトのアドレス
-listName ・・・ リスト名
-username ・・・ 処理を実行するユーザー
-password ・・・ 上記ユーザーのパスワード
-outfile ・・・ 出力先ファイル (省略可 : 既定値はコンソール出力)
-resume ・・・ $true の場合　一旦停止したワークフローを強制開始 (省略可 : 既定値 $false)

補足

• リスト ビューのしきい値と、HTTP 調整対策の内、増分バックオフ リトライに対応しています。
• 大規模なリストに対して、本スクリプトを実行する場合、HTTP 要求数が増える可能性があります。万が一のことを想定し、オフピークの時間帯に実行してください。

今回の投稿は以上です。

本情報の内容は、作成日時点でのものであり、予告なく変更される場合があります。

Summary

When working in virtual labs, I don't always adhere to best practices. For example, we all know the minimum memory recommendation for SharePoint is 16GB for production use. So, when testing in my labs, SharePoint web requests may fail. As a result, I find myself troubleshooting the issue, only to find the failure was caused by low memory. I have many SharePoint Farms and many VM's for testing, which covers all supported versions. So, one would think I have learned my lesson and simply provision all my virtual machines with at least 16GB's of memory. Well I can't because physical memory on the VM host is not limitless and I can create way more VM's if use less memory.

So why am I telling you this?

Mainly it's for me, so I can find the solution easily when this occurs again (and it will). However, I wanted to share my latest symptom which may help someone in the future.

Issue:

Unable to access a SharePoint site with SharePoint Designer, it was failing with error "The server could not complete your request."

Example:

Clicking on "Details" provided no additional information.

Cause:

Since I kind of spoiled it above, you already know its low memory. By default, when memory is below the 5% of the total memory, "Memory gate checking" at the IIS level kicks in and causes SharePoint failures.

If you think this issue is occurring, look in the application event logs during this failure, you may find the following event.

Log Name: Application
Source: System.ServiceModel 4.0.0.0
Date: 8/10/2018 2:30:15 PM
Event ID: 3
Task Category: WebHost
Level: Error
Keywords: Classic
User: contosospservice
Computer: sp

Description:
WebHost failed to process a request.
Sender Information: System.ServiceModel.ServiceHostingEnvironment+HostingManager/56528276
Exception: System.ServiceModel.ServiceActivationException: The service '/b464bf6ac4fd49f986be1900c0ff4950/MetadataWebService.svc' cannot be activated due to an exception during compilation. The exception message is: Memory gates checking failed because the free memory (149831680 bytes) is less than 5% of total memory. As a result, the service will not be available for incoming requests. To resolve this, either reduce the load on the machine or adjust the value of minFreeMemoryPercentageToActivateService on the serviceHostingEnvironment config element.. ---> System.InsufficientMemoryException: Memory gates checking failed because the free memory (149831680 bytes) is less than 5% of total memory. As a result, the service will not be available for incoming requests. To resolve this, either reduce the load on the machine or adjust the value of minFreeMemoryPercentageToActivateService on the serviceHostingEnvironment config element.

at System.ServiceModel.Activation.ServiceMemoryGates.Check(Int32 minFreeMemoryPercentage, Boolean throwOnLowMemory, UInt64& availableMemoryBytes)
at System.ServiceModel.ServiceHostingEnvironment.HostingManager.CheckMemoryCloseIdleServices(EventTraceActivity eventTraceActivity
at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath, EventTraceActivity eventTraceActivity)

--- End of inner exception stack trace ---

at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath, EventTraceActivity eventTraceActivity)
at System.ServiceModel.ServiceHostingEnvironment.EnsureServiceAvailableFast(String relativeVirtualPath, EventTraceActivity eventTraceActivity)

Process Name: w3wp
Process ID: 2360

Workaround:

To workaround this issue set the "minFreeMemoryPercentageToActivateService" to "0" in the web.config for the services web application (not the site), which effectively disables "Memory gate checking".

Example:

<system.serviceModel>

<serviceHostingEnvironment minFreeMemoryPercentageToActivateService="0" />

</system.serviceModel>

Steps:

1. From IIS Manager, right click on the service web app and choose "Explore".

2. You will see a folder that contains the web.config.

3. Make a backup copy of the web.config (always a good practice).

4. Add the "minFreeMemoryPercentageToActivateService" section previously described just above the "</configuration>" closing tag.

    

   Example:

5. Save the changes and trigger an IISRESET.
6. Test the changes by accessing Central Admin and a Site Collection.
7. If all is good, you should be able to continue testing with your new settings.

Important Takeaways:

• This is not a supported configuration and only should be used for testing functionally in test labs (not performance testing).
• Applying CU's may reverse this setting if web.config changes are present in the update.
• This is an IIS thing and a SharePoint thing.
• Low memory can occur on production servers as well, even if your server is configured with 16GB's or more.
• Please do not use this setting on a production server, because if your server is running below 5% memory, it needs some attention and not a band-aid.

En esta ocasión voy a desglosar los detalles incluidos en la calculadora de Azure para el servicio de Azure Backup, es muy importante mencionar que el modelo de precios no ha cambiado, sólo se han agregado un par de detalles para estimar el almacenamiento consumido, la información que se ha agregado es la siguiente:

Veamos a qué se refiere cada punto:

Renovación media diaria (Average Daily Churn)

Las cargas de trabajo tienen distintas tarifas de renovación. Las consideradas en Azure con respecto a la media de renovación son las siguientes.

• Baja (hasta el 2 %)
• Moderado (3 %-4 %)
• Alta (5 % y por encima)

El valor se ha determinado por la media ponderada de renovación diaria de la carga de trabajo, calculada con datos de telemetría de Azure, esto quiere decir que cuando eliges alguna de las opciones de respaldo en la opción de Tipo (Type), por defecto te asigna una media de renovación,

para Azure VM por defecto de selecciona una renovación media diaria Moderada, para Servidores o Clientes Locales – Baja y para Servidores SQL en Máquina Virtual de Azure te denomina Alta, sin embargo, se puede personalizar, ya que el campo es editable.

En un ejemplo más tangible, si tienes una carga de trabajo tipo Cliente y tiene un tamaño de 50 GB se denominaría una media de renovación baja (aprox. 2%) por lo tanto su crecimiento sería de 1 GB, esto no impacta directamente en un crecimiento de la Bóveda de Respaldo en un crecimiento de 51, ya que debemos recordar que al momento de respaldar la información se comprime entre un 30-40%, por lo tanto, lo veríamos de la siguiente manera

Duración de retención de los RP (Puntos de recuperación

Aquí se indican la duración durante la cual desea conservar los puntos de recuperación. Puede tener cualquier cantidad de puntos diarios/semanales/mensuales/anuales retenidos durante el tiempo que especifique y también puedes proyectar el crecimiento después de 1 mes, de un año y en estado estable.

Basados en el mismo ejemplo, si en la opción de retención eliges 30 días como muestra la primera imagen, quiere decir que el punto de recuperación (Recovery Point - RP) del día 1 (equivalente a 32.5 GB) se mantendrá disponible por 30 días siguientes y la misma dinámica aplica para las otras opciones.

Por lo tanto, podemos concluir que los costos mensuales de almacenamiento aumentan con el tiempo debido al crecimiento del almacenamiento y son directamente proporcionales a la renovación de la carga de trabajo y al rango de retención. El almacenamiento crece hasta un punto tras el cual se estabiliza, que se conoce como estado estable.

Para mas información sobre los precios hagan clic aquí https://azure.microsoft.com/es-es/pricing/details/backup/

Espero que haya sido de utilidad esta información.

This session is part eleven of an ongoing series focusing on Operating System Deployment in Configuration Manager. In it, Steven gives an overview of the Microsoft Deployment Toolkit comparing it's use standalone and integrated with Configuration Manager. Demonstrations include the Microsoft Deployment Toolkit UDI wizard, a discussion of the elements added when the Microsoft Deployment Toolkit is integrated with Configuration Manager 2012 and more.

The video linked below was prepared by Steven Rachui, a Principal Premier Field Engineer focused on manageability technologies.

Next in the series, Steven will pause in our more traditional OSD discussion and loop back to the Windows ADK.

Posts in OSD - A Deeper Dive

• Part VI - Task Sequence variables - a deeper dive
• Part X - USMT and OSD
• Part XI - MDT Integration (this post)
• Part XII - OSD and the ADK
• Part XIII - to be Known or to be Unknown - that is the question
• Part XIV – Pre-staged Media
• Part XXIII - Nested Task Sequences

Go straight to the Deeper Dive playlist

OSD Video Tutorial Overview

Inspire 2018 で発表がありました通り、パートナー様のソリューションを紹介し、適切なお客様に提供できるように、マイクロソフト パートナー ネットワークでは新しいサービスの提供やプログラムの強化に取り組んでいます。この記事では、その中のひとつの取り組みにフォーカスして、より深く掘り下げて取り組みをお知らせしていきます。

第一回目は、FY19 で実施されるビジネスプロファイルの変更に焦点を当てます。

ビジネスを差別化するための新しいビジネスプロファイル

コンピテンシー制度を補完するための Advanced Specialization (専門分野) をパートナーのビジネスプロファイルに追加します。これによりパートナーの皆様が、コンピテンシーでカバーされる領域のうち、どのソリューションやサービスが得意なのかを示すことができるようになります。

• SAP on Azure: デジタル変革を推進し、顧客の SAP インフラを SAP on Azure に移行することができる技能。
• クラウド IP 電話: Microsoft Teams や Skype for Business のクラウド電話機能を顧客に提供できる技能。
• オンライン会議: Microsoft Teams や Skype for Business のクラウドオンライン会議機能を顧客に提供できる技能。
• Yammer: 業界をリードするマイクロソフトのエンタープライズソーシャル機能である Yammer を、顧客のチームに適切に提供できる技能。
• ソフトウェアアセット管理 (SAM) マネージドサービス: 顧客が IT 資産をより有効に活用できるよう、マイクロソフトが提供する特典を活用して SAM マネージドサービスとして提供できる技能。
• Microsoft Teams: Office 365 のチームワーク機能であり、マイクロソフトのインテリジェントコミュニケーションビジョンの中核となる Microsoft Teams を顧客に適切に提供できる技能。
• Microsoft 365 とモダンデスクトップ: Office と Windows を単に展開するだけではなく管理もすることで、よりセキュリティを上げ、ITコストを管理し、古いソフトウェアのサポート終了間際で対策をしなくてもよいように計画/実行できる技能。
• 採用変更管理 (ACM): 顧客のマイクロソフトクラウドテクノロジーへの移行を支援し、ますます大きくなる変更管理サービスへのニーズを受け止め計画/実行できる技能。

Azure Export MSP のメリット

厳格な監査と要件の審査を通過したマネージド サービス プロバイダー (MSP) は、Azure Export MSP として認定されます。

Azure Expert MSP に認定されると、バッジの交付、マイクロソフトウェブサイトでの紹介、共同販売 (Co-Sell)やリード紹介 (Referrals) での優先的紹介、 特別イベントへの参加等の特別な特典が付与されます。

資格を得るには?
Azure Expert MSP は時間/コスト集約型の監査プロセスに合格する必要があります。以下で主要な手順をご確認ください。

• ステップ 1: 必須条件を満たす
  開始するには、Gold の Cloud Platform コンピテンシー ステータスを獲得済みで、以下に説明するその他のビジネス要件を満たすことが必要です。
• ステップ 2: 申請する
  以下に記載されたすべての要件を満たす場合は、申請プロセスにアクセスし、確認を受けるために申請することができます。
• ステップ 3: 監査を実施して合格する
  最初の確認の後、2 日間の集中的な監査を実施するため、サード パーティーの監査人をご紹介します。
• ステップ 4: 継続的な要件を満たす
  更新されたテクノロジ水準を貴社が引き続き満たしていることを確認するため、年に一度再評価が行われます。

ビジネスの重点エリア

マイクロソフトが定義するビジネス重点エリアにフォーカスいただくことで、その専門性がマイクロソフトから評価されます。以下が重点エリアとして現在考えられています。

製品

• Dynamics 365 for Sales
• Enterprise Mobility and Security

ソリューションエリアの重点エリア

• クラウドへの移行
• ハイパフォーマンスコンピューティング (HPC)
• SharePoint ビジネスアプリケーション
• エンタープライズコンテンツ管理

サービスの重点エリア

• 展開
• ライセンス管理

次回は、特典にまつわる変更について解説します。

関連記事

• マイクロソフトとのパートナーシップによる新しいビジネス チャンス
• マイクロソフト パートナー ネットワークの進化
• ビジネスを差別化する (PDF/英語)
• リード紹介
• Azure Expert MSP プログラム

Quick Download:

https://gallery.technet.microsoft.com/Get-All-SCOM-Rules-853ecfde

This is a script that will generate a list of all Rule and Monitors in a SCOM deployment.

It will also gather important information, like if the workflows generates an alert or not, and the details of the alert like default priority and severity.

Rules:

• DisplayName
• Name
• Target
• Category
• Enabled
• Alert
• Priority
• Severity
• Management Pack Display Name
• Management Pack Name
• Data Source
• Description

Monitors:

• DisplayName
• Name
• Target
• Category
• Enabled
• Alert
• Priority
• Severity
• Management Pack Display Name
• Management Pack Name
• Monitor Classification
• Monitor Type
• Description