Office 365 では 2018/10/31 から TLS 1.2 未満 (TLS 1.0/1.1) が無効化されるため、TLS 1.2 が有効に設定されていない Windows では TLS 1.2 を有効にする必要があります。Outlook クライアントでの TLS 1.2 への対応についてよくある質問を FAQ としてまとめましたのでご確認ください。
なお、具体的な作業は こちらのブログ記事 で紹介しています。

────────────────────────────────────────────────
目次
Q1. TLS 1.2 を利用できるように対策していないと、2018/10/31 から急に Office 365 に接続できなくなってしまうのですか？
Q2. Windows 7 (SP1 未適用) 、8 (8.1 未満)、Windows Server 2008 (R2 未満) では TLS 1.2 に対応できないのですか？
Q3. レジストリ DefaultSecureProtocols  はどのようなレジストリですか？
Q4. レジストリ DefaultSecureProtocols にはどの値を設定すればいいですか？
Q5. レジストリ DefaultSecureProtocols を変更した場合は、どのような影響がありますか？
Q6. レジストリ DefaultSecureProtocols はどこに作成すればいいですか？ 両方作成しても構いませんか？
Q7. HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsWinHttp のキーは「Windows OS 64 ビット/Office 32 ビット」の組み合わせの場合は必要ないのでは？
Q8. SCHANNEL のレジストリを設定すると、どのような影響がありますか？
Q9. 毎月 WSUS を使用して重要な更新を適用している場合は、KB3140245 は既に適用されていますか？
Q10. 毎月 Windows Updateを使用して重要な更新を適用している場合は、KB3140245 は既に適用されていますか？
Q11. KB3140245 のサポート技術情報の [Download] ボタンをクリックしても、KB3140245 が適用されないのですが？
Q12. KB3140245 を含むロールアップはないのですか？
Q13. KB3140245 が適用されているかは、どのように確認すればよいですか？
Q14. レジストリを配布するには、どのような方法で行えばいいですか？
Q15. レジストリ DefaultSecureProtocols は、KB3140245 適用前に作成してもよいですか？ 適用後に作成した方がいいですか？
Q16. Outlook が実際に TLS 1.2 で通信しているかは、どのように確認すればよいですか？
Q17. Internet Explorer の [インターネット オプション]-[詳細設定] で [TLS 1.2 の使用] をオンにする必要はないのですか？
Q18. Outlook 2016 for Mac では対応は必要ですか？
Q19. Outlook for iOS や Outlook for Android では対応は必要ですか？
Q20. Outlook on the Web (OotW/OWA) では対応は必要ですか？
Q21. iOS (iPhone/iPad) や Android の標準のメールでは対応は必要ですか？
Q22. Windows 10 Mobile の Outlook アプリでは対応は必要ですか？
Q23. 参考資料にはどういうものがありますか？
────────────────────────────────────────────────

Q1. TLS 1.2 を利用できるように対策していないと、2018/10/31 から急に Office 365 に接続できなくなってしまうのですか？

2018/10/31 から順次 TLS 1.2 未満の無効化が行われます。10/31 に一斉に接続できなくわけではなく、無効化を行ったサーバーに対して順次接続できなくなります。

Q2. Windows 7 (SP1 未適用) 、8 (8.1 未満)、Windows Server 2008 (R2 未満) では TLS 1.2 に対応できないのですか？

Windows 7 (SP1 未適用) と Windows 8 (8.1 未満) はサポートが終了している製品であり、Windows 7 SP1 またはWindows 8.1 以降への移行が必要です。Windows 7 (SP1 未適用) と Windows 8 (8.1 未満) には WinHTTP で TLS 1.2 を利用する機能を追加する KB3140245  (英語 日本語) を適用できないため、TLS 1.2 に対応することができません。

また、Windows Server 2008 (R2 未満)  は Windows Server 2008 R2 以降への移行が必要です。Windows Server 2008 (R2 未満) には WinHTTP で TLS 1.2 を利用する機能を追加する KB3140245 を適用できないため、WinHTTP で TLS 1.2 に対応することができません。
(KB4019276 (英語 日本語) は SCHANNEL が TLS 1.2 に対応するための更新プログラムであり、WinHTTP では TLS 1.2 に対応しません)

Q3. レジストリ DefaultSecureProtocols  はどのようなレジストリですか？

WinHTTP の通信が既定で利用できる TLS/SSL のバージョンを、以下の値の論理和で設定しておくためのレジストリです。

SSL 3.0 = 0x00000020
TLS 1.0 = 0x00000080
TLS 1.1 = 0x00000200
TLS 1.2 = 0x00000800

既定では作成されておらず、作成されていない場合は既定値の以下が利用されます。

Windows 7 SP1/8: SSL 3.0/TLS 1.0
Windows 8.1/10: SSL 3.0/TLS 1.0/1.1/1.2

Q4. レジストリ DefaultSecureProtocols にはどの値を設定すればいいですか？

マイクロソフトでは、セキュリティを考慮し以下の値を推奨しています。

0x00000a00 (TLS 1.1+1.2)

WinHTTP を使用して TLS 1.0 へ接続している可能性があり互換性を重視する場合は以下の値を設定します。

0x00000a80 (TLS 1.0+1.1+1.2)

ただし、SSL 3.0 については POODLE の脆弱性 も確認されていることから無効化することを強く推奨します。

Q5. レジストリ DefaultSecureProtocols を変更した場合は、どのような影響がありますか？

クライアントの DefaultSecureProtocols に設定されているTLS のバージョンと WinHTTP で接続したサーバーが利用できる TLS のバージョンを使用してネゴシエーションを行い、共通で利用できるもっとも高いバージョンが使用される動作になっています。
Windows 7 では既定では DefaultSecureProtocols として SSL 3.0+TLS 1.0 が使用されています。DefaultSecureProtocols に 0x00000a00 (TLS 1.1+1.2) を設定した場合は WinHTTP を使用して SSL 3.0 や TLS 1.0 を使用して接続する必要がある場合は接続ができなくなります。

たとえば、Windows 7  SP1 でまだ DefaultSecureProtocols を設定していない場合は、SSL 3.0+TLS 1.0 として扱われるため以下の動作となります。

・Exchange Online     : 現在は TLS 1.0 を使用して接続 (Office 365 で TLS 1.2 未満が無効化されると接続できなくなる)
・WinHTTP を使用して TLS 1.2 で接続する必要があるサーバー : 接続が失敗
・WinHTTP を使用して TLS 1.1 で接続する必要があるサーバー : 接続が失敗
・WinHTTP を使用して TLS 1.0 で接続する必要があるサーバー : TLS 1.0 を使用して接続

この環境に、KB3140245 を適用し DefaultSecureProtocols に 0x00000a00 (TLS 1.1+1.2) を設定した場合は以下の動作となり、TLS 1.0では接続することができなくなります。

・Exchange Online     : TLS 1.2 を使用して接続
・WinHTTP を使用して TLS 1.2 で接続する必要があるサーバー : TLS 1.2 を使用して接続
・WinHTTP を使用して TLS 1.1 で接続する必要があるサーバー : TLS 1.1 を使用して接続
・WinHTTP を使用して TLS 1.0 で接続する必要があるサーバー : 接続が失敗

WinHTTP を使用して TLS 1.0 で接続する必要がある場合や接続する可能性があることが懸念される場合は、0x00000a80 (TLS 1.0+1.1+1.2) を設定してください。
その場合は以下の動作となり、TLS 1.0でも接続することができます。

・Exchange Online    : TLS 1.2 を使用して接続
・WinHTTP を使用して TLS 1.2 で接続する必要があるサーバー : TLS 1.2 を使用して接続
・WinHTTP を使用して TLS 1.1 で接続する必要があるサーバー : TLS 1.1 を使用して接続
・WinHTTP を使用して TLS 1.0 で接続する必要があるサーバー : TLS 1.0 を使用して接続

Q6. レジストリ DefaultSecureProtocols はどこに作成すればいいですか？ 両方作成しても構いませんか？

以下の場所に作成してください。
実際の環境に必要なキーからのみレジストリが読み込まれる動作となっておりWindows OS 32 ビットに両方のキーを作成しても問題ないため、Windows 64 ビットと 32 ビットが混在している場合は両方のキーを配布してください。

Windows OS 32 ビット:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsWinHttp

Windows OS 64 ビット:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsWinHttp (64 ビット アプリ/64 ビット サービス用)
HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionInternet SettingsWinHttp (32 ビット アプリ/32 ビット サービス用)

Q7. HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsWinHttp のキーは「Windows OS 64 ビット/Office 32 ビット」の組み合わせの場合は必要ないのでは？

Office 32 ビット自体は必要ありませんが、キャッシュモードの Outlook はオフライン アドレス帳のダウンロードを BITS という 64 ビットのサービスを使用して行っており、BITS も WinHTTP を使用するため設定が必要です。
BITS は Windows Updateにも使用されるサービスです。

Q8. SCHANNEL のレジストリを設定すると、どのような影響がありますか？

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Client に以下のレジストリを作成した場合の意味は以下の通りです。

Enabled : 1 = 有効、0=無効 (該当の TLS のバージョンをクライアントとして有効にするかを指定する)
DisabledByDefault: 1=ネゴシエーションに使用する、0=ネゴシエーションに使用しない (アプリケーションが TLS のバージョンを明示的に指定せずに通信を開始した時に、該当のバージョンをクライアントとして通信を開始する際のネゴシエーションに使用するかを指定する)

Windows 7 SP1/2008/2008 R2 では、既定で DisabledByDefault は作成されていませんが  1 として扱われます。0 に変更した場合は、アプリケーションが TLS のバージョンを明示的に指定せずに通信を開始した時に、TLS 1.2 をネゴシエーションに使用する動作になります。
Enabled はどのバージョンの OS でも 1 であるため、1 を指定しても影響はありません。

Q9. 毎月 WSUS を使用して重要な更新を適用している場合は、KB3140245 は既に適用されていますか？

KB3140245 は WSUS の [分類] の [更新] に含まれる更新プログラムであるため、[分類] の [重要な更新] を配信対象にしていても [更新] を配信対象にしていない場合は、配信されません。
Microsoft Update カタログの活用法について の [A. 特定の更新プログラムのみ WSUS へインポートしたい] の手順に従って KB3140245 をインポートし、配信する必要があります。

Q10. 毎月 Windows Updateを使用して重要な更新を適用している場合は、KB3140245 は既に適用されていますか？

KB3140245 は [推奨される更新プログラム] であるため、Windows Update で重要な更新プログラムを自動インストールするように設定し [推奨される更新プログラムについても重要な更新プログラムと同様に通知する] がオンになっている場合は適用されています。
[推奨される更新プログラムについても重要な更新プログラムと同様に通知する] がオフになっている場合は適用されていないため、適用する必要があります。

↓[コントロール パネル]-[システムとセキュリティ]-[Windows Update]-[設定の変更]

Q11. KB3140245 のサポート技術情報の [Download] ボタンをクリックしても、KB3140245 が適用されないのですが？

KB3140245 (日本語  英語) の [Download] ボタンは、レジストリを作成するための Easy Fix というツールをダウンロードするためのボタンです。実行するとレジストリが作成されますが、KB3140245 の適用は行われません。

KB3140245 の適用は、以下のいずれかの方法で行ってください。
・Windows Update  から適用
・Microsoft Update カタログ からダウンロード

Q12. KB3140245 を含むロールアップはないのですか？

KB3140245 には以下のファイルが含まれています。
以下のファイルより新しいファイルを2 つとも含む更新プログラムは、2018/2/14 時点ではありません。

Webio.dll (6.1.7601.23375)
Winhttp.dll (6.1.7601.23375)

Q13. KB3140245 が適用されているかは、どのように確認すればよいですか？

以下のファイル バージョンを確認し、両方または片方のファイルが 6.1.7601.23375 よりも古い場合は KB3140245 が適用されていないため、適用してください。

C:WindowsSystem32Webio.dll (6.1.7601.23375)
C:WindowsSystem32Winhttp.dll (6.1.7601.23375)

参考:
[重要な更新] だけ適用し [推奨される更新プログラム] は適用されていない環境では Webio.dll は古いままであるため、KB3140245 を適用する必要があります。

Q14. レジストリを配布するには、どのような方法で行えばいいですか？

たとえば、Microsoft System Center Configuration Management (SCCM) のようなレジストリを配布する製品をお持ちの場合をお持ちの場合は、その製品を使用して配布してください。
レジストリを配信するツールを持っていない場合は、以下の手順に従ってグループ ポリシーの [基本設定] の機能を使用してレジストリを配布することができます。

例:
1. グループ ポリシー管理エディターを起動します。
2. [コンピューターの構成]-[基本設定]-[Windows の設定]-[レジストリ] を選択します。
3. 同コンソールの [操作(A)] - [新規作成(N)] - [レジストリ項目] メニューを実行します。
4. [新しいレジストリのプロパティ] ダイアログの [全般] タブにおいて、各項目の値を以下の様に選択、あるいは入力して [OK] をクリックします。

アクション: 更新
ハイブ: HKEY_LOCAL_MACHINE (既定のまま)
キーのパス: SOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsWinHttp
値の名前: DefaultSecureProtocols
値の種類: REG_DWORD
値: 0x00000a00 (10 進数 : 2560)

5. 同様に、以下の項目も必要に応じて作成します。

アクション: 更新
ハイブ: HKEY_LOCAL_MACHINE (既定のまま)
キーのパス: SOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionInternet SettingsWinHttp
値の名前: DefaultSecureProtocols
値の種類: REG_DWORD
値: 0x00000a00 (10 進数 : 2560)

設定後にクライアント側でグループ ポリシーを即時反映させたい場合はコマンド プロンプトから gpupdate /force を実行ください。

(参考: アクションの説明)
作成 : 新しいレジストリ値、キーを作成します。
置換 : レジストリ値、またはキーを削除して再作成します。
更新 : レジストリ値、またはキーを変更し、レジストリ値、またはキーが存在しない場合には新しく作成します。
削除 : レジストリ値、およびキーとそれらのサブフォルダーをすべて削除します。

Q15. レジストリ DefaultSecureProtocols は、KB3140245 適用前に作成してもよいですか？ 適用後に作成した方がいいですか？

レジストリ DefaultSecureProtocols の作成と KB3140245 の適用は、どちらが先でも構いません。
レジストリ DefaultSecureProtocols に TLS 1.2 を含む値が設定され、かつ KB3140245 が適用されていると、TLS 1.2 を含む値が正しく機能します。

Q16. Outlook が実際に TLS 1.2 で通信しているかは、どのように確認すればよいですか？

管理者が管理センターなどから一括で確認する方法はなく、クライアントで単純にコマンドなどで確認する方法はないため、Outlook が実際に TLS 1.2 を使用した通信を行っているか確認する方法  の記事の手順に従ってネットワーク キャプチャを採取して確認する必要があります。

Q17. Internet Explorer の [インターネット オプション]-[詳細設定] で [TLS 1.2 の使用] をオンにする必要はないのですか？

Internet Explorer の [インターネット オプション]-[詳細設定] にある [TLS 1.2 の使用] は WinINet と呼ばれる通信に対する設定です。
Outlook は Office 共通の動作、先進認証、SharePoint への接続、RSSフィードの購読などに WinINet を利用しているためこの設定も必要です。
ただし、Internet Explorer 11 の既定ではWinINet で TLS 1.0+1.1+1.2 を利用するように設定されており [インターネット オプション]-[詳細設定] タブにある [TLS 1.2 の使用] がオンであるため、意図的に変更していない場合は作業は必要ありません。

Q18. Outlook 2016 for Mac では対応は必要ですか？

Outlook 2016 for Macは TLS 1.2 で通信するため、対応は必要ありません。

Q19. Outlook for iOS や Outlook for Android では対応は必要ですか？

Outlook for iOS や Outlook for Android は Outlook クラウド サービスに接続し Exchange Online に接続しています。
Outlook クラウド サービスは今回 TLS 1.2 未満無効化を行わないため、対応は必要ありません。

Q20. Outlook on the Web (OotW/OWA) では対応は必要ですか？

Internet Explorer 11 の既定では、WinINet で TLS 1.0+1.1+1.2 を利用するように設定されています。
既定で [インターネット オプション]-[詳細設定] タブにある [TLS 1.2 の使用] がオンであり、WinINet の通信の際に TLS 1.2 を利用できるため、対応は必要ありません。

Q21. iOS (iPhone/iPad) や Android の標準のメールでは対応は必要ですか？

OS のバージョンやメール アプリが使用する API によって異なるため、各製造元までご相談ください。

Q22. Windows 10 Mobile の Outlook アプリでは対応は必要ですか？

Windows 10 Mobile では Windows 10 と同じ実装であり、Windows 10 と同様に既に既定値で TLS 1.2 が利用できるため、対応は必要ありません。

Q23. 参考資料にはどういうものがありますか？

Outlook 2016/2013/2010 から Exchange Online に接続する際に TLS 1.2 が利用されるようにする方法 (Windows 7 では作業が必要)
Outlook が実際に TLS 1.2 を使用した通信を行っているか確認する方法
[IT 管理者向け] TLS 1.2 への移行を推奨しています
Preparing for the mandatory use of TLS 1.2 in Office 365 (KB4057306)
Office 365 の TLS 1.0/1.1 無効化に伴う AD FS / WAP (AD FS Proxy) の対応

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

Hi All

I just picked a Brydge keyboard for Surface Pro. I use it with my Surface Pro 4 mainly as I often use the tablet to work on my lap on the couch. For that sort of scenario it really enhances the Surface Pro usability. It is a Bluetooth keyboard that is supposed to have 3 months battery life. My initial experience is that the usability is phenomenal despite being connected over Bluetooth. I am typing this blog with the keyboard.

The device is a fair bit heavier then the typical type cover so that is a factor for those looking at a light device. For me weight isn't a factor, but usability is the key driver. I find the key press depth is great and feels like a really solid keyboard. It is also pretty good for typing in a meeting, as key presses as quite quiet. I am also finding the mouse pad quite nice as well. The other thing I have liked is the gesture support in the track pad, there are about 6 gestures you can use.

The main advantage is of course the hinge and lappability. The device slides into a hinge that is pretty robust and has a 160 degree turn capability. You can even squiz the hands holding the Surface if you want a tighter grab on the device. It's basically held with pressure from the device clips that have a rubber inner and basically grips the surface screen. I am finding the contact point does the job really well. It also looks really smart, in fact most people double take when they look at the device not realising it is a Surface but looks like a kewl HP or Mac book .

If you want to know more check out the brydge links below:

• Device info - https://www.brydgekeyboards.com/products/brydge-12-3-microsoft-surface-pro-keyboard
• Usage info - https://www.brydgekeyboards.com/pages/product-instruction-manuals

Happy Skype'ing Team'ing

Steve

本記事は、Microsoft Secure ブログ “Overview of rapid cyberattacks” (2018 年 1 月 23 日 米国時間公開) を翻訳したものです。

Petya や WannaCrypt などの急速に広がるサイバー攻撃 – ラピッド サイバー攻撃 - によって、私たちが持っていたサイバー攻撃のスピード感とダメージ範囲に関する予想は塗り替えられました。マイクロソフト エンタープライズ サイバーセキュリティ グループの Detection and Response Team は、お客様がこのような種類の攻撃に対応し回復できるよう、幅広く活動しました。2017 年、ラピッド サイバー攻撃によって、私たちが支援したグローバル エンタープライズのお客様では、たったの 1 時間でほとんどもしくはすべての IT システムが停止していました。結果として、複数のお客様において 2 億～ 3 億米国ドルの被害が発生しました。[1]

攻撃者は既存の手法を組み合わせて、次の特徴を持つ新しい形式の攻撃を行いました。

• 急速な攻撃 – 1 時間程度で企業全体へ感染が広がった
• 妨害的な攻撃 - グローバル エンタープライズで大規模な業務の中断を引き起こした

急速に広がる「ラピッド サイバー攻撃」とは

ラピッド サイバー攻撃の特徴は、急速な感染拡大、自動化、そして妨害的であることです。この特徴によって、セキュリティ プログラムが一般的に遭遇する標的型データ盗難攻撃や、コモディティ化したランサムウェアを含むさまざまな常用化した攻撃と区別されます。

図 1: ラピッド サイバー攻撃の特徴

• 急速に広がり、かつ自動化されている - 何十年も前のワーム (Nimda や SQL Slammer) のように自己増殖が完全に自動化されているため、いったんマルウェアが起動されると攻撃は急激に広がります。
• 妨害的 – ラピッド サイバー攻撃は、データを暗号化しシステムを再起動することで、業務と IT 運用を妨害するよう設計されています。

ラピッド サイバー攻撃の技術的な影響とビジネス への影響について

技術的な観点から見ると、ラピッド サイバー攻撃は、サイバー攻撃によって引き起こされるテクニカル リスクおよび発生するビジネス リスクの中でも最悪な事例とほぼ同等であると言えます。サイバーセキュリティの世界にいると、「最悪のシナリオ」を説明する営業プレゼンテーション戦術にも慣れ、飽き飽きしてくるものですが、これらの攻撃はまぎれもなく組織に大きなビジネス インパクトを与える現実世界での事例を代表するものです。

Petya の被害者の多くは、わずか 1 時間ほどでほとんどもしくはすべてのコンピューターが停止させられました (ある例では、1 つのグローバル ネットワークで最大 62,000 台のサーバーとワークステーションが停止)。マイクロソフトのインシデント対応チームが関与したお客様環境では、IT チームがシステムを回復させている間に多くの重要な事業運用が完全に停止していました。

ビジネスの視点から見ると、2 億から 3 億米国ドルの損失が生じたために、株主に報告した業績を修正しなければならない企業が複数ありました。実際のビジネス インパクトのレベルは、業界、企業規模、既存のリスク管理コントロールなどの要因により異なります。しかしながら、ラピッド サイバー攻撃による金銭的および資源的なインパクトが甚大であることは明らかです。

ラピッド サイバー攻撃は、他の攻撃とどう違うのか

Petya は標準的な攻撃とは異なっていたため、多くの防御者を驚かせました。以下の 4 つが異なる点です。

図 2: Petya が他の攻撃と異なる点

1. サプライ チェーン - Petya による攻撃で特に目立って異なる要素の 1 つとして挙げられるのは、標的の環境に侵入するために、多くの攻撃において脅威アクターが非常によく利用するフィッシングやブラウジングではなく、サプライ チェーン攻撃を使用したことです。サプライ チェーン攻撃は、特に MEDoc アプリケーションのような IT サプライ チェーンのコンポーネントで増加傾向にありますが、通常のフィッシングやブラウジングの攻撃手法に比べると攻撃量としては少ないです。
2. マルチテクニック - 自己増殖機能を自動化したマルウェア、または複数の増殖テクニックを使用したマルウェアは Petya が最初ではありませんが、影響の大きいソフトウェア脆弱性を悪用し、なりすましのテクニックを使用するという、非常に効果的な組み合わせの実装がされていました。
3. 速さ - Petya の増殖スピードは無視できるものではありません。ウイルス対策ソフトウェアのシグネチャが利用可能になる前に、防御者が反応する時間 (検出 ＋ 手動で対応、または、検出 ＋ 自動応答ルールの作成) はごくわずかだったため、NIST サイバーセキュリティ フレームワーク (英語情報) および復旧プロセスの防御機能に分類される予防的なコントロールに依存するしかありませんでした。
4. 破壊的 - Petya はシステムを再起動させ、ファイルシステムのマスター ファイル テーブル (MFT) を暗号化しました。これによって個別のマシンの復旧がさらに難しくなり、さらには、再起動後にアクセスできなくなったストレージ自体は暗号化されなかったため、多くの企業にいっそう悪い影響を与えました (例えば、Petya のブート コードには SAN ドライバーが含まれていなかったため、当該ストレージには接続できませんでした)。

追加情報

ラピッド サイバー攻撃の詳細と対策については、オンデマンド ウェビナーを参照してください。 Protect Against Rapid Cyberattacks (Petya [aka NotPetya], WannaCrypt, and similar)

Petya の仕組みと主要なポイントを説明する次のブログ投稿 (3 回シリーズ) にご期待ください。

[1] https://www.enterprisemobilityexchange.com/news/notpetya-cyber-attack-costs-maersk-at-least-200m

Microsoft Dynamics 365 for Marketing is designed to help you nurture more sales-ready leads, align sales and marketing and make smarter decisions. Most importantly, Dynamics 365 for Marketing works together with Dynamics 365 for Sales on the same platform which aligns teams with common data, connected processes and Office 365 collaboration tools.

This blog post is a continuation of three previous blog posts on Dynamics 365 for Marketing

1. How to Create a Dynamics 365 for Marketing Trial - link
2. Try Dynamics 365 for Marketing - link
3. How to Create Landing Pages in the new Dynamics 365 for Marketing - link

Example

If you been following along in the above mentioned blog posts, you've already created a simple customer journey, which simply sends an email message to all contacts in a segment.

Now we'll go a bit deeper into customer journeys to see how to add interactive features and decision points by including multiple emails, landing pages, and triggers in the design.

• The journey starts with an email and a trigger, and then branches after the trigger.
• The initial email is will invite recipients to pick up a free download from your website
• The top branch handles the ‘positive’ outcome that the recipients responds to the invitation – goes to a marketing page and requests a download link. In that case we will send them a download link message
• The bottom branch handles the ’negative’ outcome (no response for a few days). In that case we will send a A follow-up message
• The followup message will be sent if a contact does not submit the form after a few days

First email - invite recipients to pick up a free download from your website

1. 1. 1. Go to Marketing Execution and then click Marketing Emails to create a new email message (refer to this blog post for more: "Try Dynamics 365 for Marketing" - link)
         x
      2. In this example we will start with a non-blank email template, eg. the “falcone” template
         This template not only have sample content, graphics, and column layouts, but also include all mandatory elements such as the subscription center link (1) and physical address (2) so you dont have to add those manually
         
         This (first message of your journey) message will invite recipients to pick up a free download from your website. To get the free download, they'll need to visit the landing page, submit a form, and then wait for a follow-up email that contains the download link
         x
         
      3. Fill in required and optional information
         1. Type a Name for the email
         2. Type a Subject for the email
         3. Add a dynamics placeholder for the contacts first name (optional)
         4. Add a body text with instructions to download (optional)

      4. With your new email message still open, drag a Marketing Page block from the Toolbox onto the design canvas
         
         When you drop the Marketing Page block in place, it's automatically selected and the Properties tab opens to show its settings
         
         x
         
      5. In the Properties tab set the Marketing Page field to the name of a landing page (perhaps the one you already made if you followed along in this blog post: How to Create Landing Pages in the new Dynamics 365 for Marketing - link)
         
         You now have a button with a text saying Click Here (if clicked the recipient is taken to the marketing page)
         
      6. Style and format the button
         1. Edit and style the button text by working directly on the canvas and using the floating toolbar, just as you would with a Text block. You might enter text such as “Click here to register for your download”
         2. Working on the Properties tab in the Styles and Size sections, choose a background color, text color, height, and width for the button

      7. Click Save to save your message, click Check for Errors, fix any issues, and then click Go Live to publish the message and make it available for customer journeys

Email with download link and email with follow up message

Create two more marketing emails

1. A download link message
   This message will be sent after a contact submits the form on the landing page
   1. Let the subject be "Thank you for signing up, here's your download link!" but don't worry too much about the content for now
      In a real project, you would include a link to the promised download here
      
      
   2. Save, Check for Errors, and Go Live
      x
      
2. A follow-up message
   This message will be sent if a contact does not submit the form after a few days
   1. Let the subject be "Don't miss out!", but don't worry too much about the content for now.
      In a real project, you probably would repeat most of the original offer here
      
      
   2. Save, Check for Errors, and Go Live

You now have the thee mails needed for the customer journey in place. Next up is to create the journey

Create customer journey

You can refer to this blog post for more details: "Try Dynamics 365 for Marketing" - link

1. Go to Marketing Execution, click Customer Journeys and then create a new (blank) customer journey
   
2. Place a Segment Group tile in the first position, and configure its child Segment tile to reference a segment
   
3. Add an Email tile right after the Segment Group, and configure it to reference the first email message you made above (with message with the landing page button)
   

Add a landing page

Although your email message includes a link to a landing page, the journey is not aware of that link, nor even of the landing page itself.

This journey should react to landing page submissions, so you need to reference the page and link it to the message by adding a marketing-page tile as a child to the email tile.

1. Drag a Marketing Page tile from the Toolbox, and drop it directly onto the Marketing Email Message tile
   
2. To see the child tile for the Marketing Page you just added, expand the Marketing Email Message tile
   
3. Select the Marketing Page child tile, open the Properties tab, and set the following
   1. 1. Name: Type a value that you recognize later (such as “Free download registration page”)
      2. Marketing Page: Set to the name of the landing page you made above

Add a trigger tile

Trigger tiles add interactivity to the journey by splitting the flow and establishing logical criteria for deciding which path each contact will take. As mentioned earlier we will send contacts down one of two paths, depending on their actions

1. Drag a Trigger tile from the Toolbox to the space immediately to the right of the Marketing Email Message tile
   
2. Select the new Trigger tile on the canvas, and then open the Properties tab
   1. Name: Type a value that you will recognize later (such as “Download Link Clicked”)
   2. Timeout: Set a duration to establish how long contacts will wait on this tile before being sent down the false (bottom) path if they don't submit the registration form.
      
3. With the Trigger tile still selected and the Properties tab still open, select +New next to the Set Rules heading
   
   A new rule, called Rule 1, is added for the trigger
   
4. Make the following settings for Rule 1:
   1. Source: Choose the name of the Marketing Page tile you added to the Marketing Email Message tile (eg “Free download registration page”).
      Note that this references the name of the tile, not the name of the marketing page itself (which by the way was “Spring Sale Sign Up Cadiz” – but thats not important for this exercise)
   2. Condition: Set to User registered
      This expression evaluates to true as soon as a contact submits valid information by using the referenced landing page. Each contact will wait at this trigger tile either until its logic evaluates to true or until the timeout period has elapsed, whichever comes first. As soon as a contact fulfills the requirements, it's sent down the true (top) path; if the timeout expires first, the contact is sent down the false (bottom) path instead.
      
      

Add two more marketing email tiles

1. Add two more Marketing Email Message tiles after the trigger, one on the top path and one on the bottom path
   
2. Configure them as follows:
   1. Top tile: This message is sent to contacts who submit the form (when the trigger evaluates to true). Configure it to send the download link message that you created earlier in this procedure.
   2. Bottom tile: This message is sent to contacts who haven't submitted the form within three days of receiving the initial offer. Configure it to send the follow-up reminder message that you created earlier in this procedure.
      

Test the customer journey

1. Save the journey
2. Go to the General tab to give the journey a name and schedule (note: if you want the journey to kick off immediately make sure to set Start date and time to today)
   
   
3. Check for Errors and Go Live

After the journey starts open the mailbox of one of the recipients and open the mail received

Then click the download button in the mail to navigate to the download page, fill out the form and click Subscribe to complete the “registration” (the simulated sign up for a download)

Verify in the inbox of the recipient that the second mail (the “Download Link” mail) is received

On the Insights form of the Customer Journey notice the statistics for the Trigger tile (one contacts sent down the top/yes branch so far)

You can also navigate to the first email of the the flow, and - on the Insights tab - get lots of information about that mail (unique opens, unique clicks etc)

Close

I hope you got a feeling for the power in Customer Journeys by now, how you can use Dynamics 365 to visualize and automate the journey that customers will take while interacting with your marketing initiatives on their way to making a purchase - and I wish you lots of good times with Dynamics 365 for Marketing

 
See Also

• How to Create a Dynamics 365 for Marketing Trial - link
• Try Dynamics 365 for Marketing - link
• How to Create Landing Pages in the new Dynamics 365 for Marketing - link
• Dynamics 365 for Marketing Help and Training - link

Starting spring 2018, Office 365 Partner Admin Center (PAC) tool functionality is moving to the Microsoft Partner Center. You will be presented with a popup dialog box when available for the transfer to Partner Center.

On transition day, each partner that attempts to access PAC will be automatically redirected and logged in to the Partner Center Dashboard. When the automatic redirection happens, Partners will no longer be able to access Partner Admin Center.  Note to Advisors: currently, you can’t send Paid and Trial Quotes to customers through Partner Center.

You can continue to use the Build your Business functionality in PAC until the Paid and Trial Quotes function is enabled in Partner Center.

Moving from Partner Admin Center (PAC) to Partner Center

Office 365 Partner Admin Center (PAC) is moving to the Microsoft Partner Center portal.

We are evolving Microsoft Partner Center into the single place where you will manage your partnership with Microsoft and with your customers. In Partner Center you can manage membership, customer referrals, incentives, and all other aspects of the Cloud Solution Provider (CSP) Program. We will retire the PAC starting March 2018.

The Office 365 Partner Admin Center (PAC) will be retired

During the months of March and April 2018, PAC will be retiring, and partners will start being automatically redirected to Microsoft Partner Center. The redirection will happen in stages, and once you are redirected to Partner Center, you will not be able to work in PAC.

Cloud Solutions Provider partners If you are a CSP partner, we will automatically redirect you to Partner Center starting March 2018.

Advisor partners If you are an Advisor partner, we will automatically redirect you to Partner Center during April 2018.

Note to Advisors: Currently, you can’t send Paid and Trial Quotes to customers through Partner Center. You can continue to use the Build your Business functionality in the Office 365 Partner Admin Center until the Paid and Trial Quotes function is enabled in Partner Center.

Start using the Microsoft Partner Center now!

Start using Microsoft Partner Center now to get ready for the move from PAC. You’ll use the same credentials for Partner Center that you use for PAC. All the features and functions you are used to in PAC are available today in Partner Center (see above Note to Advisors). See the Side-by-side comparison to familiarize yourself with the new look and feel of the features in Partner Center. You will find additional information on account management, customer management, licenses and subscriptions, pricing and offers, and more in Microsoft Partner Center Help.

Partner Center: Moving from Partner Admin Center (PAC) to Partner Center

You know the feeling you get when you find a customer or partner you know you can do great things with? We do. We've got it right now. 90% of Fortune 500 companies trust the Microsoft cloud. That's a lot of really great relationships.

But we think we've found our perfect match. Citrix has nearly 30 years' experience delivering virtual desktops and apps to enterprises. And like any great team, together, we can do more. And we're excited to get started. So we wanted to share half a dozen ways the Microsoft Azure and Citrix Cloud partnership can help your business - and your customers.

1. Grow your business

Public cloud services are on the up. In fact, from 2016 to 2020, it's predicted that the market will grow by 83% . You can compete in this market with a wider range of exciting services and solutions. Our new partnership can help.

2. Make the most of Microsoft Azure

The number one reason customers trial Microsoft Azure is to get Citrix Cloud up and running. Azure is built for Citrix Cloud - and plenty of other services and solutions, so you can make sure your offering is the best it can be.

3. Free up your customers

Privacy is built in to Azure, which is why so many desktops and apps are being moved there. But with XenApp Essentials from Citrix Cloud, your customers can get to their Windows apps from Azure on any device. Then, they're free to work however, and wherever, they like.

4. Make a difference to desktops

XenApp Essentials is the first Citrix Cloud service made just for the Azure Marketplace. With it, you can deploy Windows 10 for your customers. Then they've got a high-performance desktop they can get to securely from any device.

5. Make hybrid IT happen

Loads of companies have got a hybrid IT strategy. But plenty don't know where to start with putting it into action. With your support, and the advice of two industry experts in partnership together, they'll have an easier time moving services to the cloud, and managing their complex hybrid IT.

6. Look out for extra profits

With a good solid foundation from our partnership, you're free to add new services to your offering. We'll take care of the technical side of things, and you can make sure you're delivering great service to your customers.

With all the benefits of our partnership, you can find your perfect match, too. Move customers to the cloud faster, and with less risk. Build flexible IT and tweak solutions and apps as they need them. And sell extra value-added services around your main portfolio. Become your customers' perfect match with Citrix Cloud and Microsoft Azure

On the second day of Tech Summit Birmingham, Scott Guthrie took to the stage to host the Azure Red Shirt Dev Tour. For those of you that haven't attended one before, these are detailed yet past-paced demonstrations and tutorials on a wide array of Azure features. They typically run for about 5 hours, 6 if you're counting breaks and lunch, allowing plenty of time for devs to see what Azure has to offer.

While the Birmingham event has passed, you can still learn more about the cloud with the tour's detailed resources on various Azure-related topics. Whether you want to learn more about Virtual Machines or the Azure App Service, Azure Cosmos DB or Docker, there's something here for everyone.

Each topic is broken down into segments, which range from detailed step-by-step tutorials to free Pluralsight video training. Whether you missed the event on the day or just want a refresher, be sure to browse the full list of resources.

If you'd prefer to hear from Scott himself, you can watch recordings of last year's New York City event! These are all available for free on Channel 9, and we've included the first of the three videos down below. In the meantime, keep an eye on our events listing, as well as our @MSDevUK Twitter account for news about future tours!

Last year at Ignite we introduced the newest member of the family, Azure Advanced Threat Protection. Azure ATP brings the power of Microsoft Advanced Threat Analytics to the cloud, but not way more robust, and easier to deploy. Today we are pleased to announce that you can register to Azure ATP Public Preview by following the instructions from this page. Also, make sure to watch the presentation below to get more familiar with Azure ATP:

We've released a new version of the Surface Dock Updater, v2.12.136.0, available now from the Surface Tools for IT page at the Microsoft Download Center. This new update includes fixes for external display stability issues when Surface Dock is used with Surface Book devices and includes firmware updates for both the Surface Dock main chipset and DisplayPort.

Note: The updates provided by Surface Dock Updater v2.12.136.0 apply to Surface Dock only when used with Surface Book or Surface Book 2 and do not apply to scenarios where Surface Dock is used with other Surface devices. Surface Dock Updater firmware updates are cumulative. Updating a Surface Dock that has not yet been updated with v2.9.136.0 will provide the improvements of the earlier release in addition to those in v2.12.136.0.

In addition to the firmware updates for Surface Dock, installation of the Surface Dock Updater utility on a Surface Book will also install a firmware update for the Surface Book base of that device. This Surface Base Firmware Update, v4.0.7.0, is required to enable the display stability fixes for a connected Surface Dock. Both the Surface Dock and the Surface Book base must be updated to implement these fixes.

Note: Surface Book 2 devices do not require a Surface Base Firmware Update and only require the Surface Dock update for implementation of these fixes.

Recently we decided to change the central admin URL to use SSL and a host header. There are several articles out there on the steps required to do this successfully. We followed the steps and were quickly up and running. If you have already created some service applications and have been using them you may run into issues with the URL change.

USER Profile Service Application

About two weeks after the URL change, we found out that the User Profile service was not working properly. When we loaded the MIISCLIENT.EXE (typically located at 'C:Program FilesMicrosoft Office Servers14.0Synchronization ServiceUIShell' ) we saw the miisclient console shows 'stopped-extension-dll-exception' error. Basically the MIISCLIENT was pointing to the old Central Admin URL. To verify this

• Open MIISCLIENT.EXE
• Click on Tools, Management Agents (or click the Management Agents in the bar)
• Right-click on the management agent with type 'Extensible Connectivity' and select Properties
• In the Properties window, select "Configure Connection Information "The "Connect to:" beginning field should point to the new SharePoint Central Administration site. DO NOT CHANGE THE URL in MIISCLIENT.exe See https://support.microsoft.com/en-us/help/2517937/support-for-modifications-to-the-user-profile-configuration-settings-v

To fix simply log into Central admin and Stop and Start the User Profile Synchronization Service from the server. When the User Profile Synchronization Service re-provisions it will update the connection information within FIM. After stopping/starting the service you may go back into MIISCLIENT.EXE and verify that the URL is now correct.

PowerPivot Service Application

Even though we had already provisioned the PowerPivot service application we had not started to use the application. When we started to try and setup PowerPivot, we noticed the Health Analyzer Rule: 'PowerPivot: Usage data is not getting updated at the expected frequency' and The “PowerPivot Management Dashboard Processing Timer Job” was failing.  Looking at PowerPivot mini-Dumps we noticed that a couple of PowerPivot Properties were point to the original URL.

Using PowerShell (Get-PowerPivotServiceApplication ) we identified the two properties of interest. UsageWorkbookUrl (Can be modified )  and ServiceAppFolderUrl (Read Only), both these properties had the old URL  . We decided to put in Alternate Access Mapping for the old URL to the new URL and that did seem to fix the issue with the Report Management page load but we weren't comfortable that it would address everything, so since this was not in use yet and we were not in production, we decided to delete and recreate the service application.

The journey of Hadoop and Cloud is interesting. Both of these revolutionary technologies started around the same time. However, they charted their own separate paths. When Hadoop burst onto the scene, Cloud was getting started as well. Enterprises starting their Hadoop journey had two choices, on-premise clusters or create virtualized infrastructure in the cloud and create a cluster there.

In those early days, there were many reasons to start Hadoop deployments in the on-premise datacenter. Hadoop workloads were "Big Data" workloads and hence cloud option was restrictively expensive. Storage available in the cloud was also not optimal for heavy data-intensive workloads. Network and disk bandwidth and IOPS were also not optimized for heavy workloads like the ones Hadoop was being put in service for. In addition, Hadoop primarily used an execution engine called MapReduce which was built around disk IO with memory playing a secondary role.

This all worked out great in the early days when Hadoop was primarily a batch analytics engine built around workloads that took minutes to hours to complete and latency was not a big requirement. There were two problems with this approach though. One, disk and compute were tied together. This meant that both of these needed to be upgraded together. If the cluster was maxed out on disks the only way to expand storage is by adding compute to the cluster which will make additional disks available. Two, all these clusters were designed with the mayday approach, which meant design for the highest peak of the workload and everything else will be automatically be taken care of. There was no elasticity built into the cluster. It just ran all day and all night whether the utilization was 5% or 95%. Even that approach would have been good if we were living in a static world. But, the data and size of the data were changing every single day. The estimation of peak workload from last year wouldn't apply to the workload of this year. It resulted in another capital expenditure to expand the cluster for just those 10% days when there will be peak workloads. Rest of the 90% days it will still be largely underutilized.

Right around 2015, an optimized and improved version of the cloud debuted. In this version compute capacity started getting increased with premium nodes becoming available, storage capacity and latency got improved and a slew of network and disk bandwidth improvements provided a much-needed boost. But the real improvement came in terms of decoupling of storage and compute. You no longer needed to have storage and compute on the same nodes. You can have data stored in a persistent storage layer and compute will only come up when it is needed to run jobs or queries. This made everyone's life a lot easier. Storage was rather cheap and you could store as much data as needed without ever getting worried about the capacity. Compute was elastic and you could use as little or as much without getting worried about your peak workloads. No matter what the workload is you will be able to scale. That guarantee, that assurance meant a lot to the organizations.

This advancement is really what saved Hadoop from becoming another technology that gets bogged down by upgrade cycles and capital expenditure. This really saved Hadoop from being relegated to a specialized environment for a specialized workload. Now, Hadoop ecosystem along with Spark is a general purpose compute environment that is being used for everything from data processing to low latency querying, to machine learning and everything in between. This makes the Hadoop ecosystem a player in the long run.

There are still a majority of Hadoop clusters in this world that are running in on-premise environments. Time is ripe to rethink that strategy. Before dipping hands into another capital expenditure budget request think Cloud for Hadoop. That will save your Hadoop clusters in the long run. When it comes to Hadoop the mantra should be "Cloud First, Cloud Must".

We've released new driver and firmware updates for Surface Pro (Model 1796), Surface Pro with LTE Advanced (Model 1807) and Surface Book devices with Windows 10 Version 1703 (Creators Update) or above. On Surface Pro and Surface Pro with LTE Advanced devices these updates include new Surface System Aggregator firmware. On Surface Book devices these updates include new drivers for Surface Integration and Surface Embedded Controller Firmware. These updates improve system stability and on Surface Book devices provide improved battery reliability.

These updates are available currently via Windows Update only and will be announced separately when made available from the Microsoft Download Center.

Surface Pro (Model 1796):

• Surface System Aggregator Firmware (v233.2099.256.0) improves system stability.

Surface Pro with LTE Advanced (Model 1807):

• Surface System Aggregator Firmware (v233.2102.1.0) improves system stability.

Surface Book:

• Surface Embedded Controller Firmware (v90.2098.256.0) improves system stability.
• Surface Integration (v1.1.339.1) improves battery reliability.

A common need for a Remote Desktop Services (RDS) and/or Citrix farm admin, is to remove local profiles from a server.
Another example for this, is the question posted a few days ago in the PowerShell.org forum here.

Funny thing, about 6 years ago, I wrote a vbscript that does that. It just doesn't filter by last used date.

Anyway, I decided to write the Remove-Profile PowerShell function:

#requires -version 3
function Remove-Profile {
    param(
        [string[]]$ComputerName = $env:ComputerName,
        [pscredential]$Credential = $null,
        [string[]]$Name,
        [ValidateRange(0,365)][int]$DaysOld = 0,
        [string[]]$Exclude,
        [switch]$IgnoreLastUseTime,
        [switch]$Remove
    )

    $ComputerName | ForEach-Object {

        if(Test-Connection -ComputerName $_ -BufferSize 16 -Count 2 -Quiet) {

            $params = @{
                ComputerName = $_
                Namespace    = 'rootcimv2'
                Class        = 'Win32_UserProfile'
            }

            if($Credential -and (@($env:ComputerName,'localhost','127.0.0.1','::1','.') -notcontains $_)) {
                $params.Add('Credential', $Credential)
            }

            if($null -ne $Name) {
                if($Name.Count -gt 1) {
                    $params.Add('Filter', ($Name | % { "LocalPath = '{0}'" -f $_ }) -join ' OR ')
                } else {
                    $params.Add('Filter', "LocalPath LIKE '%{0}'" -f ($Name -replace '*', '%'))
                }
            }

            Get-WmiObject @params | ForEach-Object {

                $WouldBeRemoved = $false
                if(($_.SID -notin @('S-1-5-18', 'S-1-5-19', 'S-1-5-20')) -and
                    ((Split-Path -Path $_.LocalPath -Leaf) -notin $Exclude) -and (-not $_.Loaded) -and ($IgnoreLastUseTime -or (
                        ($_.LastUseTime) -and (([WMI]'').ConvertToDateTime($_.LastUseTime)) -lt (Get-Date).AddDays(-1*$DaysOld)))) {
                    $WouldBeRemoved = $true
                }

                $prf = [pscustomobject]@{
                    PSComputerName = $_.PSComputerName
                    Account = (New-Object System.Security.Principal.SecurityIdentifier($_.Sid)).Translate([System.Security.Principal.NTAccount]).Value
                    LocalPath = $_.LocalPath
                    LastUseTime = if($_.LastUseTime) { ([WMI]'').ConvertToDateTime($_.LastUseTime) } else { $null }
                    Loaded = $_.Loaded
                }

                if(-not $Remove) {
                    $prf | Select-Object -Property *, @{N='WouldBeRemoved'; E={$WouldBeRemoved}}
                }

                if($Remove -and $WouldBeRemoved) {
                    try {
                        $_.Delete()
                        $Removed = $true
                    } catch {
                        $Removed = $false
                        Write-Error -Exception $_
                    }
                    finally {
                        $prf | Select-Object -Property *, @{N='Removed'; E={$Removed}}
                    }
                }
            }

        } else {
            Write-Warning -Message "Computer $_ is unavailable"
        }
    }
}

You can use it to report all the profiles in the local computer:

Remove-Profile

To report all the profiles, except a specific profile:

Remove-Profile -Exclude Administrator

To report profiles last used in the past 90 days that would be deleted:

Remove-Profile -DaysOld 90 | Where-Object { $_.WouldBeRemoved }

To report against a remote computer:

Remove-Profile -ComputerName myRemoteServer

To report against a collection of remote computers, authenticating different credentials:

Remove-Profile -ComputerName $Computers -Credential $cred -DaysOld 90

To ignore the LastUseTime value in case the account never logged-on locally (e.g. an IIS ApplicationPool), use the IgnoreLastUseTime switch:

Remove-Profile -ComputerName WebServer01 -DaysOld 30 -IgnoreLastUseTime

To really remove the profiles, use the -Remove switch:

Remove-Profile -DaysOld 90 -Remove

HTH,

Martin.

Once upon a time, application compatibility projects usually followed these basic tenets:

1.)     Find all the applications being used.

2.)     Rationalize as much as possible.

3.)     Thoroughly test as many as possible.

4.)     Repackage all the applications.

Depending on the size of the portfolio and the number end-users, these projects lasted from 9 to 12 months on average – longer for large organizations. Each project had a definitive start date and finish date (which often slipped.) The amount of time it took along with potential slippage of dates was never a major issue when the average operating system migration took place every 5 to 7 years.

Times have changed. Shadow IT has creeped into the enterprise and innovation within this world has created a desire for faster feature delivery. Combine that with the ongoing agility of cloud products beginning with minimum viable products that continuous expand their feature set, and the traditional delivery of Windows does not make the most sense going forward for most enterprises. Like Office, Azure, and Intune, the Windows service delivery has evolved with WaaS (Windows as a Service.) Instead of drastic operating system updates every few years, more gradual feature updates occur on a semi-annual basis.

This warrants a paradigm shift in the world of application management – especially managing compatibility between these gradual operating system updates. The classic project management method of application compatibility just will not work because it 1.) Takes too long and 2.) is often littered with unnecessary work and redundancies.

A Risk-Based Approach

First introduced in 2016 by Chris Jackson, the recommended approach to application compatibility going forward is a risk-based, ongoing, iterative one. The iteration part is easy to grasp because it basically looks on paper as if there will always be some sort of application testing going on, be it for the current release for some applications, or the next release for the more critical applications. The primary purpose of adopting a risk-based approach is to ultimately determine how and when you will test an application for compatibility with the next feature release. In the case of WaaS, while the critical applications are still thoroughly regression tested, the others might be relegated to simple smoke (ILT – Install-Launch-Tested) or automated testing or even reactive testing (test in Pilot or do not test at all.)

Solutions such as Windows Analytics (or partner solutions) can automate and reconcile supportability for a vast amount of commercial vendor (COTS) applications. This can cut down on the time it takes to inventory and rationalize applications. In addition, applications that have been verified as adopted or supported can be relegated out of the critical space in many situations. But what about the rest of the portfolio? How do we get an accurate assessment of how important it will be to test that application?

One recommended approach is to adopt a very common risk management practice of leveraging a simple x/y graph where the variables are impact of regression to the business and the probability of regression. The higher of each, the more critical the application and the more necessary it will be to regression test that application. The probability of regression is rooted in history as well as application composition. How an application impacts a business or organization will vary especially across different industries so there is not really a cookie-cutter one-size-fits-all approach to calculating an application’s impact to the business.

It will be a potentially difficult process at first yet it will be one that, if implemented properly, will be a permanent risk profile for each application’s lifecycle and adjustments to risk profiles will only need to be managed as new applications are introduced and old ones are retired.

Thoughts on Repackaging

Bear in mind that for the majority of WaaS Feature Update scenarios, IPU (In-place Upgrades) will be the approach organizations will adopt if they are on a cadence of upgrading every 6-12 months. Operating system deployment images and provisioning packages will still be updated and maintained for new devices, but for the existing devices, the applications will already be installed, and the operating system will be only experiencing a minor in-place upgrade. In most cases, there will be no reason to reinstall and there will be no reason as well to repackage an application unless the purpose of repackaging is to modernize the application for newer delivery mechanisms such as leveraging the Desktop Bridge to bring an application to the Windows Store.

The Tenets are Evolving

As the deployment and servicing of Windows has evolved so have approaches to managing application compatibility. What we are finding that works well for customers who are able to stay current with Windows and Waas, is an application compatibility management approach that adopts these tenets:

1.)     Leverage tools and telemetry to discover and inventory, and even rationalize.

2.)     Rationalize into risk profiles.

3.)     Test according to risk profiles.

4.)     Don’t repackage applications for the sake of repackaging.

For the second in this series of blog entries we want to look into which vulnerability reports make it into the monthly release cadence.

It may help to start with some history.  In September 2003 we made a change from a release anytime approach to a mostly predictable, monthly release cadence.  October 2003 ushered in what became known as Update Tuesday.  How and when Microsoft releases new products and services in market products has changed over the years, but the monthly delivery of security content has remained steady.

So how do we decide what goes into a monthly security release?  That decision largely rides on required customer action and risk.  Required customer action is realized through products where customers need to take action to protect themselves against a vulnerability.  For consumers, protection is accomplished through automatic updates.  Not all of Microsoft’s offerings require customer action and are accordingly not part of the monthly cadence.  In the next blog entry we will talk about online services cases which are the main class of reports not addressed on Update Tuesday.  To assess risk, we utilize our security bug bar as established by the Security Development Lifecycle (SDL).  Every vulnerability report is triaged against that bar and assigned a severity – critical, important, moderate, low, or defense in depth.  We prioritize critical and important class vulnerabilities to be addressed in our monthly update cycle. 

Lower severity vulnerabilities are typically considered for next version (v.Next) releases.  Those may or may not be backported to platforms currently in support depending on their impact.  On occasion lower severity vulnerabilities will be addressed in a monthly update, but those are more opportunistic updates where additional fixes for higher severity vulnerabilities were already releasing that month.  For more information on what is in support and our support lifecycle, please visit https://microsoft.com/lifecycle. Later in this blog series we will discuss the v.Next process, how that has evolved over the years of our release cadence, and what researchers can expect from reports that fall into these classes.

The combination of all of these processes are what customers experience as our Update Tuesday cadence.  The releases represent the highest risk vulnerabilities.  We document the fixes with the risk information so customers can better make informed decisions for their environments.  More information on how we create security updates can be found here: https://technet.microsoft.com/en-us/security/dn436305.  For security researchers, these releases show their research and collaboration with Microsoft to better protect customers together.

In our next blog entry, we will explore vulnerability reports and resolution in our online services space.

Phillip Misner,

Principal Security Group Manager

Microsoft Security Response Center

Consider the following scenario:

You have SharePoint 2016 set up to import user profiles from an External Identity Manager.

We'll say you're using Microsoft Identity Manager (MIM) 2016 to import profiles from some 3^rd party LDAP directory. The profiles should be imported as Trusted Provider type users (SAML-claims).

You run a Sync, and everything goes fine until the export step for the SharePoint Management Agent (SP MA).

There are export errors for each user object "Error returned during object Export"

The error detail shows:

"Export retry FAILED for Entity(ObjectType: user, Anchor: User1__8c9c474c-a26c-4295-aedc-739d547a2f15).

Error System.Web.Services.Proptocols.SoapExtension: Server was unable to process request - One or more errors occurred. - The trust relationship between the primary domain and the trusted domain failed."

In the SharePoint ULS logs, you may see this error for each user:

w3wp.exe (0x30E4) 0x172C SharePoint Foundation Runtime aoxsq Medium Sending HTTP response 500 for HTTP request POST to http://yourCentralAdminServer:5555/_vti_bin/ProfileImportExportService.asmx

Cause:

You did not configure your property mappings correctly in MIM.

See my colleague Adams blog post on the subject: https://blogs.technet.microsoft.com/adamsorenson/2018/01/31/sharepoint-2016-mim-and-samlfba-user-profiles/

Specifically, the mappings for SPS-ClaimProviderType,
SPS-ClaimProviderID, and SPS-ClaimID are either missing or not mapped properly.

These need to be configured properly so that SharePoint can construct the proper account name for the user profile. For example: i:0e.t|ADFS|User1

In this case, the "i:0e.t" part comes from the identity claim type (UPN in my case), "ADFS" comes from SPS-ClaimProviderID, and of course "User1" is the value for SPS-ClaimID.

Without these mappings, SharePoint will receive an "Add" for an isolated (not qualified) account name like "User1". Because it doesn't know any better, SharePoint assumes that this must be a local Active Directory user, so it makes a call to the LsarLookupNames4 method in an attempt to resolve the user.

In this case, the user comes from a 3^rd party LDAP directory, so it does not exist in Active Directory. Because the user name is not qualified (ie: not in domainusername or username@domain.com format) every trusted Active Directory domain and forest will be searched, which could take a long time and fail with the "The trust relationship between the primary domain and the trusted domain failed" error.

Resolution:

Map SPS-ClaimProviderType SPS-ClaimProviderID and SPS-ClaimID properly.

Mappings in the LDAP provider Management Agent

SPS-ClaimProviderType should be mapped to a Constant of "Trusted"

SPSClaimProviderID should be mapped to a Constant and contain the name of your SharePoint Trusted Identity Token Issuer. In my case, it's named "ADFS".

To get the proper name, you would run this PowerShell:

Get-SPTrustedIdentityTokenIssuer | select name

SPS-ClaimID needs to be mapped to whatever your Identity / Identifier claim is. In my case it's User Principal Name (UPN).

You can check that by running this PowerShell:

$ti = Get-SPTrustedIdentityTokenIssuer

$ti.IdentityClaimTypeInformation

Mappings in the SharePoint Management Agent:

In the SharePoint MA, these properties should just be flowed through:

(この記事は2017 年11月29日にMicrosoft Partner Network blog に掲載された記事 Work smarter, not harder: the Bullet Journal の翻訳です。最新情報についてはリンク元のページをご参照ください。)

真の生産性は、単に忙しい状態を続けるだけで実現できるものではありません。やるべきことの意図を明確にして、効果的に遂行する必要があります。同様に、優れたクラウド ビジネスを構築するためには、多大な集中力と自制心が必要です。パートナー様がデジタル トランスフォーメーションを通じてお客様の成果達成を支援するにあたっては、デザイナーの Ryder Carroll 氏が生み出した、人気の手帳術「バレット ジャーナル (英語)」をお勧めします。

Carroll 氏は、TEDx Talk (英語) の中で自身が語っているように、幼いころに注意欠陥障害と診断されました。そこで、自分の心を整理して集中するためのシンプルな手法を編み出したところ、意外にもそのやり方が他の人にとっても同様に有効だということが判明しました。Carroll 氏の手助けにより、友人や家族は注意散漫な生活を改め、明確な意図を持った生活を送れるようになったのです。その後、バレット ジャーナルは口コミで大きな人気を集めることになりました。

このアナログ ソリューションをデジタル化することで、紙の手帳をカレンダー、タスク リスト、予定表、インデックスなどのカスタマイズされたログに変換できます。実用性を重視したり、創造力を発揮したりして、バレット ジャーナルを好みに合わせてカスタマイズする方法は無数にありますが、根本的な考え方はいくつかの主要な要素で構成されます。これらの体系に従うことで、重要でない事柄を頭から排除して、重要な事柄に時間と労力を注ぐことができます。

執筆者: Yi Zhong (Program Manager II)

このポストは、2018 年 2 月 12 日に投稿された Azure IoT SDKs released new Long-Term Support branch の翻訳です。

Azure IoT SDK で、新しい Long Term Support (LTS) Branch がリリースされました。マイクロソフトは、SDK をオープンな GitHub リポジトリで開発し、その新バージョンを隔週でリリースすることで最新機能を皆様にお届けしています。また 2017 年 7 月からは、重大なバグの修正やセキュリティ更新プログラムのみを提供するブランチの提供もスタートしました。2018 年 1 月にリリースした最新の LTS バージョンでは、Azure IoT Hub および Azure IoT Hub Device Provisioning Service と連携するクライアントを開発することができます。

LTS Branch では、デバイスのコードに与える影響を最小限に抑えながら、必要なセキュリティ更新プログラムと重要なバグの修正を確実に提供します。また、開発者はリポジトリのマスター ブランチの最新版にアクセスして最新のテクノロジや機能を利用できる一方、報告していた問題への対応が早く迅速に解決されるという 2 つのメリットがあります。

この最新の LTS バージョンは、GitHub の lts_2018_01 ブランチ、および NuGet、PiPy、apt-get、Maven、NPM などのパッケージ マネージャーから入手できます。マイクロソフトのすべての SDK は、セマンティック バージョニングに従っており、メジャー バージョンは大幅な変更があった場合に変更され、マイナー バージョンは新機能が追加された場合に変更され、修正バージョンはバグが修正された場合に変更されます。

LTS のタイムラインは以下のとおりです。

1.    6 か月ごとに LTS の新バージョンがリリースされます。新しい LTS Branch は開発者のコード アクセスを可能にするために作成され、新しい LTS パッケージのセットは、サポート対象のパッケージ マネージャーでリリースされます。LTS Branch のバージョニングは、リリース時のマスター ブランチに従います。マスター ブランチで非推奨となった API は、メジャー バージョンの更新時に削除され、その後リリースされる LTS Branch でも使用できません。

2.    各バージョンは6 か月間アクティブに提供され、セキュリティ更新と重要なバグの修正を受け取れます。6 か月が経過した後は、LTS の新バージョンがリリースされます。前のバージョンは非推奨モードになり、更新は提供されなくなります。

3.   1 年間の有効期限が終了すると、そのブランチは GitHub から削除されますが、パッケージ マネージャーのパッケージは引き続き提供されます。

このタイムラインについてのフィードバックは UserVoice (英語) までお気軽にお寄せください。

執筆者: Ye Gu (Principal Program Manager, Azure Developer Experience)

このポストは、2018 年 2 月 12 日に投稿された Azure Redis Cache geo-replication is now generally available の翻訳です。

このたび、Azure Redis Cache で geo レプリケーション機能の一般提供を開始します。Redis Cache は、一般的なオープン ソース Redis のインメモリ型キー/値ストアを基盤とした、Microsoft Azure が提供するサービスとしてのキャッシュです。geo レプリケーションに対応したことにより、開発者や IT プロフェッショナルの皆様に、ディザスター リカバリー プラン構築のための Azure サービスの 1 つとして Redis Cache をご利用いただけます。この機能では、万が一リージョン規模の障害が発生した場合でも、クラウドで実行するミッション クリティカルなアプリケーションの可用性を確保することが可能です。Azure Site Recovery 対応の Virtual Machines、Traffic Manager、Cosmos DB や SQL Database をはじめとするデータ サービスなどの既存のオプションと共に、Azure で回復性の高いソリューションを構築する際にお役立てください。

Redis Cache の geo レプリケーションの一般提供開始にあたって、パブリック プレビュー (英語) にご参加いただいた皆様に感謝申し上げます。検証の際には、皆様からの貴重なご意見を参考にさせていただきました。ご協力ありがとうございました。

Redis Cache で geo レプリケーションをセットアップ

geo レプリケーションは、Azure Redis Cache の Premium サービス レベルで提供されます。この機能を使用する場合、事前に Premium レベルのキャッシュ インスタンスのペアを準備する必要があります。既に Premium レベルのキャッシュ インスタンスをお持ちの場合は、お好みのセカンダリ Azure リージョンを 1 つ追加するだけで済みます。Basic レベルまたは Standard レベルのインスタンスを使用している場合には、Premium レベルにアップグレードする必要があります。現時点では、プライマリ キャッシュ インスタンスごとに geo レプリケーション用のキャッシュ インスタンスを 1 つセットアップすることができます。インスタンスの設置場所に制限はありませんが、高い回復性を維持するためには、異なる Azure リージョンへ設置することをお勧めします。

geo レプリケーションをセットアップするには、2 つの Azure Redis Cache インスタンスをリンクさせる必要があります。最も簡単なのは Azure ポータルで操作する方法です。詳しい手順はこちらの「Azure Redis Cache の geo レプリケーションの構成方法」をご覧ください。

geo レプリケーションを構成すると、プライマリ キャッシュ インスタンスはこれまでと変わらずクライアントからの要求を処理し、レプリカはプライマリ インスタンスからデータのレプリケーションを受け付けるようになります。レプリカは読み取り専用モードに制限されているため、セカンダリ拠点で実行中のアプリケーションでもすぐに使用することができます。

フェールオーバーの管理

キャッシュのパフォーマンスを最適化するためには、同一 Azure リージョンに設置することをお勧めします。クライアントとサーバーが同一リージョンに設置されている場合、通常、Azure Redis Cache を使用したアプリケーションの応答時間は往復のネットワーク レイテンシを含めて 10 ミリ秒未満に抑えられます。反対に、Azure リージョンが物理的に離れていると全体の応答速度は大幅に低下します。このため、Azure Redis Cache が別のリージョンの geo レプリケーション用キャッシュ インスタンスに自動でフェールオーバーされることはありません。

万が一リージョン レベルでサービスが停止した場合には、ビジネス継続性プランに定義されているとおりに、セカンダリ拠点へのアプリケーション スタック全体の復旧をオーケストレーションします。たとえば、Traffic Manager で要求をルーティングして完全冗長した 2 つの Azure リージョンでアプリケーションを実行している場合、Azure Redis Cache をフェールオーバーしてから、Traffic Manager がすべての要求をセカンダリ拠点にリダイレクトするように変更する必要があります。プライマリ キャッシュのリンクを解除してアプリケーションを構成すれば、いつでも同一 Azure リージョンの geo レプリケーション先のセカンダリ キャッシュ インスタンスにフェールオーバーすることができます。2 つのキャッシュ インスタンスの間の geo レプリケーションのリンクが解除されると、セカンダリ インスタンスが独立してプライマリとなり、書き込み要求を受け付けるようになります。geo レプリケーションのリンクは、Azure ポータルで手動で解除できます。また、PowerShell コマンド (英語) を使用して自動で解除することもできます。

料金

geo レプリケーションの料金は、Azure Redis Cache の Premium サービス レベルの料金に含まれます。ただし、別のリージョン間でデータを複製する場合、送信データ転送の標準料金がかかります。

この機能をぜひお試しください

Azure Redis Cache で geo レプリケーションを使用すると、予期しない災害から重要なデータを保護できます。今回ご紹介した機能や Azure サービスの他の geo 冗長機能を活用すると、クラウド サービスに確実なディザスター リカバリー プランを実装し、ミッション クリティカルなアプリケーションの可用性を確保できるようになります。

ご不明な点やご意見は、お気軽に AzureCache@microsoft.com までお寄せください。

こんにちは。

日本マイクロソフト、Microsoft Japan IIS / Azure Bot Service Support Team の鈴木です。

今回は Web Deploy ツールを利用した IIS の移行方法をご案内します。

IIS 7.5 から IIS 10.0 へ、といった IIS の環境を別のマシンへ移行する場合にご利用いただけるツールとして、Web Deploy (Web 配置) ツールがあります。

Web 配置ツール
https://technet.microsoft.com/ja-jp/library/dd939114.aspx

移行時にモジュールの依存関係などの確認も可能であり、弊社ではこのツールを利用した移行を推奨しております。

Web Deploy で移行可能な範囲について
==================================
Web Deploy を利用した移行により実現可能な範囲は以下の通りです。

a) IIS の構成
b) コンテンツのコピー

一方、アプリケーションの構成により別途対策が必要な部分として以下の要素が考えられます。

c) ユーザーアカウントの作成
d) 必要な役割サービス、.NET Framework 、その他コンポーネントのインストール
e) アプリケーションの動作検証

また、Web Deploy によるコピーが成功した場合でも、アプリケーションの実装や利用されるモジュールのバージョンの差異等により、意図されている動作にならない可能性もありますので、コンテンツのコピーまで完了した後、Web アプリケーションの動作について十分な評価を行ってください。

Web Deploy を利用した移行手順
==================================
※紹介する参考資料は IIS 7.0、 IIS 7.5 を対象に記載されているものもありますが、 IIS 7.5 以降の各バージョン (IIS 10 を含む) でもご利用いただける内容です。

1) Web Deploy ツールのインストール

下記サイトから Web Deploy ツールをインストールします。

Web Deploy v3.5
https://www.microsoft.com/ja-JP/download/details.aspx?id=39277
※移行先サーバー、移行元サーバーの両方にインストールする必要があります。

- 参考資料
Web Deployment Tool Overview
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd569058(v=ws.10)

2) 移行元および移行先のバックアップ

バックアップ および 復元のコマンドは以下の通りです。
移行実施前に、移行元および移行先のそれぞれでバックアップを取得してください。

バックアップ時
>%SystemRoot%system32inetsrvappcmd.exe add backup <任意のバックアップ名>

復元時
>%SystemRoot%system32inetsrvappcmd.exe restore backup <復元したいバックアップ名>

- 参考資料
appcmd によるバックアップの作成
http://technet.microsoft.com/ja-jp/library/ff453992.aspx

AppCmd.exe の使用の開始 - バックアップの管理
http://technet.microsoft.com/ja-jp/library/dd647592.aspx#Managing

3) 依存関係の確認

移行元サーバーのコマンドプロンプトを開き、 Web Deployment Tool インストールフォルダ (既定で c:Program FilesIISMicrosoft Web Deploy V3) に移動した上で、以下のコマンドを実行します。

>msdeploy -verb:getDependencies -source:webServer

※移行先サーバーに個別にインストールしなければならない可能性のあるコンポーネントが XML 形式で出力されます。
※本コマンドで使用可能なパラメータ等の詳細については、”msdeploy /?” を実行することで確認できます。

- 参考資料
Web Deploy GetDependencies Operation
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd569090(v=ws.10)

Web Deploy Operation Settings

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd569089(v=ws.10)

4) 必要なコンポーネントのインストール

手順 3) で確認した必要なコンポーネントを、移行先サーバーにインストールします。

※以降でご案内する手順について、構成情報のみをコピーする場合には、”-disableLink:ContentExtension” オプションを指定します。コンテンツ含めてコピーする場合には、”-disableLink:ContentExtension” オプションを除外します。

5) 移行元サーバーのアーカイブ取得

移行元サーバーのコマンドプロンプトを開き、 Web Deployment Tool インストールフォルダ (既定で c:Program FilesIISMicrosoft Web Deploy V3) に移動した上で、以下のコマンドを実行します。

構成情報のみをコピーする場合
> msdeploy -verb:sync -source:webServer -dest:archivedir=c:archive,encryptPassword=Password123 -enableLink:AppPoolExtension -disableLink:ContentExtension > msdeployarchive.log

コンテンツを含む場合
> msdeploy -verb:sync -source:webServer -dest:archivedir=c:archive,encryptPassword=Password123 -enableLink:AppPoolExtension > msdeployarchive.log

※コマンド実行後、c:archive に Web サイトのコンテンツ ディレクトリ、アプリケーション ディレクトリ、archive.xml、systemInfo.xml が作成されます。
※出力先にフォルダ、ファイルが既に存在する場合は上書きされます。
※アーカイブの出力先フォルダを c:archive、ログファイル名を msdeployarchive.log とした場合のコマンド例です。

6) 手順 5) で取得したアーカイブフォルダを移行先サーバーへコピーします。

例) 移行元サーバーの c:archive を、移行先サーバーの c:archive にコピーします。

7) 移行の動作検証

移行先サーバーのコマンドプロンプトを開き Web Deployment Tool インストールフォルダ (既定で c:Program FilesIISMicrosoft Web Deploy V3) に移動した上で、以下のコマンドを実行します。

構成情報のみをコピーする場合
> msdeploy -verb:sync -source:archivedir=c:archive,encryptPassword=Password123 -dest:webServer -enableLink:AppPoolExtension -disableLink:ContentExtension -whatif > msdeploysync.log

コンテンツを含む場合
> msdeploy -verb:sync -source:archivedir=c:archive,encryptPassword=Password123 -dest:webServer -enableLink:AppPoolExtension -whatif > msdeploysync.log

※whatif フラグを指定してコマンドを実行することで、実際に移行を実施する前に、動作検証を行うことができます。
※アーカイブの出力先フォルダを c:archive、ログファイル名を msdeploysync.log とした場合のコマンド例です。

コマンド実施後に、msdeploysync.log でエラーや警告が出ていないか、確認します。

8) 移行の実施

手順 7. の出力内容を確認し、特にエラー等が表示されていない場合、whatif フラグを指定せずに同じコマンドを実行し、実際に IIS の構成情報の移行を行います。

構成情報のみをコピーする場合
> msdeploy -verb:sync -source:archivedir=c:archive,encryptPassword=Password123 -dest:webServer -enableLink:AppPoolExtension -disableLink:ContentExtension > msdeploysync.log

コンテンツを含む場合
> msdeploy -verb:sync -source:archivedir=c:archive,encryptPassword=Password123 -dest:webServer -enableLink:AppPoolExtension > msdeploysync.log

※アーカイブの出力先フォルダを c:archive、ログファイル名を msdeploysync.log とした場合のコマンド例です。

補足
=====================
1) appcmd での移行について

appcmd にて取得可能なバックアップは、基本的に取得した対象のサーバーでの IIS 構成情報の復元にご利用いただけます。

バックアップに含まれる 「%SystemRoot%system32inetsrvconfigapplicationHost.config」 ファイルには、パスワードを暗号化するために利用するサーバー固有のキーの情報が含まれます。
また、サーバーごとにインストールされているモジュールが異なっている場合、構成情報に含まれる設定と実際の IIS のインストール状況に差異が生じ、正常に動作しない可能性があります。

そのため、他サーバー間の移行の際には上記でご案内した Web Deploy ツールをご利用ください。

2) FTP サイトの移行について

FTP 7.5 以降の移行では上記でご案内しました Web Deploy ツールをご利用いただけます。
ただし、 FTP 6.0 から FTP 7.5 へ移行したいという場合には、上記の方法はご利用いただけません。

FTP 6.0 では、IIS 7.0 以降で IIS 構成ファイルとして利用される applicationHost.config ファイルではなく、IIS 6.0 以前で利用していた MetaBase.xml ファイルを構成情報の設定に利用します。
Windows Server 2008 には、この MetaBase.xml のバックアップを行うスクリプト ツールが導入されていないため、自動でのバックアップ、リストアを行うことができません。
そのため、FTP 6.0 からの移行の際には、お手数ですが手動での移行をご検討くださいますようお願いいたします。

以上です。