SQL 2016 Service Pack 1 is now supported for SCOM 2016 deployments.

https://docs.microsoft.com/en-us/system-center/scom/plan-sqlserver-design#sql-server-requirements

There is no Update Rollup level requirement for this.  You can deploy SCOM 2016 in new deployments on SQL 2016 SP1, and you may upgrade existing deployments to SQL 2016 SP1.

In Office 365 it may become necessary to change recipient types for on premises accounts.  In this scenario contoso.com provided a mailbox within their Office 365 tenant for a user.  A decision was made to host the users mailbox within a different mail system but authentication would still occur against the contoso.com domain.  The desire was to retain the original active directory account provisioned for the user and have the user appear in the global address list with routing information to the new mail system.

Let’s take a look at this example. 

In the contoso.com directory a user account was provisioned.

PS C:> Get-ADUser testcontoso | fl

DistinguishedName : CN=Test Contoso,OU=Users,OU=UsersOU,DC=contoso,DC=local
Enabled           : True
GivenName         : Test
Name              : Test Contoso
ObjectClass       : user
ObjectGUID        : a89d3274-747d-4f10-8fa6-68ea419656d1
SamAccountName    : TestContoso
SID               : S-1-5-21-2774288044-2073832935-89463056-1298
Surname           : Contoso
UserPrincipalName : TestContoso@contoso.com

The user was enabled for a remote mailbox using the command enable-remotemailbox.  Once the object is replicated through directory synchronization a new remote mailbox will be created within Office 365.

[PS] C:>Enable-RemoteMailbox -Identity TestContoso -RemoteRoutingAddress testcontoso@contoso.mail.onmicrosoft.com

Name                 RecipientTypeDetails         RemoteRecipientType
----                 --------------------         -------------------
Test Contoso         RemoteUserMailbox            ProvisionMailbox

We can verify the account creation in Azure Active Directory with get-msolUser.

PS D:> Get-MsolUser -UserPrincipalName testcontoso@contoso.com

UserPrincipalName              DisplayName  isLicensed
-----------------              -----------  ----------
TestContoso@contoso.com        Test Contoso False

The final step in provisioning is verification of the Exchange Online Account.  This can be performed with get-recipient.

PS D:> Get-Recipient TestContoso

Name         RecipientType
----         -------------
Test Contoso UserMailbox

When reviewing the object on premises there are active directory attributes that in conjunction with directory synchronization control how the object is created and provisioned in the service.  For this example we are particularly interested in an attribute msExchRemoteRecipientType.  For a remote mailbox that was provisioned using on premises commands enable-remoteMailbox the remote recipient type should be a value of 1. 

msExchRemoteRecipientType: 1;

In our example the value is 1.  A good reference for recipient display types https://blogs.technet.microsoft.com/johnbai/2013/09/11/o365-exchange-and-ad-how-msexchrecipientdisplaytype-and-msexchangerecipienttypedetails-relate-to-your-on-premises/.

1               

0x1         

ProvisionedMailbox (Cloud MBX)

Now that we have established how the user and mailbox were provisioned we can review the conversion process.  In our example we want to convert the user from a REMOTE MAILBOX to a MAIL USER.  (A mail user is an active directory account that is extended with an email address outside the organization for the purposes of allowing authentication to the directory, allowing the user to appear in the global address list, and having messages sent from the source mail system to the remote mail system.).

The process starts by disabling the remote mailbox.  This is accomplished utilizing the disable-remoteMailbox command.

[PS] C:>Disable-RemoteMailbox TestContoso -Confirm:$FALSE

This process removes the Exchange attributes from on premises and adjusts the remote recipient type.  In this case the remote recipient type is adjusted to 8. 

msExchRemoteRecipientType: 8;

8               

0x8            

DeprovisionMailbox

At this stage the user account still exists in on premises Active Directory and still exists in Azure Active Directory.  We have not deleted nor modified further the account. 

To enable the account as a mail user we will use the enable-mailUser command.

[PS] C:>Enable-MailUser TestContoso -ExternalEmailAddress test@contoso.com

Name                                     RecipientType
----                                     -------------
Test Contoso                             MailUser

Using the get-recipient command we can validate the attribute set on premises – specifically the email addresses and target address.

[PS] C:>Get-Recipient TestContoso | Select-Object EmailAddresses,ExternalEmailAddress,PrimarySMTPAddress | fl

EmailAddresses       : {smtp:TestContoso@contoso.mail.onmicrosoft.com,
                       smtp:TestContoso@contoso.org, smtp:TestContoso@contoso.com,
                       SMTP:test@external.com}
ExternalEmailAddress : SMTP:test@external.com
PrimarySmtpAddress   : test@external.com

In the case of a mail enabled contact the primary SMTP address, external SMTP address, and primary email address in the proxy addresses signified by SMTP: should all match.  This is one of the few cases where a primary proxy address will reflect an external non-owned address.

We can verify the same information in Exchange Online using get-recipient.

PS D:> Get-Recipient TestContoso | Select-Object RecipientType,EmailAddresses,ExternalEmailAddress,PrimarySMTPAddress | fl

RecipientType        : MailUser
EmailAddresses       : {X500:/o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=84d0cea822fe44509f4382fdaed37ab5-Test Co, SMTP:TestContoso@contoso.onmicrosoft.com,
                       smtp:TestContoso@contoso.mail.onmicrosoft.com, smtp:TestContoso@contoso.com, smtp:TestContoso@contoso.org}
ExternalEmailAddress : SMTP:test@external.com
PrimarySmtpAddress   : TestContoso@contoso.onmicrosoft.com

This output confirms that a mail user object has been provisioned in the service but the addresses do not match on premises?  Why?

In this instance the provisioning process is confused by the presence of the remote recipient type on premises.  A typical mail user does not have a remote recipient type set.   In this instance the mail user will work, but any attempts to search via SMTP address or information displayed on contact cards may not be consistent with expectations.  For example, the contact in the on premises GAL would show a primary proxy of the external address while the Exchange Online GAL would show a primary proxy of the internal address.  Although this display is not the same – we will route messages correctly to the external recipient since the external email address is properly set.

How do we fix this issue?

In order to correct this condition the remote recipient type needs to be cleared.  Using Active Directory Users and Computers ensure advanced features is enabled (view –> advanced features).  Locate the user account on premises and select properties. 

Select the EDIT button –> CLEAR –> OK.  This will revert the entry to NOT SET.  The apply button will commit the change to the directory.  Directory replication and directory synchronization will apply the change to Azure Active Directory and Exchange Online.

When changes have replicated successfully we can use get-recipient to validate the changes in Exchange Online.  The primary proxy address listed in SMTP addresses and signified with SMTP: matches the primarysmtpaddress field.  The fix was successful.

PS D:> Get-Recipient TestContoso | Select-Object RecipientType,EmailAddresses,ExternalEmailAddress,PrimarySMTPAddress | fl

RecipientType        : MailUser
EmailAddresses       : {smtp:TestContoso@contoso.onmicrosoft.com, SMTP:test@external.com, X500:/o=contoso/ou=Exchange Administrative Group
                       (FYDIBOHF23SPDLT)/cn=Recipients/cn=84d0cea822fe44509f4382fdaed37ab5-Test Co, smtp:TestContoso@contoso.mail.onmicrosoft.com, smtp:TestContoso@contoso.com,
                       smtp:TestContoso@contoso.org}
ExternalEmailAddress : SMTP:test@external.com
PrimarySmtpAddress   : test@external.com

This is the process that can be utilized to convert a remote mailbox to a mail user.

皆様、こんにちは。Windows プラットフォーム サポート担当の竹村です。
前回に引き続き、本エントリではトークン署名証明書、トークン暗号化解除証明書の更新手順をご紹介いたします。

トークン署名証明書、トークン暗号化解除証明書は AD FS が発行する自己証明書であり、既定では1年に1回自動的に新しい証明書の作成、更新処理が行われます。
これを、自動ロールオーバー機能と呼びます。

自動ロールオーバー機能は、具体的には以下のように動作します。
1. 有効期限が切れる 20 日前に、セカンダリのトークン署名/トークン暗号化解除証明書を作成します。
2. 上記 1 でセカンダリの証明書が作成されてから 5日後に、セカンダリの新しい証明書がプライマリとなり、実際に利用されるようになります。
※ この 5日間の間に、証明書利用者信頼に新しい証明書を登録する必要があります。

ここでは、これらの証明書を手動で更新する手順をご案内いたします。
また、補足として証明書の有効期限を既定の 1年 から変更する方法についても併せてご紹介いたします。

- 対象リリース
Windows Server 2012 R2 (AD FS 3.0)

- 更新手順
以下の流れで更新作業を行います。

------------------
手順の概要
------------------
1. セカンダリのトークン署名/トークン暗号化解除証明書を作成
2. 証明書利用者信頼 (Office 365) の証明書情報を更新
3. セカンダリのトークン署名/トークン暗号化解除証明書をプライマリに昇格
4. Active Directory Federation Services サービスを再起動

それぞれの詳細を後述致します。

--------------------------------------------------------------------------
1. セカンダリのトークン署名/トークン暗号化解除証明書を作成
--------------------------------------------------------------------------

トークン署名/トークン暗号化解除証明書を更新するためには、現在使用されているプライマリのトークン署名/トークン暗号化解除証明書の有効期限が切れる前に、セカンダリのトークン署名/トークン暗号化解除証明書を作成致します。
このセカンダリのトークン署名/トークン暗号化解除証明書は、既定では、プライマリのトークン署名/トークン暗号化解除証明書の有効期限が切れる 20 日前に、AD FS によって自動で作成されます。
セカンダリのトークン署名/トークン暗号化解除証明書が作成されているか否かは、以下の手順で確認致します。

1-1. プライマリ AD FS サーバーでスタート画面などから [AD FS の管理] コンソールを開きます。

1-2. 画面左側から [AD FS] - [サービス] - [証明書] を選択します。

1-3. 画面中央から、トークン署名/トークン暗号化解除証明書のセカンダリが存在するか確認します。
セカンダリのトークン署名/トークン暗号化解除証明書は、AD FS による自動作成を待たずに、手動で作成することも可能です。
もし、セカンダリのトークン署名/トークン暗号化解除証明書が作成されていない際には、自動で作成されるのを待つか、以下の手順で手動で作成します。

1-4. プライマリ AD FS サーバーで PowerShell を管理者として起動します。

1-5. 起動した PowerShell で以下のコマンドを実行してセカンダリのトークン署名/トークン暗号化解除証明書を作成します。
Update-ADFSCertificate
※ このコマンドを実行するためには、自動ロールオーバー機能 が有効である必要がございます。
無効の場合には、事前に以下のコマンドを実行し、有効にしてください。
Set-ADFSProperties -AutoCertificateRollover $true

1-6. 上記 1-1. から 1-3. の手順で、セカンダリが作成されていることを確認します。
以上でセカンダリのトークン署名/トークン暗号化解除証明書作成手順は終了です。
次のステップに進みます。

--------------------------------------------------------------------------
2. 証明書利用者信頼 (Office 365) の証明書情報を更新
--------------------------------------------------------------------------
新しいトークン署名証明書を作成いたしましたら、証明書利用者信頼にその新しい証明書を登録する必要があります。
セカンダリのトークン署名/トークン暗号化解除証明書が作成されてから 5 日以内に、証明書利用者信頼に新しい証明書を登録する必要があります。
これは、セカンダリのトークン署名/トークン暗号化解除証明書が作成されてから 5 日後にプライマリに昇格されて、実際に使用されるようになるためです。
ここでは、例として Office 365 の場合の手順をご案内します。
(Office 365以外の場合には、実際に利用されている証明書利用者信頼ごとに手順をご確認ください。)

2-1. プライマリ AD FS サーバーでスタート画面などから [Windows PowerShell 用 Windows Azure Active Directory モジュール] を管理者として起動します。

2-2. 起動した PowerShell で以下のコマンドを実行し、Office 365 に接続します。
Connect-MsolService
資格情報の入力を求められるので、管理者アカウントの情報を入力します。

2-3. 続けて、以下のコマンドを実行して現在の証明書情報を調べて、更新が必要か確認します。
Get-MsolFederationProperty -DomainName
このコマンドで得られる結果から "Source : ADFS Server" と、"Source : Microsoft Office 365" のブロックを比較します。
この 2 つのブロックの情報が異なる場合は、引き続き下記の手順に従って更新を行う必要があります。

2-4. 続けて、以下のコマンドを実行して Office 365 の証明書情報を更新します。
Update-MSOLFederatedDomain -DomainName
※ 複数のトップレベル ドメインをサポートしている場合は、代わりに以下コマンドを実行します。
Update-MSOLFederatedDomain -DomainName -SupportMultipleDomain

2-5. 上記 2-3. の手順で再度確認を行います。
以上で Office 365 の証明書情報更新手順は終了です。
次のステップに進みます。

--------------------------------------------------------------------------
3. セカンダリのトークン署名/トークン暗号化解除証明書をプライマリに昇格
--------------------------------------------------------------------------
※ この手順以降、手順 4. が完了するまで、正しく認証ができない場合があります。手順 4. まで続けて実行してください。
手順 1. で自動、または手動でセカンダリのトークン署名/トークン暗号化解除証明書が作成されてから 5 日後に、AD FS によって自動でセカンダリがプライマリに昇格されます。
それ以降、AD FS では、この新しいプライマリのトークン署名/トークン暗号化解除証明書が使用されるようになります。
そのため、上述の手順 2. は、セカンダリの証明書が作成されてから 5 日以内に行う必要があります。
この AD FS によるプライマリへの自動昇格を待たずに、手動で昇格することも可能です。

その手順は、以下になります。

3-1. プライマリ AD FS サーバー で PowerShell を管理者として起動します。

3-2. 起動した PowerShell で以下のコマンドを実行して自動ロールオーバー機能を無効化します。
Set-ADFSProperties -AutoCertificateRollover $false
※ すでに無効化されている場合は、このコマンドの実行は不要です。

3-3. スタート画面などから [AD FS の管理] コンソールを開き、画面左側から [AD FS] - [サービス] - [証明書] を選択します。

3-4. 画面中央から、プライマリに昇格したいセカンダリのトークン署名/トークン暗号化解除証明書を右クリックし、[プライマリとして設定] を選択します。

3-5. 警告が表示される場合は [はい] をクリックします。

3-6. 続けて、PowerShell で以下のコマンドを実行して自動ロールオーバー機能を有効に戻します。
Set-ADFSProperties -AutoCertificateRollover $true
※ 無効化された状態で運用をされる場合は、このコマンドの実行は不要です。
以下の手順でセカンダリのトークン署名/トークン暗号化解除証明書が自動、もしくは手動でプライマリに昇格されていることを確認致します。

3-7. プライマリ AD FS サーバーでスタート画面などから [AD FS の管理] コンソールを開きます。

3-8. 画面左側から [AD FS] - [サービス] - [証明書] を選択します。

3-9. 画面中央から、トークン署名/トークン暗号化解除証明書のプライマリとセカンダリが入れ替わっていることを確認します。
以上でセカンダリのトークン署名/トークン暗号化解除証明書をプライマリに昇格する手順は終了です。
次のステップに進みます。

--------------------------------------------------------------------------
4. Active Directory Federation Services を再起動
--------------------------------------------------------------------------
手順 3. の後、トークン署名/トークン暗号化解除証明書の入れ替えが各 AD FS サーバーに反映されるまで、10 分ほど待った後、各 AD FS サーバーの Active Directory Federation Services を再起動致します。
各 AD FS サーバーで以下の手順を行い、Active Directory Federation Services を再起動致します。

4-1. スタート画面などから [サービス] コンソールを開きます。

4-2. [Active Directory Federation Services] を右クリックし、[再起動] を選択します。

以上で Active Directory Federation Services の再起動手順は終了です。

-------------
補足
-------------
以下について補足をさせて頂きます。
トークン署名/トークン暗号化解除証明書の更新に際しまして、ご参考になれば幸いです。
1. トークン署名/トークン暗号化解除証明書の有効期間を延ばす手順
2. 自動ロールオーバー機能を無効化する手順
3 . セカンダリのトークン署名/トークン暗号化解除証明書を削除する手順
それぞれの詳細を後述致します。

--------------------------------------------------------------------------
1. トークン署名/トークン暗号化解除証明書の有効期間を変更する手順
--------------------------------------------------------------------------
既定では、トークン署名/トークン暗号化解除証明書の有効期間は 1 年です。
以下の手順に沿って、トークン署名/トークン暗号化解除証明書の有効期間を変更することで、次回以降作成される証明書に反映されます。
なお、この手順は現行の証明書の期間を変更するものではなく、この設定以降に作成される証明書の有効期間を変更するものとなります。
そのため、トークン署名/トークン暗号化解除証明書の有効期間を変更する際には、最初にこの手順を実施していただいた後に証明書の更新作業を行ってください。

1-1. プライマリ AD FS サーバー で PowerShell を管理者として起動します。

1-2. 起動した PowerShell で以下のコマンドを実行して有効期間を設定します。
Set-AdfsProperties -CertificateDuration

例えば、およそ 10 年 (3650日) に設定する場合は以下のようになります。
Set-AdfsProperties -CertificateDuration 3650

弊社内部情報より、最長で 50 年の設定を行っても問題ないことを確認しております。

--------------------------------------------------------------------------
2. 自動ロールオーバー機能を無効化する手順
--------------------------------------------------------------------------
先述のとおり、自動ロールオーバー機能は既定で以下のように動作します。
・現在使用されているプライマリのトークン署名/トークン暗号化解除証明書の有効期限が切れる 20 日前に、新証明書をセカンダリとして作成する
・セカンダリのトークン署名/トークン暗号化解除証明書が作成されてから 5 日後に、プライマリ (旧証明書) とセカンダリ (新証明書) を入れ替える
そのため、各証明書の有効期限に合わせて(既定では 1年ごとに) 新しい証明書を証明書利用者信頼に登録する作業を行っていただく必要がございます。
※ 証明書利用者信頼の中には、AD FS からフェデレーションメタデータを受信できるネットワーク環境であれば、自動的に更新作業が行われるものもございます。
上述1 の証明書の有効期限を変更する手順と併せて、自動ロールオーバー機能を無効にしていただくことで、各作業を、各証明書の有効期限が切れるまでにお客様の任意のタイミングで進めていただくことができます。
自動ロールオーバー機能を無効にする方法は以下になります。

2-1. プライマリ AD FS サーバー で PowerShell を管理者として起動します。

2-2. 起動した PowerShell で以下のコマンドを実行して自動ロールオーバー機能を無効化します。
Set-ADFSProperties -AutoCertificateRollover $false

なお、自動ロールオーバー機能を有効に戻す場合は、以下のコマンドを実行します。
Set-ADFSProperties -AutoCertificateRollover $true

--------------------------------------------------------------------------
3. セカンダリのトークン署名/トークン暗号化解除証明書を削除する手順
--------------------------------------------------------------------------
トークン署名/トークン暗号化解除証明書の更新作業を行っていただいた後、元々プライマリであった証明書がセカンダリとして残ります。
以下の手順に沿って、このセカンダリの証明書を削除することが可能です。
なお、このセカンダリの証明書は残っていても AD FS の動作などに影響を及ぼすものではございません。

3-1. プライマリ AD FS サーバー で PowerShell を管理者として起動します。

3-2. 起動した PowerShell で以下のコマンドを実行して現在の証明書情報を確認します。
Get-AdfsCertificate
CertificateType の値が Token-Signing になっていて IsPrimary の値が False になっているブロックがセカンダリのトークン署名証明書の情報ブロックです。
CertificateType の値が Token-Decrypting になっていて IsPrimary の値が False になっているブロックがセカンダリのトークン暗号化解除証明書の情報ブロックです。

3-3. 続けて、PowerShell で以下のコマンドを実行して自動ロールオーバー機能を無効化します。
Set-ADFSProperties -AutoCertificateRollover $false
※ すでに無効化されている場合はこのコマンドの実行は不要です。

3-4. 上記 2-2. で確認した結果を元に、PowerShell で以下のコマンドを実行してセカンダリのトークン署名証明書を削除します。
Remove-AdfsCertificate -Thumbprint -CertificateType Token-Signing

3-5. 上記 2-2. で確認した結果を元に、PowerShell で以下のコマンドを実行してセカンダリのトークン暗号化解除証明書を削除します。
Remove-AdfsCertificate -Thumbprint -CertificateType Token-Decrypting

3-6. 続けて、PowerShell で以下のコマンドを実行して自動ロールオーバー機能を有効に戻します。
Set-ADFSProperties -AutoCertificateRollover $true
※ 無効化された状態で運用をされる場合はこのコマンドの実行は不要です。

手順は以上の通りとなります。
上記手順は過去にも同様のお問い合わせをお受けした際、多くのお客様にご案内しております実績のある手順となっておりますので、ご参考いただけますと幸いです。

Thanks again to everyone that attended my Securing, Governing, and Protecting Your Office 365 Investments session at Microsoft Ignite last Monday or Wednesday afternoon. As promised, the slides from my session have been posted and shared below.

During the session, we discussed and white boarded Microsoft's layered approach to security (slide 5) and reviewed in depth 4 common scenarios and common customer use cases related to:

1. Just In Time and Just Enough Access
2. Phishing and Zero Day Attacks
3. Limited Access
4. Visibility

Here is a link to additional screenshots from the demos that were done for this session during Ignite.

Slide 9 in the deck below has links to many of the key resources to help you go deeper and learn more about these topics and others related to Microsoft's Office 365 and Enterprise Mobility + Security capabilities.

A number of people have also requested more information on some of the capabilities that were highlighted during the session. Here you go:

• Configuring Microsoft Azure AD Privileged Identity Management (PIM)
• Office 365 Advanced Threat Protection (ATP)
• Limited Access Policies for SharePoint Online and OneDrive for Business
• Office 365 Audit Log Searches
• Office 365 Threat Intelligence
• Office 365 Cloud App Security
• Office 365 Secure Score

Hope these additional resources and links help. It was great connecting with so many Microsoft customers and partners in Orlando!

Securing, Governing, and Protecting Your Office 365 Investments from Chris Bortlik [MSFT]

The Microsoft Security Response Center (MSRC) receives reports about potential vulnerabilities in our products and it’s the job of our engineering team to assess the severity, impact, and root cause of these issues. In practice, a significant proportion of these reports turn out to be memory corruption issues.  In order to root cause these issues, an MSRC security engineer typically needs to analyze the crash and try to understand what went wrong. This workflow isn’t unique to externally reported vulnerabilities; vulnerabilities that are discovered internally through fuzzing and variant investigation are also typically memory corruption issues and these need to be triaged and assessed for exploitability too.

For these reasons, MSRC has made significant investments over the course of many years to build tooling that helps us automate the root cause analysis process. VulnScan is a tool designed and developed by MSRC to help security engineers and developers determine the vulnerability type and root cause of memory corruption bugs. It is built on top of two internally developed tools: Debugging Tools for Windows (WinDbg) and Time Travel Debugging (TTD).

• WinDbg is Microsoft's Windows debugger that has recently received a user interface makeover to make it even easier to use. You can find more information about the new WinDbg Preview version here.
• Time Travel Debugging is an internally developed framework that records and replays execution of Windows applications. This technology was released during CPPCon 2017.

By leveraging WinDbg and TTD, VulnScan is able to automatically deduce the root cause of the most common types of memory corruption issues. Application Verifier’s mechanism called PageHeap is used to trigger an access violation closer to the root cause of the issue. The analysis starts from the crash location and progresses towards the root cause. Classes of memory corruption issues supported by VulnScan:

• Out of bounds read/write
  • The invalid pointer value is tracked back to its origin. If the origin points to a valid allocation and the pointer subsequently becomes invalid VulnScan tries to determine which instruction made the change and why.
  • This also means the tool can detect integer overflows and underflows as well as basic out of bounds accesses caused by a bad loop counter value.
• Use after free
  • The value of the invalid pointer at the access violation is used in a backwards lookup to identify the point in the execution timeline where the invalid pointer becomes valid. From this point VulnScan does the forward trace of application code, tracking all memory free operations to determine where the pointer was freed.
  • We experimented with a few techniques before selecting the above method. Originally all memory allocations and frees were logged, but this was very resource and time consuming. It also negatively affected the speed of triage for other bugs as the map of heap objects was prepared even for non-use-after-free bugs. This method allowed us to triage use-after-free bugs without PageHeap enabled. It can still be used but it’s disabled by default.
• Type confusion
  • For this vulnerability type, the tool is using a heuristic that checks if the pointer size and alignment are consistent. If a tainted pointer value in the reverse execution flow is being partly overwritten with a value of the same size (misaligned structure member memory write) or modified with a value with different size it might indicate a type confusion vulnerability (different structure member type).
  • An example triage of a type confusion bug can be found in next part of this blog post below.
• Uninitialized memory use
  • Each memory read operation is verified for initialization by inserting a memory breakpoint at the address of the memory read. Then the code is run in reverse order to the point where it had been written. If the write operation is missing, we report an uninitialized memory use to the user and continue analysis.
  • An example triage of an uninitialized memory pointer:

[*]     Current instruction: cmp         qword ptr [r8+00000558h],rax
[*]     Current position: 0x2B3DC0000001
[*]     Source memory value: 0x2390E31B940
[*]     Tainting back register: r8
[*]     Register value: 0x0
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         r8,qword ptr [rcx+00000410h] <- uninitialized memory
[*]     Current position: 0x2b3d80000144
[*]     Source effective address: 0x2417f9a2690
[*]     Source memory value:0x0
[*]     ----------------------------------------------------------------------
[*]     Uninitialized heap object vulnerability detected !!!

• Null/constant pointer dereference
  • The multi-branch tainting engine in VulnScan tracks all values to their initialization. If all branches lead back to null or constant values without modification, we report a null or constant pointer dereference to the user.
  • Example triage of a null pointer dereference bug:

[*]     Current instruction: test        byte ptr [rcx+4Ch],1
[*]     Current position: 0x6328B80000001
[*]     Source memory value: 0x1
[*]     Tainting back register: rcx
[*]     Register value: 0x0
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         rcx,qword ptr [rcx+20h]
[*]     Current position: 0x6328B4000014E
[*]     Source effective address: 0x1E3A54FDC20
[*]     Source memory value: 0x0
[*]     Memory is initialized @TTTPos: 1744423515849038.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x1E3A54FDC20
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         qword ptr [rbx+20h],rax
[*]     Current position: 0x6327FC00002AE
[*]     Source memory value: 0x0
[*]     Tainting back register: rax
[*]     Register value: 0x0
[*]     ----------------------------------------------------------------------
[*]     Current instruction: xor         eax,eax
[*]     Current position: 0x6327FC00002AD
[*]     Tainted register got zeroed!
[*]     ----------------------------------------------------------------------

MSRC uses VulnScan as part of our automation framework called Sonar. It automatically processes externally reported proof of concept files on all supported platforms and software versions. Sonar is used to both reproduce and to perform the root cause analysis. To this end, we employ multiple different environments and try to reproduce the issue multiple times with different configurations.

VulnScan is planned for inclusion in Microsoft Security Risk Detection service (Project Springfield), where it is used to de-duplicate crashes and provide extended analysis of vulnerabilities found through fuzzing.

Over a 10-month period where VulnScan was used to triage all memory corruption issues for Microsoft Edge, Microsoft Internet Explorer and Microsoft Office products. It had a success rate around 85%, saving an estimated 500 hours of engineering time for MSRC engineers.

Case study – triaging type confusion bug (CVE-2017-0134)

With the help of the Time Travel Debugging (TTD) we can explore code in both directions of the timeline of code execution. We use taint techniques to track register changes and memory breakpoints to track writes to the memory. Every instruction in the tainting process is analysed in the context of previously executed instructions to find the possible root cause of the issue and to determine the bug class.

VulnScan taint analysis is multi-branch, which means it can sequentially track all values obtained from a single instruction. VulnScan has a queue of registers and memory addresses associated with specific positions in the execution timeline. Taint analysis is performed separately for each branch. Using this technique, application data flow can be recreated in full. Over time, we’ve made a few simplifications and optimizations to speed up the analysis process. The following analysis is a simple example just to highlight the basic concepts and capabilities of the tool.

The example is from a Chakra vulnerability submitted to the MSRC by Jordan Rabet (Microsoft Offensive Security Research Team).

The following positions in the trace are the important ones:

Position 0x2D0780000001: The location of the access violation.

Address (0xA0000000A), as dereferenced by the mov instruction, does not point to a valid memory location. We start our analysis by tainting back from the register (rcx) used in this pointer calculation.

Position 0x2CFA8000014D: The first time the heuristic is triggered.

This is probably the most important point of this analysis. The invalid pointer value was tracked back as a 64-bit value up to this point, but it is used as 32-bit value in a memory write operation. This heuristic is triggered a couple more times in the analysis, but these are not important since they do not affect the invalid pointer value we saw at the location of the access violation.

Positions 0x1D420000037E to 0x1D40400000A7: The tainted value changes between these positions.

As this was set externally by the NtReadFile system call, this implies that the value could be controlled by an attacker. Tracing further back shows the memory being set to a PageHeap-specific constant value, which also indicates we are dealing with a heap allocation.

Call stack:
00 ch!memcpy          <- Position 0x1D420000037E
01 ch!memcpy_s
02 ch!_fread_nolock_s <- syscall
03 ch!fread_s
04 ch!fread
05 ch!Helpers::LoadScriptFromFile
. . .
0n <- Position 0x1D40400000A7

Position 0x2A8C80001709: Taint analysis of the main branch ends here.

The dereferenced address (0x7FFC239B2358) is a read-only global variable within the ChakraCore binary. Analysis of other branches (called junctions) is performed from this point. Analysis will be continued in the next branch because the instruction is an arithmetic operation with a register in the destination operand.

This operation is represented in source code by dbl *= g_rgdblTens[lwExp], where g_rgdblTens is a global variable.

Other branches (position 0x2A8C800016F9 and position 0x1D404000001A) lead to constant and null values, but it was worth investigating them anyway to ensure we did not miss any important details.

db    db db    db db      d8b   db .d8888.  .o88b.  .d8b.  d8b   db
88    88 88    88 88      888o  88 88'  YP d8P  Y8 d8' `8b 888o  88
Y8    8P 88    88 88      88V8o 88 `8bo.   8P      88ooo88 88V8o 88
`8b  d8' 88    88 88      88 V8o88   `Y8b. 8b      88~~~88 88 V8o88
 `8bd8'  88b  d88 88booo. 88  V888 db   8D Y8b  d8 88   88 88  V888
   YP    ~Y8888P' Y88888P VP   V8P `8888Y'  `Y88P' YP   YP VP   V8P


[*]     Loading Trace.
[*]     Exception found in trace file!
[*]     Current instruction: mov         rax,qword ptr [rcx+8]
[*]     Current position: 0x2D0780000001
[*]     Source effective address: 0xA0000000A
[*]     Tainting back register: rcx
[*]     Register value: 0xA00000002
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         rcx,qword ptr [rsp+00000088h]
[*]     Current position: 0x2D0740000FE7
[*]     Source effective address: 0x99C17FDCF8
[*]     Source memory value: 0xA00000002
[*]     Memory is initialized @TTTPos: 49509161766887.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x99C17FDCF8
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         qword ptr [r15],rax
[*]     Current position: 0x2D0740000FD0
[*]     Source memory value: 0xA00000002
[*]     Tainting back register: rax
[*]     Register value: 0xA00000002
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         rax,qword ptr [rcx+18h]
[*]     Current position: 0x2D0740000FCC
[*]     Source effective address: 0x2967D8CC0C0
[*]     Source memory value: 0xA00000002
[*]     Memory is initialized @TTTPos: 49509161766860.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x2967D8CC0C0
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         dword ptr [r10+rax*4+18h],r11d
[*]     Current position: 0x2CFA8000014D
[*]     Source memory value: 0xA
[*]     Pointer size mismatch detected!
[*]     Tainting back register: r11d
[*]     Register value: 0xA
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         r11d,r8d
[*]     Current position: 0x2CFA8000013E
[*]     Tainting back register: r8d
[*]     Register value: 0xA
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         r8d,r9d
[*]     Current position: 0x2CFA8000013A
[*]     Tainting back register: r9d
[*]     Register value: 0xA
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         r9d,dword ptr [rdi+rax*4+18h]
[*]     Current position: 0x2CFA8000012C
[*]     Source effective address: 0x2967D8B4898
[*]     Source memory value: 0xA
[*]     Memory is initialized @TTTPos: 49454400930092.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x2967D8B4898
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         qword ptr [rax],rcx
[*]     Current position: 0x2CC280001D5A
[*]     Source memory value: 0x140000000A
[*]     Pointer size mismatch detected!
[*]     Tainting back register: rcx
[*]     Register value: 0x140000000A
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         rcx,qword ptr [rdx]
[*]     Current position: 0x2CC280001D59
[*]     Source effective address: 0x2967E1B4070
[*]     Source memory value: 0x140000000A
[*]     Memory is initialized @TTTPos: 49213882768729.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x2967E1B4070
[*]     ----------------------------------------------------------------------
[*]     Current instruction: movups      xmmword ptr [rcx-10h],xmm0
[*]     Current position: 0x2C68400005CB
[*]     Source memory value: 0x140000000A
[*]     Tainting back register: xmm0
[*]     Register value: 0x140000000A
[*]     ----------------------------------------------------------------------
[*]     Current instruction: movups      xmm0,xmmword ptr [rdx+rcx]
[*]     Current position: 0x2C68400005C7
[*]     Source effective address: 0x2967D713D30
[*]     Source memory value: 0x140000000A
[*]     Memory is initialized @TTTPos: 48826261964231.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x2967D713D30
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         dword ptr [rax+8],ecx
[*]     Current position: 0x2C4A80000537
[*]     Source memory value: 0x14
[*]     Pointer size mismatch detected!
[*]     Tainting back register: ecx
[*]     Register value: 0x14
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         ecx,dword ptr [rdx+8]
[*]     Current position: 0x2C4A80000535
[*]     Source effective address: 0x2967E1BC078
[*]     Source memory value: 0x14
[*]     Memory is initialized @TTTPos: 48698486687029.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x2967E1BC078
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         dword ptr [rbx+rcx*4+4],eax
[*]     Current position: 0x2C4A800004E5
[*]     Source memory value: 0x14
[*]     Tainting back register: eax
[*]     Register value: 0x14
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         eax,dword ptr [rbp+18h]
[*]     Current position: 0x2C4A800004E0
[*]     Source effective address: 0x2967DDB9AA8
[*]     Source memory value: 0x14
[*]     Memory is initialized @TTTPos: 48698486686944.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x2967DDB9AA8
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         dword ptr [rax+18h],ebp
[*]     Current position: 0x2A8C80001858
[*]     Source memory value: 0x14
[*]     Tainting back register: ebp
[*]     Register value: 0x14
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         ebp,edx
[*]     Current position: 0x2A8C80001827
[*]     Tainting back register: edx
[*]     Register value: 0x14
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         edx,dword ptr [rdi+000000E0h]
[*]     Current position: 0x2A8C8000181F
[*]     Source effective address: 0x99C17FEE00
[*]     Source memory value: 0x14
[*]     Memory is initialized @TTTPos: 46782931277855.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x99C17FEE00
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         dword ptr [rax],edx
[*]     Current position: 0x2A8C80001738
[*]     Source memory value: 0x14
[*]     Tainting back register: edx
[*]     Register value: 0x14
[*]     ----------------------------------------------------------------------
[*]     Current instruction: cvttsd2si   edx,xmm1
[*]     Current position: 0x2A8C80001728
[*]     Tainting back register: xmm1
[*]     Register value: 0x4034000000000000
[*]     ----------------------------------------------------------------------
[*]     Current instruction: movsd       xmm1,mmword ptr [rbp+58h]
[*]     Current position: 0x2A8C80001725
[*]     Source effective address: 0x99C17FE550
[*]     Source memory value: 0x4034000000000000
[*]     Memory is initialized @TTTPos: 46782931277605.
[*]     Memory was initialized!
[*]     Tainting back memory: 0x99C17FE550
[*]     ----------------------------------------------------------------------
[*]     Current instruction: movsd       mmword ptr [rdi],xmm0
[*]     Current position: 0x2A8C80001719
[*]     Source memory value: 0x4034000000000000
[*]     Tainting back register: xmm0
[*]     Register value: 0x4034000000000000
[*]     ----------------------------------------------------------------------
[*]     Current instruction: movaps      xmm0,xmm1
[*]     Current position: 0x2A8C8000170D
[*]     Tainting back register: xmm1
[*]     Register value: 0x4034000000000000
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mulsd       xmm1,mmword ptr [rdx+rax*8]
[*]     Current position: 0x2A8C80001709
[*]     Source effective address: 0x7FFC239B2358
[*]     Source memory value: 0x4024000000000000
[*]     Adding junction to taint register: xmm1
[*]     ----------------------------------------------------------------------
[*]     Processing junction..
[*]     Current instruction: mulsd       xmm1,mmword ptr [rdx+rax*8]
[*]     Tainting register: xmm1
[*]     Register value: 0x4000000000000000
[*]     Current instruction: cvtsi2sd    xmm1,rax
[*]     Current position: 0x2A8C80001701
[*]     Tainting back register: rax
[*]     Register value: 0x2
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         eax,esi
[*]     Current position: 0x2A8C800016FF
[*]     Tainting back register: esi
[*]     Register value: 0x2
[*]     ----------------------------------------------------------------------
[*]     Current instruction: lea         esi,[rax+rsi*2]
[*]     Current position: 0x2A8C800016FA
[*]     Adding junction to taint register: rsi
[*]     Tainting back register: rax
[*]     Register value: 0x32
[*]     ----------------------------------------------------------------------
[*]     Current instruction: movzx       eax,al
[*]     Current position: 0x2A8C800016F8
[*]     Tainting back register: al
[*]     Register value: 0x32
[*]     ----------------------------------------------------------------------
[*]     Current instruction: movzx       eax,byte ptr [rbx]
[*]     Current position: 0x2A8C800016F4
[*]     Source effective address: 0x28E6922DCA8
[*]     Tainting back memory: 0x28E6922DCA8
[*]     ----------------------------------------------------------------------
[*]     Current instruction: rep movs    byte ptr [rdi],byte ptr [rsi]
[*]     Current position: 0x1D420000037E
[*]     Source effective address: 0x28E692302E8
[*]     Source memory value: 0x0
[*]     Tainting back memory: 0x28E692302E8
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         qword ptr [rcx+28h],rdx
[*]     Current position: 0x1D40400000A7
[*]     Source memory value: 0xC0C0C0C0C0C0C0C0
[*]     Pointer size mismatch detected!
[*]     Tainting back register: rdx
[*]     Register value: 0xC0C0C0C0C0C0C0C0
[*]     ----------------------------------------------------------------------
[*]     Current instruction: imul        rdx,r9
[*]     Current position: 0x1D404000001C
[*]     Adding junction to taint register: rdx
[*]     Tainting back register: r9
[*]     Register value: 0x101010101010101
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         r9,101010101010101h
[*]     Current position: 0x1D404000001B
[*]     Tainted register is set to constant value!
[*]     ----------------------------------------------------------------------
[*]     Processing junction..
[*]     Current instruction: lea         esi,[rax+rsi*2]
[*]     Tainting register: rsi
[*]     Register value: 0xFFFFFFE8
[*]     Current instruction: lea         esi,[rsi-18h]
[*]     Current position: 0x2A8C800016F9
[*]     Tainting back register: rsi
[*]     Register value: 0x0
[*]     ----------------------------------------------------------------------
[*]     Current instruction: lea         esi,[rsi+rsi*4]
[*]     Current position: 0x2A8C800016F7
[*]     Tainting back register: rsi
[*]     Register value: 0x0
[*]     ----------------------------------------------------------------------
[*]     Current instruction: xor         esi,esi
[*]     Current position: 0x2A8C80001696
[*]     Tainted register got zeroed!
[*]     ----------------------------------------------------------------------
[*]     Processing junction..
[*]     Current instruction: imul        rdx,r9
[*]     Tainting register: rdx
[*]     Register value: 0xC0
[*]     Current instruction: movzx       edx,dl
[*]     Current position: 0x1D404000001A
[*]     Tainting back register: dl
[*]     Register value: 0xC0
[*]     ----------------------------------------------------------------------
[*]     Current instruction: mov         edx,0C0h
[*]     Current position: 0x1D4040000011
[*]     Tainted register is set to constant value!
[*]     ----------------------------------------------------------------------
[*]     Type Confusion vulnerability detected !!!
[*]     Loading Symbols.
[*]     Building output.
[*]     Writing findings to file: n:CVE-2017-0134ch.run.html
[*]     Analysis finished in 00:01:08

This initial output provides us with an assembly language analysis of the bug. VulnScan then produces a more detailed report, containing the register values, source code, local variables, and call stack. This assists the product developers in providing an accurate and comprehensive fix.

Using the data obtained from both reports we can start investigating the source code in between crashing location and triggered heuristic. We can observe that the value used as a pointer is being set as an array element in Js::JavascriptArray::DirectSetItemInLastUsedSegmentAt and it comes from the Js::JavascriptArray::EntryConcat function. Jordan found a way to change the array type by using a custom getter on a property of the IntArray object to change the array type to VarArray. Functions JavascriptArray::ConcatIntArgs (as shown on the call stack in report) and JavascriptArray::ConcatFloatArgs use the Symbol.isConcatSpreadable property of the array object, and it is a custom getter on that symbol that can be used to change the array type. This caused concatenated IntArray items to be written to a VarArray instead of an IntArray after the type change, which led to array object corruption. A fix for this issue was introduced in this ChakraCore commit.

That’s it for today. If you would like to hear more about this tool, and the heuristics and taint techniques used please leave feedback. Our next steps highly depend on community response. The tool is frequently updated with new heuristics and features requested by users of the tool within Microsoft.

Shout outs to MSRC UK team for feedback and ideas, Jordan Rabet for the bug he found, Steven Hunter, Matt Miller and Gavin Thomas for the help in writing this blog post. Kudos should also fly to WinDbg, TTD, Sonar and Microsoft Security Risk Detection teams for amazing tools they developed.

Mateusz Krzywicki from Microsoft Security Response Center (UK).

去る 9 月 25 日(月)～ 29 日(金)に米国フロリダ オーランドで開催され、今年も大盛況だった Microsoft Ignite 2017。様々な先進的技術や、最新のマイクロソフトテクノロジーについてのハイライトと、11 月 8 日(水)～ 9 日(木)で開催される Tech Summit 2017 の見どころを、Tech Summit の各トラックオーナーからポイントを絞ってわかりやすくお伝えします。

ビジネス推進をされる IT  リーダーや IT  プロフェッショナルの皆様必見です。
この機会に是非ご参加ください。

▼ ライブ配信はこちらから

・日時
10 月 4 日(水)  18:00～19:00

・キャスト
井上 大輔（日本マイクロソフト㈱ デベロッパーエバンジェリズム統括本部 テクニカルエバンジェリスト）
冨永 晶子（日本マイクロソフト㈱ クラウド＆エンタープライズビジネス本部 シニアプロダクトマネ－ジャ－）
安納 順一（日本マイクロソフト㈱ コマーシャルソフトウェアエンジニアリング本部 プリンシパルテクニカルエバンジェリスト）
井上 章（日本マイクロソフト㈱ パートナー事業本部パートナー技術統括本部 テクニカルエバンジェリスト）
松崎 剛（日本マイクロソフト㈱ パートナー事業本部パートナー技術統括本部 テクニカルエバンジェリスト）
兼城 鮎美（日本マイクロソフト㈱  Dynamics ビジネス本部 プロダクトマ－ケティングマネ－ジャ－）
渡辺 弘之（日本マイクロソフト㈱ パートナー事業本部パートナー技術統括本部 テクニカルエバンジェリスト）
山本 美穂（日本マイクロソフト㈱ パートナー事業本部パートナー技術統括本部 テクニカルエバンジェリスト）

*キャストにつきましては、予告なく変更となる場合があります。また、一部のセッションは収録による配信となります。あらかじめご了承ください。

こんにちは、Azureサポートチームの三國です。

今回は、ARMのWindowsでディスクやVMレベルでのIOスロットリングを監視・通知する方法についてご案内いたします。

本記事は下記英文ブログの抄訳です。
How to monitor and alert potential Disk and VM Level IO Throttling on Windows VMs using ARM
https://blogs.msdn.microsoft.com/mast/2017/09/12/how-to-monitor-and-alert-potential-disk-and-vm-level-io-throttling-on-windows-vms-using-arm/

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

はじめに

本ブログはAzure上にあるWindows VMのディスクパフォーマンス監視手順について紹介します。
ディスクやVMレベルでのIOスロットリングについて検出することが目的です。
本ガイドラインはAzure Resource ManagerにてデプロイされているAzure上のすべてのバージョンのWindowsに適用できます。

手順の紹介に入る前に、3つの前提となる概念について説明します。

スロットリングとは？
Azure Premium Storage では、選択された VM サイズとディスク サイズに応じて、指定された数の IOPS とスループットがプロビジョニングされます。 アプリケーションが、VM またはディスクが対応できるこれらの上限を超えて IOPS やスループットを試みると、これを抑制するように調整されます。 これは、アプリケーションのパフォーマンスの低下という形で現れます。 これにより、待機時間が長くなり、スループットや IOPS が低下する可能性があります。スロットリングにはディスクレベルとVMレベルの2種類があります。
詳細については以下のドキュメントをご確認下さい。

https://docs.microsoft.com/ja-jp/azure/storage/common/storage-premium-storage-performance#throttling

ディスクレベルのスロットリングとは？。
基本的に、ディスクの制限値を超えたIOについてはすべて滞留しより大きな遅延が発生します。
管理ディスク・非管理対象ディスクの制限値については以下のドキュメントをご参照ください。

https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/sizes-general#dsv2-series

VMレベルのスロットリングとは？
基本的に、VMにアタッチされたディスクの総IOがスループット制限を超えた場合にVMレベルのスロットリングが発生します。制限値はキャッシュ/非キャッシュで異なります。こちらはPremium ディスクをお使いの場合のみ該当します。Standard ディスクをお使いの場合にはVMレベルのIOスロットリングという概念はありません。
IOスロットリングの詳細については、以下のドキュメントをご参照ください。
https://blogs.technet.microsoft.com/xiangwu/2017/05/14/azure-vm-storage-performance-and-throttling-demystify/

準備

本ブログの説明に用いるVMの構成例を以下に記載します。
VM名: "MonitorVM"
VMサイズ : DS2_v2
Disk 構成:
以下の4データディスクをVMにアタッチします:
2x P10 (128 GB - Disk limits: 500 IOPS or 100 MB/s - Disk Cache Setting: None)
1x P20 (512 GB - Disk limits: 2300 IOPS or 150 MB/s - Disk Cache Setting: None)
1x P30 (1024 GB - Disk limits: 5000 IOPS or 200 MB/s - Disk Cache Setting: None)

本シナリオでは、上記のようにアタッチされたディスクすべてについてキャッシュが無効になっています。そのためVMの非キャッシュディスクスループット制限(IOPS/MBps)について確認します。下記のURLの"キャッシュが無効な場合の最大ディスク スループット: IOPS/MBps"より確認できます。
https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes-general#dsv2-series

キャッシュを有効にする場合は、上記URLの"キャッシュが有効な場合の一時ストレージの最大スループット: IOPS/MBps (キャッシュ サイズは GiB 単位)"よりVMにおける一時ストレージのスループット制限(IOPS/MBps)を確認できます。

"MonitorVM"VM内部のディスク設定の詳細について

Fドライブに、P10ディスクを2つ用いて復元力を備えた記憶域を構成し、1000IOPS(2 x 500 IOPS)が制限値となります。

ディスク管理:

ファイルエクスプローラー:

"MonitorVM"VM内のパフォーマンスモニター:

VM内のパフォーマンスモニターでVMの物理ディスクのパフォーマンスカウンターについてカウンター名が確認ができました。
次に、以下のパフォーマンスカウンターについてVMの診断設定に追加し、IOPSをAzureポータルで監視する方法をご案内します。

IOPS:

"PhysicalDisk(_Total)Disk Transfers/sec" (VM レベルのスロットリング - 6400 IOPS)
"PhysicalDisk(0 C:)Disk Transfers/sec" (ディスクレベルのスロットリング - OS disk P10 - 500 IOPS)
"PhysicalDisk(2)Disk Transfers/sec" (ディスクレベルのスロットリング - P10 disk - 500 IOPS)
"PhysicalDisk(3)Disk Transfers/sec" (ディスクレベルのスロットリング - P10 disk - 500 IOPS)
"PhysicalDisk(4 G:)Disk Transfers/sec" (ディスクレベルのスロットリング - P20 disk - 2300 IOPS)
"PhysicalDisk(5 H:)Disk Transfers/sec" (ディスクレベルのスロットリング - P30 disk - 5000 IOPS)
"PhysicalDisk(6 F:)Disk Transfers/sec" (ディスクレベルのスロットリング - 記憶域スペースドライブ - 1000 IOPS)

Azureポータルでパフォーマンスカウンターを監視するには？

パフォーマンスカウンターはAzureポータルの診断設定にて追加できます。

追加手順を以下に記載します。
・Azureポータルの"MonitorVM"VMのページへ移動します
・VMブレードの"Diagnostic settings"を選択し、"Performance counter"タブへ移動します(図中1.)
・パフォーマンスカウンターを追加するため"Custom"(図中2.)を選択します
・テキストボックス(図中3.)にパフォーマンスカウンター名を入力します(例: PhysicalDisk(0 C:)Disk Transfers/sec)
・"Add"ボタン(図中4.)を押下し、パフォーマンスカウンターを追加します
・サンプルレートをテキストボックス内(図中5.)に入力します
・最後に"Save"ボタンを押下し構成を保存します

サンプルレートはパフォーマンスカウンターを収集する頻度です。デフォルトでは60秒に指定されているため、60秒ごとにパフォーマンスカウンターが収集されます。ディスク負荷の変化が激しい場合は収集頻度を10秒、あるいは1秒に短縮してIOがディスクやVMの制限に到達していないかを確認できます。ディスク負荷の変化が緩やかな場合はサンプルレートを大きくすることもできます。サンプルレートはいつでも、すぐに変更でき、Azureポータルの"Metrics"を通じて都度検証することができるので、ぜひ適切な値を環境に応じて調整してみてください。

収集した情報を確認するには？

下図のようにAzureポータルの"Metrics"より確認ができます。

下図はVMレベルスロットリングを監視するための設定例です。

まとめ

こんにちは、Azureサポートチームの三國です。
今回は、Azureの仮想マシン名を変更する方法および注意点についてご案内します。
本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

目次

1. はじめに: 仮想マシン名とは

2. 注意: 仮想マシン名は簡単には変更できない

簡単に変える手順を期待していた方、申し訳ございません。仮想マシン名を簡単に変更することはできません。
仮想マシン名はAzureが管理するリソース情報と密接にかかわっているためです。
今回ブログを書くにあたり、手順がわかっていても、20分程度かかりました。
また、"仮想マシン名"を変更するにあたりダウンタイムが発生する、というデメリットもございます。
その点を踏まえて、次項以降をご覧ください。

3. 想定ケース

4. 変更手順

4-1. 引き継ぎたい情報を確認する

以下のように、引き継ぎたい情報を確認します。

-仮想マシンのサイズ

-仮想ネットワーク、サブネット名

-ディスク名

-可用性セット名

-起動診断に用いるストレージアカウント名

4-2. 仮想マシン、ネットワークインターフェイスを削除する

-仮想マシンを削除します

-ネットワークインターフェイスを削除します

4-3. 仮想マシンを新しい名前で作成する

-ディスクを選択し、仮想マシンの作成を開始します

-確認した情報をもとに、引き継ぎたいパラメータで仮想マシンを作成します

-仮想マシンの名前が変わっていることが確認できます

4-4. データディスクを接続する

-データディスクをご利用の場合は、接続します。

5. 仮想マシン名の代わりにタグでも管理できる

それでは、どのようにすればよいのでしょうか。

Windows Server 2012 の Active Directory で導入された Resource SID Compression の機能の影響により、AD を移行後にサードパーティー製の NAS へアクセスできなくる事象について解説します。

- 現象

ドメインに Windows Server 2012 以降のドメイン コントローラーを追加した後に、クライアントからサードパーティー製の NAS の共有フォルダーへアクセスを行うと、下記のようなアクセス許可がないことを示すメッセージが表示される場合があります。

\FileServerShare にアクセスできません

\FileServerShare に対するアクセス許可がありません。ネットワーク管理者にアクセス許可を要求してください。

本事象はサポート技術情報 2774190 で公開しています。

 Resource SID Compression in Windows Server 2012 may cause authentication problems on NAS devices

 サポート技術情報: 2774190

 http://support.microsoft.com/kb/2774190

ユーザーが所属するグループの数が数百と多い環境では、Kerberos のトークンサイズが大きくなり、認証に失敗する場合があります。

そのような背景から、追加で SID を圧縮する機能 (Resource SID Compression) がWindows Server 2012 以降のドメイン コントローラーからサポートされました。

Windows Server 2012 以降の KDC はチケット発行時、使用されるリソースに関する SID 情報を圧縮しますが、NAS デバイスでこの圧縮機能を理解できない場合、アクセス拒否が発生します。

- 対処方法

NAS デバイスが Resource SID Compression をサポートしてない場合、上記のサポート技術情報の Resolution に記載の通り、下記のいずれかの方法で Resource SID Compression を無効化することで対処を行うことができます。

----------------------------

- 対処方法 1 (推奨)

----------------------------

以下の手順をご実施いただくことにより、NAS のコンピューター オブジェクトを指定して Resource SID Compression を無効化できます。

- 手順

1. 任意のドメイン コントローラー 1 台に、管理者権限を持つユーザーでログオンします。

2. 後述のサポート技術情報 2774190 に記載されているスクリプトをコピーし、以下のファイル名で保存します。

DisableKerbGroupCompression.ps1

-- ここから --

#

# Script to Disable Kerberos Group SID Compression #

～～(中略)～～

else

{ Write-Host "Resource group compression did not change."}

-- ここまで --

3. コマンド プロンプトを起動して、以下のコマンドを実行します。

  Powershell.exe -ExecutionPolicy Unrestricted -File C:WorkDisableKerbGroupCompression.ps1 <NAS のコンピューター オブジェクト名>

上記手順を実行することで、指定したコンピューター オブジェクトの msDS-SupportedEncryptionTypes 属性にフラグ 0x80000 が付与されます。

これにより指定したコンピューター オブジェクトに対する Resource SID Compression が無効化されます。

対処方法1 はスクリプトを実行すると即時反映されます。

----------------------------

- 対処方法 2

----------------------------

方法 1 が指定したコンピューター オブジェクトに対する無効化であるのに対し、方法 2 はドメイン コントローラー単位でこの機能を無効化します。

ドメイン コントローラー上で以下のレジストリ キーを設定する事で、Resource SID Compression を無効化します。

キー: HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemKdcParameters

値の名前: DisableResourceGroupsFields

値の種類: REG_DWORD

値のデータ: 1

※ レジストリ値が存在しない場合は、新たに作成します。

この方法はドメイン コントローラー単位での構成となるため、環境内で KDC として稼働する Windows Server 2012 のドメイン コントローラー全台に対して同じ設定をする必要があります。この解決方法を用いた場合、設定を行った Windows Server 2012 の KDC で、すべての Kerberos チケットの発行においてこの機能が無効化されます。

対処方法2 は反映のため、設定を変更したドメイン コントローラーにて OS や KDC サービスの再起動を行う必要ありません。

- 対処方法1 の値の場所

---------------------------------------------------------------

対処方法1 のスクリプトでは、NAS のオブジェクトに含まれる msDS-SupportedEncryptionTypes という属性に Resource SID Compression が無効となっていることを示すフラグ 0x0080000 を追加しています。

msDS-SupportedEncryptionTypes 属性の値は下記の手順で確認することができます。

<確認方法>

1) いずれか 1 台のドメイン コントローラーにログオンします。

2) [スタート] - [管理ツール] - [Active Directory ユーザーとコンピューター] を起動します。

3) [表示] メニューの中の [拡張機能] の左側にチェックが付いていない場合は、選択してチェックを付けます。

4) NAS のオブジェクトが格納された OU を開き、その中から NAS のオブジェクトを右クリックして [プロパティ] を開きます。

5) 属性から msDS-SupportedEncryptionTypes の値を確認します。

※ "<未設定>" と表示されている場合は、値が設定されていないことを示します。

- Resource SID Compression を無効にした場合の影響

---------------------------------------------------------------

Resource SID Compression の無効化は Windows Server 2012 以降の設定であり、Windows Server 2008 R2 以前のドメイン コントローラーに影響を及ぼすことはありません。 

ドメインのユーザーは NAS へアクセスするための Kerberos サービス チケットを KDC (ドメイン コントローラー) から取得して、そのチケットを NAS へ提示することで認証が行われます。

Windows Server 2012 以降のドメイン コントローラーでは、Resource SID Compression が既定で有効となっているため、SID を圧縮してチケットを発行します。一方、Windows Server 2008 R2 の DC では圧縮せずにチケットを発行します。

Resource SID Compression を無効にすると、Windows Server 2008 R2 以前と同様の動作になり、サービス チケット発行時に SID が圧縮されなくなります。

つまり、既存の Windows Server 2008 R2 のドメイン コントローラーと同様の動作となるため、無効にすることで既存の環境に対して影響が及ぶことはありません。

また、NAS のオブジェクトの 「msDS-SupportedEncryptionTypes」 の値を設定した場合は、NAS のサービス チケットを払い出すときのみ、Resource SID Compression が無効化されます。無効化による影響は NAS のみとなり、現行の運用に影響を及ぼすことは想定されません。

- msDS-SupportedEncryptionTypes について

---------------------------------------------------------------

「msDS-SupportedEncryptionTypes」 はユーザーやコンピューター アカウントでサポートされる暗号化アルゴリズムを定義するため値であり、KDC (ドメイン コントローラー) がサービスチケットを生成するときにこの値が参照されます。

この値に 「0x0080000」 が設定されているオブジェクトは Resource SID Compression が無効となっていることを示し、SID を圧縮せずにサービス チケットが生成されます。

- 参考資料

2.464 Attribute msDS-SupportedEncryptionTypes

https://msdn.microsoft.com/ja-jp/library/cc220375.aspx

----------------------

This attribute specifies the encryption algorithms supported by user, computer, or trust accounts. The Key Distribution Center (KDC) uses this information while generating a service ticket for this account. Services and computers can automatically update this attribute on their respective accounts in Active Directory, and therefore need write access to this attribute.

----------------------

2.2.7 Supported Encryption Types Bit Flags

https://msdn.microsoft.com/ja-jp/library/ee808210.aspx

2.2.7 Supported Encryption Types Bit Flags

https://technet.microsoft.com/ja-jp/ee808210

Online, Online, Online. Všichni to známe to známe, trend posledních několika let - vše Online.

S rozmachem Online technologií a služeb je tak logicky využíváno stále více těchto "Online" služeb. Relativně novou službou, která ovšem rozhodně stojí za zmínku a časem o ní uslyšíme stále více, je Microsoft Flow. Služeb, o kterých ještě uslyšíme je samozřejmě mnohem více, v tomto článku bude řeč především o Microsoft Flow a jeho praktickém využití s příkladem.

Samotné Flow asi není převratnou myšlenkou, leckdo již zná a používá služby jako IFTT nebo Zapier, které propojují další Online služby a automatizují tak některé úkony. V případě IFTT to navíc skoro vypadá, že dalo těmto službám název - If This Then That.

Microsoft Flow je Online služba, která je také schopna automatizovat některé úkony. Stejně jako ostatní služby poskytuje verzi zdarma i placenou, rozdíly najdete zde. Nenechte se však mýlit, Microsoft Flow není "JEN" dalším produktem tohoto typu, ačkoliv se to tak na první pohled může zdát. Microsoft Flow má v Online světě velký potenciál. Microsoft to se svým Flow myslí tak vážně, že Flow je zamýšleno jako náhrada pro Workflow, které jsou doposud vytvářena pomocí aplikace SharePoint Designer. A mimo jiné, jeho odlišností a výhodou oproti jiným produktům je těsnější integrace právě na SharePoint. Integrace do On Premises prostředí je možná pomocí On Premises data gateway, která Vaše On Premises data zpřístupní bezpečně do Online světa.

Protože se jedná o relativně novou službu, možností napojení na další aplikace je celkově méně než u konkurenčních služeb, ale Microsoft Flow využívá trochu jiný koncept a tím umožňuje i jiné možnosti. Celá služba se navíc nadále rozvíjí a náskok konkurence se snaží dotáhnout. Pro řadu scénářů je vhodnější využít Microsoft Flow oproti jiným službám. Velmi důležitý je také fakt, že oproti klasickým SharePoint Workflow není Microsoft Flow na SharePointu vůbec závislé. Z pohledu Microsoft Flow je SharePoint pouze další službou, na kterou se Microsoft Flow umí napojit (číst/zapisovat).

U Microsoft Flow ale nejde samozřejmě pouze o těsnější integraci do SharePointu, nebo ostatních Microsoft služeb, Microsoft Flow lze napojit do celé řady služeb třetích stran, ve kterém nechybí nejznámější nejpoužívanější aplikace. Jejich seznam najdete zde.

Jednoduché schéma jak funguje výše zmíněná „Data Gateway“, lze pochopit z následujícího obrázku, kde je vidět, že Gateway může sloužit nejen pro služby jako je Microsoft Flow, Power BI, ale také PowerApps atp.

Work less, do more

V následujícím článku popíšeme konkrétní praktický příklad využití technologií SharePoint Online, Microsoft Flow a Microsoft Power BI. Doufáme, že následující příklad Vám bude sloužit jako motivace, jak lze jednotlivé služby využít a vzájemně propojit a využít jejich potenciál.

Příklad:

1. SharePoint schvalování nákupů

V hlavní roli:

1. SharePoint Online
2. Microsoft Flow
3. Power BI

Platformu SharePoint obecně je možné využívat různými způsoby, nejen k ukládání dokumentů, jejich verzování, sdílení a schvalování, zkrátka tak, jak ji většina uživatelů zná a používá, ale také k automatizaci procesů.
Tento příklad ukáže, jak lze jednoduše „naklikat“ proces schvalování nákupů od A do Z s využitím Microsoft Flow.
Pozornost bude věnována tomu, jak vytvořit:

1. strukturu v SharePointu
2. napojit data do Microsoft Flow
3. vytvořit alerty v Power BI

Všechny zmíněné služby jsou dostupné v rámci Office 365 subskripce a nejsou potřeba žádné další licence.

SharePoint Online

Nejlépe je začít názornou ukázkou.

1. V tomto příkladu budeme v SharePoint Online potřebovat seznam „Nákupy“, s vytvořenými sloupci dle předlohy.
2. Uživatel bude vyplňovat pouze pole „Předmět“ a cenu v poli „Celková částka“.
3. Ve sloupci „Oddělení“ je pouze informace, která slouží pro lepší kategorizaci, na vlastní proces schvalování nemá vliv.
4. Vše ostatní doplníme automatizovaně pomocí Microsoft Flow.

Tímto veškerá příprava na straně SharePoint Online končí a dále bude následovat tvorba procesu.

Microsoft Flow

Jak bylo již zmíněno výše, Microsoft Flow není pouhou náhradou SharePoint Workflow. Microsoft Flow se nám snaží dát další možnosti pro automatizaci procesů a nijak na platformě SharePoint není závislé.
Microsoft Flow obsahuje různé aktivační události neboli triggery. Ty určují, kdy se má Flow spustit. V době psaní tohoto článku existuje 164 triggerů a 267 akcí. Typickým příkladem triggeru a následné akce je následující: do Outlooku dorazí email, pokud obsahuje přílohu, uloží ji na OneDrive.
Není třeba instalovat žádnou aplikaci, není potřeba mít speciální znalosti. Stačí jen prohlížeč a během několika málo kliků je Flow vytvořeno. Všechny triggery a akce jsou přeloženy i do češtiny, a tak je Flow dostupné i běžnému uživateli.

Poznámka:
Vytvořené Flow je dostupné pouze autorovi. Aby Flow mohla spravovat i další osoba, je třeba jej nastavit jako vlastníka. Toto sdílení je dostupné pouze pokud jste přihlášeni Office 365 účtem. Flow můžete používat i se svým osobním Microsoft Account (původně Live ID).

Pokud máte zkušenosti s vyvářením SharePoint Workflow, měli byste vědět, že Flow se nespouští ihned při vytvoření položky, ale v časovém intervalu až 5 minut. Může se tedy stát, že bude chvíli trvat, než dojde k zahájení procesu. Z vlastní zkušenosti je však ověřeno, že ke spuštění Flow dochází v řádu vteřin.

Flow neboli česky „Tok“ můžeme vytvořit buď tak, že si otevřeme stránku https://flow.microsoft.com nebo v SharePoint seznamu klikneme na „Tok“, „Vytvořit Tok“. Výsledek je stejný, jen v prvním případě musíme zadat URL adresu SharePoint webu sami.

Nyní vytvoříme proces schvalování. Ten může vypadat následovně a vzápětí si jej i popíšeme.

1. Po vytvoření položky v seznamu „Nákupy“ se spustí Flow, které si následně načte profil žadatele (autora položky) a jeho nadřízeného (schvalovatele).
   • Profil žadatele v našem případě potřebujeme znát kvůli názvu oddělení, které následně doplníme k žádance
   • Profil nadřízeného potřebujeme pro získání jeho emailové adresy a odeslání žádosti o schválení nákupu
2. Aby kdokoliv, kdo otevře seznam „Nákupy“, věděl, v jakém stavu je aktuální žádost, nastavíme stav na „Čeká na schválení“.
   • Jedná se o aktivitu „Aktualizovat položku“, kde nastavíme oddělení, stav a schvalovatele.
3. Hlavním bodem celého Flow je schválení samotné žádanky. To se provádí aktivitou „Poslat e-mail se schválením“.
   • V konfiguraci aktivity použijeme email schvalovatele, kterému se odešle speciální email s tlačítky pro schválení, resp. zamítnutí žádosti.
4. Po dokončení úkolu schvalovatelem se provede vyhodnocení, zda byl úkol dokončen jako schválený či jako zamítnutý a podle toho se aktualizuje stav položky.
5. Na závěr se odešle email žadateli, čímž celé Flow končí.

V průběhu tvorby procesu se může stát, že dojde k neočekávané chybě. V historii průběhů se můžeme podívat na detail průběhu, zjistit, kde se něco nepovedlo, a dokonce uvidíme i hodnoty, se kterými Flow pracovalo v době běhu. Oproti SharePoint Workflow je to veliká pomoc při debuggování!

Power BI

Jistě není třeba popisovat k čemu slouží Power BI. Zjednodušeně je to další Online služba, určená pro vizualizaci dat pomocí reportů a dashboardů. Méně známou možností je však vytvoření tzv. „data-driven alerts“. Ty nám umožní hlídat klíčové hodnoty (čísla) a na základě nich provést další akce.

Ve chvíli, kdy je splněna definovaná podmínka se odešle email nebo (a teď se podržte ) se spustí Flow (například eskalace, že v daném termínu nedošlo k vyřešení, atp.). Všechno do sebe skvěle zapadá a vzájemně se doplňuje.

Poznámka:
Reporty se vytvářejí pomocí aplikace Power BI Desktop, která je dostupná zdarma. Připojení dat ze SharePointu je otázka několika málo kliků. Pokud byste chtěli využít data v On Premises prostředí (např. SharePoint Server, SQL server, MySQL, IBM, SAP atp.), musíte použít On Premises data gateway.

1. Na našem jednoduchém dashboardu vidíme čerpání rozpočtu po jednotlivých odděleních. Konkrétně nás zajímá vizuál typu Card (vpravo na obrázku), který jako jeden z mála (Card, KPI, Gauge) umí spustit Alert (výstraha).
   
2. Otevřením nabídky vizuálu pomocí ellipsis (…) a následným vybráním „Spravovat výstrahy“ (ikona zvonku) se dostaneme na místo, kde lze definovat podmínky pro vytvoření výstrahy. V našem případě chceme spustit výstrahu tehdy, pokud hodnota na vizuálu přesáhne 10 000 Kč.
   
3. Pomocí odkazu ve spodní části dialogu můžeme vytvořit Flow, které se spustí současně s výstrahou a provede požadovanou akci. Např. odešle email definované osobě.
   

Závěrem

Na uvedeném přikladu je vidět, že využití Microsoft Flow opravdu není složité a zvládne i běžný uživatel. Do uvedeného příkladu můžete zapojit i využití dalších Online služeb, fantazii se meze nekladou. Nebojte se proto pohrát si s možnostmi a nezapomeňte také, že s využitím On Premises data gateway, lze Microsoft Flow napojit i na data, která nejsou uložena v Online službách.

Pro více informací o Microsoft Flow navštivte web https://flow.microsoft.com/cs-cz.

- Lukáš Nešpor, Jakub Urban (KPCS CZ)

現在您在多個不同的地區都可以建立 OMS 工作區。除了美國東部、西歐之外，在東南亞、澳洲東南部、和美國中西部都可以建立 OMS 工作區。

您可以從 www.microsoft.com/oms 概觀來建立一個 OMS 工作區並選擇其存放的地區，如下圖：

或是在 Azure 入口網站，新建立一個 Log Analytics(OMS) 時，可以選擇工作區的地區，如下圖：

本記事は、Ann Johnson (Vice President、Enterprise Cybersecurity Group) による Microsoft Secure Blog への投稿 “Microsoft’s perspective on cyber resilience” (2017 年 8 月 23 日 米国時間公開) を翻訳したものです。

最近発生したランサムウェアの流行をきっかけに、影響を受けた企業がサイバー レジリエンスの計画と実施に関する考えをどう進化させたのかを理解したいと思っていました。そこで、お客様のサイバー攻撃への対応と回復をプロアクティブかつリアルタイムに支援するマイクロソフトの Detection and Response Team に依頼し、彼らの経験を共有してもらいました。以下に、チームが共有してくれたお客様のシナリオをいくつか匿名化して紹介しています。これらのシナリオでは、サイバー レジリエンス計画の緊急の必要性が提示されています。

それに続き、最先端の攻撃に直面した時に、お客様がさらに俊敏に動けるよう支援するマイクロソフトの能力に関する参照フレームワークを紹介します。言い換えると、この投稿ではサイバー レジリエンス確立への道のりを示します。

サイバー レジリエンスが重要な理由

世界中の組織は、個人およびビジネス関連のタスクを遂行する上でテクノロジに大きく依存しています。暦年 2017 年の 第 1 四半期の終わりには、全世界で 37 億人以上のインターネット ユーザー (英語情報) が存在し、その数は増え続けています。インターネットの普及が進むにつれて、攻撃対象も増加しています。現在のサイバーセキュリティの脅威ランドスケープは、人と資産に現実的な危険をもたらします。そのため、組織はアクセス許可とリスク管理のバランスを維持する必要があります。通常、企業組織のサイバーセキュリティに対するアプローチは、"保護" と "インシデント対応" を目的としたツール、テクノロジおよび人材の実装です。これが重要である一方、サイバーセキュリティのツールやテクノロジを実装する根本的な理由は事業継続です。企業組織は、戦略的なレベルで基幹システム、IT インフラストラクチャ、およびデータ センターを要塞化する方法の "全体像" を検討し、ダウンタイムを引き起こす人的エラーやサイバー脅威に直面した場合の回復力を保持するよう備えるべきです。ここでサイバー レジリエンス戦略の出番が来ます。組織は、セキュリティ インシデントが発生した場合でも事業継続を確保するために、自身のビジネス ニーズに沿ったサイバー レジリエンス戦略を構築し、サイバー レジリエンス プログラムを実行する必要があります。

アクセンチュア社の “State of Cybersecurity and Digital Trust” (英語情報) によると、調査へ参加した人の 75% がサイバーセキュリティの信頼度は高いと回答する一方、自組織がセキュリティ違反を監視する能力を信頼しているのはたったの 37%、サービス中断の最小化に関しては 36% でした。ガートナー社によるとダウンタイムにかかるコストの平均は 1 分あたり 5,600 米国ドル (英語情報)、つまり 1 時間あたり 300,000 米国ドルを超えます。ダウンタイムの原因で最も多いのは、人的エラーです。ある研究によると、ダウンタイムの原因の 75% が人的エラーによるもの (英語情報) と結論付けています。

未だかつてないほど組織が IT に依存している状況で、事業継続と災害対応 (BCDR) を IT チームのみに関連する問題としてではなく、組織全体にとって必須の要素として認識することが重要です。すべての企業組織は、不測の事態に起因する機能の停止状態に対応できるよう備える必要があります。基幹アプリケーションおよびサービスの中断は、生産性と運用の停止、収益減、および組織に対する顧客の信用の低下を引き起こす可能性があります。強力なサイバー レジリエンス計画が効果的に実行されれば、組織のコンピューター システム、IT インフラストラクチャおよびデータ センターはサイバー脅威と人的エラーに対抗することができます。

サイバー レジリエンスのシナリオ

サイバー攻撃やデータ漏えいに悩まされた組織に関する目新しい話はたくさんあります。サイバー レジリエンスを支援する戦略を立て、行動を取ることで、そのようなインシデントによる被害の範囲を減らし、回復コストを下げることができる可能性があります。

例 1 - 全世界的に複数の組織がランサムウェアに感染

2017 年の前半のランサムウェア攻撃によって、たとえランサムウェアでロックダウンされていても、重要なIP、システム、およびインフラストラクチャにアクセスできることの必要性が強調されました。ランサムウェアの WannaCry は、一定時間、生産停止を余儀なくされた自動車工場など、世界中で複数の業界や企業に影響を及ぼしました。攻撃の誘因にかかわらず、影響を受けた企業にとっては計画外のダウンタイムと回復コストをもたらす結果となったことは明らかです。

ここで重要なポイントは、ランサムウェアがどのような種類の組織に対しても影響を与えられるということです。コンピューター システムに修正プログラムを適用して最新の状態を保ち、定期的にデータのバックアップを取り、十分に検証した災害復旧計画を作成し、直接雇用の従業員や請負業者にサイバー脅威 (例えば、フィッシングやランサムウェア) に関する教育を提供することで、少なくともそのようなインシデントによる被害の範囲を減らすことに役立ちます。

例 2: 米国の医療産業で引き続きデータ漏えいが発生

医療データへのアクセスに成功したサイバー犯罪者が、利益を得る目的でそのデータを使用して詐欺や ID の盗難を実行するため、医療産業では引き続きサイバー攻撃がある程度の影響を及ぼしています。また、多くの場合、個人データには患者の病歴が含まれており、標的型のスピアフィッシング攻撃に使用される可能性があります。2017 年 8 月 9 日現在、米国保健福祉省の HIPPA 違反レポート ツールの Web サイト (しばしば "wall of shame" と呼ばれている) では、2009 年以来、合計 2,018 件の違反が確認できます。医療データ漏えいに影響を受けた個人の数は近年急増し、2014 年 5 月 30 日には 3,150 万人だったのが、2017 年 8 月 9 日には 1 億 7500 万人になりました (英語情報)。

これらの傾向と統計から得られる教訓は 3 つあります。まず、医療従事者と患者はできる限り不審なやり取り (詐欺、フィッシング メールなど) および ID 盗難事件に注意し、IT 組織に報告する必要があります。もう 1 つのポイントは、個人の医療および識別情報は、明示的な共有要件 (例えば、健康診断や医療処置を受けるために患者が身分証明書を提示する、など) がない限り開示されるべきではないということです。最後に、データ区分と情報保護ソリューションの使用によって、ライフサイクル全般にわたり秘匿性の高い情報を保護し、暴露の影響を減らせる可能性があります。

例 3: 人的エラーにより金融サービス会社で顧客情報の漏えいが発生

金融サービスおよび銀行業界では、他の業界に比べてインフラストラクチャおよびデータに対して比較的厳しい監視および規制が導入されているにもかかわらず、引き続きデータ漏えいの影響を受けています。2017 年の初めに、金融サービス会社が何千人もの顧客の機密情報を含むデータベースを不注意で一般に公開する事象が発生しました。その会社は、サード パーティ ベンダーの人的エラーによりインシデントが起こったと主張しています。

ここで得られる教えは、組織がそのネットワークとデータにアクセスできるすべての請負業者に対して責任を課すことが重要だということです。例えば、Petya ランサムウェアの流行時にも明るみに出た重要課題ですが、サード パーティの請負業者が組織のサイバーセキュリティ ポリシーに従っておらず、これが危機の根本原因となりました。

サイバー レジリエンス プログラムの検討

企業組織において、コンピューター システム、IT インフラストラクチャ、およびデータ センターが人的エラー、サイバー脅威、およびサイバー攻撃による被害に対抗する能力を強化するために、人、プロセス、およびクラウド サービスの連携を活用するサイバー レジリエンス プログラムを検討することを推奨します。

人:

常勤の従業員、コンサルタント、および請負業者を含む、企業ネットワークへアクセスできる人は全員、サイバー レジリエンスに対する考え方を育てるために定期的に訓練を受ける必要があります。これには、ID ベースのアクセス制御に関連する IT セキュリティ ポリシーの順守だけでなく、復旧までの時間を最短にするために、疑わしいイベントや感染についてできる限り早く IT 部門へ報告することも含まれます。

プロセス:

組織では、サイバー レジリエンスに対する方針を効果的に進めるために、いくつかのプロセスの実装を検討すべきです。IT セキュリティ ポリシーとして実装できるものもあります。下の表で、推奨のプロセスを紹介します。

クラウド サービス:

サイバー レジリエンスを維持するためには、推奨するプロセスが、会社のリスク処理のしきい値と、人による取り組みおよびテクノロジ製品やサービスの連携を通した経営上のプロセスを実行する能力に基づいて、定期的に実行される必要があります。

幸運なことに、クラウド サービスに基づいたアーキテクチャは、オンプレミス インフラストラクチャの迅速な再構築や、ミラー化済みのインフラストラクチャへのフェール オーバーに使用することができます。クラウド サービスを採用する際の重要な検討事項は、プロバイダーがどのように評価を実施しているかを確認すること、また、第三者による監査や認証を参考にプロバイダーの実績を確認することです。

Microsoft Azure および Office 365 のようなクラウド サービスは、少なくともお客様のサイバー レジリエンスのニーズを支援するための第一歩としての役割を果たします。

マイクロソフトとエコシステムとの連携

サイバー レジリエンスは、私たちが単独で対処できる問題ではありません。私たちのコミットメントは、お客様が既に使用しているテクノロジ上で、マイクロソフト製品が正しく動くことを保証することです。マイクロソフトは、業界の水準を共に引き上げるパートナーと一緒に、活力あるエコシステムを促進しています。テクノロジのパートナー ネットワークを通じて、プロアクティブな脆弱性ツールと、アプリケーション ファイアウォールおよび脅威検知などの潤沢な機能を備えたソリューションをお客様に提供することができます。また、特定のお客様のサイバー レジリエンスのニーズや業界規制を満たすために、お客様および業界標準団体と広範囲にわたってコラボレーションしています。マイクロソフトは、オペレーティング システム、そして最近ではクラウド プラットフォームである Azure がサイバー脅威に対して機能強化されていることを実証するために、Center for Internet Security (CIS) と協業しています。現在、Azure が CIS ベンチマークの要件を満たすことを目標にしています。CIS ベンチマークは、政府、業界、および学界で開発され受け入れられている、唯一の合意に基づくベストプラクティスのセキュリティ構成ガイドです。さらに、マイクロソフトのオファリングが SANS Critical Security Controls の推奨事項と合致するよう積極的に取り組んでいます。SANS Critical Security Controls とは、今日のインターネットの世界に存在する最も重要な実際の脅威に備えるために、各組織が利用する基準です。

サマリー

サイバー レジリエンス プログラムを開発し実行することは簡単なことではありません。それは終着点ではなく、道のりです。組織が重点的に取り組み、コミットし、努力する必要があります。このトピックに関する追加の詳細なガイダンスについては、今年の後半に公開される予定のホワイトペーパーにご期待ください。

Ann Johnson, Vice President Enterprise & Cybersecurity

こんにちは、Azure サポート部の石井です。

今回は、Azure の Instance Metadata Service について、実例を交えて紹介します。VM 内部から、自身のメンテナンス時間が把握でき、猶予時間内に適切な処理が行えるというものです。

詳しい内容は以下技術情報をご参考ください:
Windows VM 用の Azure Instance Metadata Service
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/instance-metadata-service

Azure Metadata Service: Windows VM のスケジュールされたイベント (プレビュー)
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/scheduled-events

[機能の紹介]

VM の内部のシステム管理者やアプリケーション開発・運用者から見ると、Azure プラットフォーム側から何らかの操作をされる、ということは、実際にシステムに影響が出るまで分からないものです。それが問題となるケースにおいては、Instance Metadata Service を使うことで事前に対応ができる猶予時間を得られることができます。
Azure VM の内部から、以下のような操作を知ることができるというものになります。

・非通知のメンテナンスとして VM を一時停止 (フリーズ) 状態にして行うもの
・Azure 仮想マシン管理者のポータル・CLI などの操作による再起動や再デプロイ
マイクロソフトが行うメンテナンスのほか、Azure のリソース管理者が行う再起動・再デプロイなど、広義の意味でのメンテナンス作業があるかどうか、VM 内部でプログラム的に知ることができるということがメリットです。

具体例を交え、役に立つシナリオは以下の通りです。

・メンテナンスの有無を記録しておき、VM 内のアプリの不調・切断といった事象の手がかりとする

・シャットダウンに時間がかかる、といった通常のシャットダウンや再起動命令に間に合わないシステムで猶予時間が得られ、あらかじめ停止処理・フェールオーバー処理が開始できる

後者についてより詳しい例を挙げると、「データベースと連動するアプリケーションがあり、シャットダウンに 15 分かかる。」というような場合、Azure からシャットダウンをするとシャットダウンの 15 分が待たれず強制再起動されてしまいます。つまり、アプリケーションが終了中、強制 Kill されてしまうというリスクがあります。
つまり、Azure 管理者は、VM 内部のシステムにログインし、データベースを止めてから Azure VM を停止するという手間をかけるという、パブリック クラウド時代の目標となる自動化とは程遠い運用が必要でした。Instance Metadata Service を使えば、Azure 基盤側から再起動が行われるとき、内部のアプリケーションが事前にシャットダウン処理を実行できるため、管理者がわざわざ VM にログインする手間が省けます。

[使用例と考察]

Instance Metadata Service とは、VM 内部からのみアクセスが出来る特殊な Web サイト http://169.254.169.254/ にアクセスすることで、VM 自身のメンテナンス情報が受け取れるというものです。
メンテナンスが特に無い状態では、空白のコンテンツが返され、メンテナンスがスケジュールされている場合、適切なパラメーターが入った文字列が得られます。パラメーターについての詳細は、冒頭にもあったリンクを参照してください。

メンテナンスは、最長でも 15 分前に知ることが出来る、というものです。何時間前、何日前、といったスパンではない点に注意してください。
あくまでも自動処理を意図したものというデザインになっています。

このことから、ベースとなるのは、以下のようなシンプルな PowerShell Script によるループ処理です。
運用に組み込む場合、OS の Task Scheduler でバックグラウンド実行させることが前提となります。

while($true){
   $message = curl http://169.254.169.254/metadata/scheduledevents?api-version=2017-04-02
   $message | Out-File C:testmetadata.txt -append
   $message.Content | Out-File C:testmetadata.txt -append
   # $message.Content の内容によって何か処理を行う
   Start-Sleep -seconds 10
}

まずは、テキスト ログに出力される内容から、何がおきるのか見てみます。
何もスケジュールされていない時は、このようなアウトプットになります。

//$message の中身。正常に情報が取れたことを示す StatusCode 200 と、日時が記録されています。
StatusCode : 200
StatusDescription : OK
Content : {"DocumentIncarnation":0,"Events":[]}
RawContent : HTTP/1.1 200 OK
x-ms-package-infosource: ProcessRequestFromPAAgent
Content-Length: 37
Content-Type: application/json
Date: Wed, 04 Oct 2017 01:27:00 GMT
ETag: 813064690011386043
Server: Microsof...
Forms : {}
Headers : {[x-ms-package-infosource, ProcessRequestFromPAAgent], [Content-Length, 37], [Content-Type,
application/json], [Date, Wed, 04 Oct 2017 01:27:00 GMT]...}
Images : {}
InputFields : {}
Links : {}
ParsedHtml : System.__ComObject
RawContentLength : 37

// $message.Content の中身は、何もないので空白です

{"DocumentIncarnation":0,"Events":[]}

さて、実際にポータルの Virtual Machines ブレードから [再起動] をクリックしてみます。ここで、Instance Metadata Service をコールしている VM では、15 分後に再起動がスケジュールされます。

以下のように $message.Content の中身 が変わります。

//$message の文字列
StatusCode : 200
StatusDescription : OK
Content : {"DocumentIncarnation":1,"Events":[{"EventId":"C6125276-A766-40DE-AC13-370AC02C8C88","EventStatus":
"Scheduled","EventType":"Reboot","ResourceType":"VirtualMachine","Resources":["_tidv2promo"],"NotBe
fo...
RawContent : HTTP/1.1 200 OK
x-ms-package-infosource: ProcessRequestFromPAAgent
Content-Length: 238
Content-Type: application/json
Date: Wed, 04 Oct 2017 01:30:44 GMT
ETag: 5865132596377058819
Server: Micros...
Forms : {}
Headers : {[x-ms-package-infosource, ProcessRequestFromPAAgent], [Content-Length, 238], [Content-Type,
application/json], [Date, Wed, 04 Oct 2017 01:30:44 GMT]...}
Images : {}
InputFields : {}
Links : {}
ParsedHtml : System.__ComObject
RawContentLength : 238

// $message.Content の内容
{"DocumentIncarnation":1,"Events":[{"EventId":"C6125276-A766-40DE-AC13-370AC02C8C88","EventStatus":"Scheduled","EventType":"Reboot","ResourceType":"VirtualMachine","Resources":["_tidv2promo"],"NotBefore":"Wed, 04 Oct 2017 01:45:39 GMT"}]}

上記 Instance Metadata を取得した時間が 1:30 、再起動の NotBefore は 1:45 とあることから、ドキュメントの記載どおり 15 分の猶予がもたれていることが分かります。
つまり、Instance Metadata Service をコールしている VM には、シャットダウンに猶予時間が生じるということですね。

// 対象の Windows のシステム イベント ログより、実際に NotBefore の時間以降にシャットダウンが行われていることが確認できます

Information 10/4/2017 1:46:03 AM User32 1074 None
The process C:WindowsSystem32svchost.exe (tidv2promo) has initiated the shutdown of computer tidv2promo on behalf of user NT AUTHORITYSYSTEM for the following reason: Other (Planned)
Reason Code: 0x80000000
Shutdown Type: shutdown
Comment:

なお、VM のメニューから、[再デプロイ] ボタンを押した場合の Content は以下のとおりでした。EventType が Redeploy (再デプロイ) であることに注目してください。(長いので Instance Metadata 自体は省略しますが、公開情報どおり再デプロイ= 10 分間の猶予ということも確認できました。)

{"DocumentIncarnation":4,"Events":[{"EventId":"9618CBC9-96E1-4F2C-8A5C-CBB9D1F1C7A0","EventStatus":"Scheduled","EventType":"Redeploy","ResourceType":"VirtualMachine","Resources":["_tidv2promo"],"NotBefore":"Wed, 04 Oct 2017 02:13:09 GMT"}]}

"EventType" が Freeze のものはすぐに検証が出来ませんでしたが、これは Azure で不定期に行われるメモリ保護更新 (あるいはインプレース VM 移行) と呼ばれる処理です。過去の事例ですと、月に 1 度、といった頻度で不定期に行われています。
この処理では、最長で 30 秒ほど一時停止状態になりますが、メモリ情報などは完全に保存されるので、一時的なネットワーク通信エラーやタイムアウトになる程度の影響となります。この動作が何か問題となるケースではログを残しておいたり、意図的にフェールオーバーをさせてしまうといったことも有効かもしれません。
ただし、Freeze を伴うメンテナンスでは多くの場合、TCP/IP の再送、あるいはアプリケーション レイヤーでのリトライ処理で問題にならないケースがほとんどです。Azure サポート チームとしては、特別な理由がない限り、Freeze のイベントについては、イベント ログやテキスト ログに痕跡を残しておき、アプリケーションなどのトラブルの自己分析のために役立てるといった活用法をお勧めします。

ここまでの記載で、Instance Metadata Service でどういった情報が取れるのかや、挙動について把握が出来ました。

PowerShell スクリプトによって、$message.Content の文字列の "EventType" が存在するか否か、という条件によって、何らかのアプリケーションのバッチ処理をキックするといった対応が一般的です。

[補足: 準備が出来た場合に、即時メンテナンス実行を許可する]

上記の例では、再起動を行った場合 15 分、といった猶予時間が得られましたが、Instance Metadata Service では VM 内部から準備が出来次第、「もうメンテナンスしてもいいよ」という許可を出すことも可能です。
許可を出さないと、Azure 管理者が再起動命令をした後、15分ぎりぎりまで再起動がはじまらない、ということになるため、タイムリーな対応にならないということが懸念されます。そのような場合には処理が完了次第、許可を出すようにスクリプトを組むことをお勧めします。

サンプル スクリプトは、冒頭のリンクにて紹介されていますので、手動で行った例を添えておきます。

// Azure Portal から VM の再起動をクリックした状態で、Instance Meatadata を取得します。

$message = curl http://169.254.169.254/metadata/scheduledevents?api-version=2017-04-02

// 上記で得られた Content を出力すると、以下の DocumentIncarnation 番号と、EventID が得られました。
$message.Content
{"DocumentIncarnation":7,"Events":[{"EventId":"053CDB29-A979-4532-958F-42C814B35DDF","EventStatus":"Scheduled","EventType":"Reboot","ResourceType":"VirtualMachine","Resources":["_tidv2promo"],"NotBefore":"Wed, 04 Oct 2017 04:17:42 GMT"}]}

上記に対して、許可のメソッドを発行します。

Invoke-RestMethod -Uri http://169.254.169.254/metadata/scheduledevents?api-version=2017-04-02 -Headers @{"Metadata"="true"} -Method POST -Body '{"DocumentIncarnation":"7", "StartRequests": [{"EventId": "053CDB29-A979-4532-958F-42C814B35DDF"}]}'

本来なら、スケジュールされた 4:17 を待って再起動されるはずですが、上記 Invoke-RestMethod 実行後すぐにシャットダウン処理が行われ、全体的なメンテナンス完了を早めることができました。

近日、Azure 基盤で大々的に、再起動を伴うメンテナンスも計画されています。このため、VM 管理者側からの対応策としてこの機能を使い、アプリケーションやシステムへの影響を極力抑えるといった工夫も行えるかと存じます。

Way back in August, Microsoft announced a new partner program. Nothing new there but this one is kind of special, it is the fastest, easiest way to get you moving into a Software Defined Datacenter.

WSSD

The program is designed to bring many benefits in a timely and cost-effective way

The implementation of a Software Defined Datacenter (SDDC) is not uncomplicated. It is difficult to plan, size and implement without dedicated support from both software and hardware vendors.

Microsoft has joined with its WSSD partners to provide three different WSSD solutions.

Goldfinger war der dritte Bond-Film mit Sean Connery und einem tollen Gerd Fröbe als Bösewicht. Noch immer habe ich den Titelsong von Shirley Bassey im Ohr, der Film zählt für viele zu den besten Bonds. Und ich habe noch den wunderschönen Aston Martin DB5 vor Augen, den 007 in einer rasanten Verfolgungsjagd fährt – mit Maschinengewehr, Nebelwerfer und Schleudersitz.

Es sind nicht zuletzt die Bond-Filme, die den Ruf von Aston Martin als Hersteller der schönsten Sportwagen der Welt gefestigt haben. Dabei ist die Marke selbst zum Zeitpunkt der Veröffentlichung von Goldfinger 1964 schon über 50 Jahre alt.

Heute zählt Aston Martin bereits stolze 104 Jahre. Dennoch versteht Andrew Palmer das Unternehmen als „104 Jahre altes Startup“, wie der CEO von Aston Martin erklärt. Sein Plan für das zweite Jahrhundert hängt maßgeblich davon ab, wie das Unternehmen es schaffen wird, zu expandieren – ohne dabei die handwerkliche Qualität der Autos inklusive aller feinen Details aufzugeben. Denn erst diese machen den eigentlichen Reiz der Marke aus. Microsoft 365 und die Microsoft-Cloud spielen bei dieser Strategie eine wichtige Rolle.

Aston Martin war und ist eine Luxusmarke, und das soll auch in Zukunft so bleiben: Bis in die 90er Jahre des vergangenen Jahrhunderts hat das Unternehmen gerade einmal 16.000 Autos gebaut, und seitdem hat sich an dieser Strategie auch nichts verändert.

Kern des Erfolgsrezepts: Geistiges Eigentum in der Cloud

Um über mehr als ein Jahrhundert konstant hohe Qualität liefern zu können, braucht es mehr als fundiertes Know-how über Automobildesign und -entwicklung, sagt Andrew Palmer: „Unser Ziel ist es, Markttrends zu verstehen und die Bedürfnisse unserer Kunden auf Jahre im Voraus zu antizipieren“. Das ist das eigentliche (Geheim-)Rezept des Unternehmens. Und damit das aufgeht, arbeitet Aston Martin datenbasiert – mit Power BI und Office 365.

Die Microsoft-Werkzeuge für cloudbasierte Kommunikation und produktive Kollaboration hält Palmer für die natürlichen Verbündeten seines Unternehmens: Sie verbinden die leidenschaftlichen Mitarbeiter Aston Martins mit Weltklasse-Tools. Das Unternehmen nutzt Microsoft 365, zu dem neben Office 365 auch Windows 10 sowie Enterprise Mobility + Security gehören – und damit alles, was Unternehmen für kollaboratives und kommunikatives Arbeiten in einer sicheren Umgebung brauchen.

Neben Microsoft 365 setzt Aston Martin auch auf die Microsoft-Cloud für die Sicherung des eigentlichen Firmenkapitals: „Unsere Entscheidung, unser geistiges Eigentum in der Cloud zu speichern, ist auch ein Statement über die dauerhafte, hohe Zuverlässigkeit von Microsoft als Partner“, so Palmer.

Wir freuen uns – darüber und auf die kommenden 100 Jahre mit Aston Martin!

Ein Beitrag von Alain Genevaux
Leiter des Office-Geschäfts bei Microsoft Deutschland

Die (englische) Kundenreferenz zum Einsatz von Microsoft 365 bei Aston Martin findet ihr hier.

We are listening to customers' requests on User Voice. The issues reported on DHCP MP have been rectified and we have released a new version of the MP. You can download the Microsoft System Center Management Pack for Windows Server DHCP 2016 here and DHCP 2012 R2 MP here. The MP has below fixes

• DHCP Failover Server Relationship Discovery was failing as the Scope ID length max limit was 4000. The Scope ID length limit has been increased to 65536.
• Alert description for "DHCP IPv4 Runtime Service Bound to Static IP Address Monitor", "DHCP Dependent Service Health Monitor","DHCP Database Integrity Monitor" have been updated, users can comprehend and troubleshoot the situation better with such information.
• To reduce the alert noise created with multiple alerts of same type, the alert rules "DHCP Back Up Database Warning", "DHCP IPv4 Runtime DNS Registration Rule",  "DHCP IPv4 Runtime Users Group Configuration Rule" and "DHCP Database Integrity Warning Rule" are suppressed so that only the alert count increases and not generate new alerts
• "Collect ALL DHCP Server Performance Data" rule has been fixed to ingest right data in the registry key, thus indicating the correct health state of the entity
• "DHCP Performance Health Monitor" which was always in not-monitored state has been rectified to correctly show the health state of the entity it monitors
• "DHCP Server 2012 R2 Super Scope Addresses Available Percentage Monitor" that was failing to change state on critical alerts, has been fixed to show the appropriate state so the users do not miss out on critical state

こんにちは Windows サポートの林です。

今回は Windows Server 2012 R2 におけるタスクスケジューラの「停止するまでの時間」設定の問題についてご案内致します。

問題概要

タスクスケジューラのタスク設定における "停止するまでの時間" 設定は [トリガー] タブおよび [設定] タブの 2 箇所設定する場所があります。しかし、トリガー設定にて "繰り返し間隔" (繰り返し実行設定) が設定されており、更に [設定] タブのみ "停止するまでの時間" が設定されている場合、この停止時間設定が期待通りに動作せず設定した時間を経過してもタスクが終了されない問題があります。この問題は Windows Server 2012 R2 で発生し、Windows Server 2016 以降では発生致しません。

原因

Windows Server 2012 R2 では UBPM(Unified Background Process Manager) とタスクエンジン(taskeng.exe) の 2 つのタスクスケジュールエンジンがございます(詳しくはこちらを参照)。本問題は誤って本来 UBPM から実行されるべきではないタスクが誤って実行されてしまうために発生します。具体的には繰り返し実行が設定されているタスクにて [設定] タブのみ "停止するまでの時間" 設定がされていると本事象は発生しますが Windows Server 2012 R2 では UBPM は繰り返し実行が設定されているタスクはサポートされておらず、本来は従来のタスクエンジン(taskeng.exe) からタスクが実行される必要がございます。しかし、内部ロジックの問題で誤って UBPM からタスクが実行されてしまい、UBPM は繰り返し実行設定をサポートしていないために設定通りに停止しない問題が発生致します。

対処方法

上記のように本件は [設定] および [トリガー] の 2 箇所の設定のうち、[設定] タブのみ "停止するまでの時間" が設定されている場合に発生します。対処は下記のように [トリガー] タブの "停止するまでの時間" を設定することでタスクエンジンからタスクが起動されるようになり、停止時間設定も期待通り動作するようになります。