Uncover the resources needed to assist your customers with threat, identity and information protection by exploring the offerings within Microsoft 365. This technical webinar is carefully planned and delivered by Microsoft Partner Technical Consultants, available to you as a Partner Network member at no cost.

Introduction to Microsoft 365 Security and Compliance - Explore the comprehensive collection of security offerings within Microsoft 365 to help you protect, detect and respond to security attacks. In this session you’ll receive an overview of Microsoft 365 provided security capabilities, equipping you to provide security services for customers. Our Microsoft 365 technical experts walk you through threat protection, identity projection, and information projection and the resources available to you as a partner.

Explore the full suite of technical webinars and consultations available for the Security & Compliance technical journey at aka.ms/SecurityTechJourney.

In short: Please avoid making any edits and or posting any new TN Wiki articles between November 19 5pm PST and 10pm PST.

What’s happening?
The TechNet Wiki site  https://social.technet.microsoft.com/wiki will be migrating from the current infrastructure to a full Azure hosted platform, this is part of our roadmap for a full Azure adoption across all our services and platforms.

When is this happening?
The platform team will starting the migration/cutover on 11/19/2018 @5pm PST and our work window to complete this migration is approximately 4 hours. To keep safe, please allow another hour of reserve... (so.. ending around 10PM PST).

What is the Impact?
No downtime is expected as we will have both systems running in parallel, however, during the work window we request that all users avoid making any edits and or posting any new articles until the migration is completed, this is absolutely critical as data loss can incur should a user perform any changes during that period.

For your information
PST is GMT-8, which means

• 5PM or 17h00 PST = 1AM GMT (20/nov)
• 10PM or 22h00 PST = 6 AM GMT (20/nov)

This is a pretty unique scenario, but it came up recently and exposed a little-known configuration "gotcha" with SharePoint.

Consider the following scenario:

• You have two Trusted Providers (SAML auth) and are using them both for the same web application.
  • For example, you have an Internal zone using URL https://teamsInternal.contoso.com that uses Trusted Provider "ADFS-Internal"
  • And an External zone using URL https://teams.contoso.com, and Trusted Provider "ADFS-External"
• You create both Trusted Identity Token Issuers using the same token signing certificate, creating the "ADFS-External" one first.
• When internal users browse to the site, they are authenticated, but receive the "Sorry, this site has not been shared with you" Access Denied page.
• In reviewing the ULS logs and /or a Fiddler trace, you see that the Internal user is indeed authenticated, but is authenticated as an External user, which does not have permission to the site, thus the "access denied".

Notes:

• I cannot come up with a practical scenario for using two separate providers instead of handling both user types with one trusted provider, but it has happened. More than once.
• Please forgive the references to SharePoint 2010 and ADFS 2.0 in the above link. The steps are still valid for the most recent version of both.
• I'll use "ADFS" as my Trusted Provider example, but the same rules apply to all SAML providers (SiteMinder, Ping Federate, Okta, etc).

That's weird, why does that happen?

Both the Internal ("ADFS-Internal") and External ("ADFS-External") Trusted Identity Token Issuers have been configured to use the same token signing certificate.

Because SharePoint uses the certificate it receives from ADFS to match the Trusted Identity Token Issuer within SharePoint, it will match that certificate to only the first Trusted Identity Token Issuer in the list that uses that same certificate.

In this case, the result is that it will always match the certificate to the "ADFS-External" Token Issuer because it was the first one created, and appears first in the list.

The result is that every user will be authenticated as an External user, even when accessing the site using the Internal URL.

You're saying the user is Authenticated. Why do they get Access Denied?

Most of this goes back to the concept of Authentication (who are you) vs Authorization (what permission do you have).

However, in SharePoint, I find it's even more easily confused because the same physical person can authenticate to SharePoint as multiple different "users".

Continuing with my example above, the same person can authenticate using the External URL with the "ADFS-External" trusted provider, and with the Internal URL with the "ADFS-Internal" trusted provider. SharePoint sees those two users as completely separate. Knowing that SharePoint uses the name of the Trusted Provider as part of the users account name, it should become clear why:

i:0e.t|adfs-internal|josh@joroar.local is not the same user as i:0e.t|adfs-external|josh@joroar.local

Those two user accounts will always be treated by SharePoint as separate. There's no way to "merge" their permission sets, or anything of the like.

This concept is really just a variation on one I blogged about previously: https://blogs.technet.microsoft.com/spjr/2018/07/24/sharepoint-windows-user-not-equal-to-adfs-user/

How can I tell if I have this issue?

You should be able to run the following PowerShell to check which certificate each Trusted Identity Token Issuer is using:

Get-SPTrustedIdentityTokenIssuer | select name, signingcertificate | fl

Check the "Thumbprint" value on the SigningCertificate for both Token Issuers. If it's the same value, it's the same certificate.

What can be done?

If you're set on using two different Trusted Providers within the same web application, then one of them must use a different token signing certificate. How you do that on the SAML provider side varies by implementation (ADFS, SiteMinder, Ping, OKTA, etc), so I won't get into that here.

However, once you have a new token-signing certificate, updating SharePoint to match is quite simple. It's the same steps you would use when your token signing certificate expires and you need to update SharePoint to use a new one.

The example below assumes I got a new certificate for the "Internal" trusted provider, and I'm leaving the External one alone.

-- Update the Internal Token Issuer to use the new certificate using PowerShell:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:newInternalCert.cer")

$ti = Get-SPTrustedIdentityTokenIssuer "ADFS-Internal"

Set-SPTrustedIdentityTokenIssuer $ti -ImportTrustCertificate $cert

-- Add the new certificate to the farm trust (Central Admin | Security | Manage Trust).

-- Make sure it's trusted at the Windows level by importing it (and any parent certificates in the cert chain) to the Trusted Root Authorities certificate store on the SharePoint servers.

Happy Coding!

- Sri Lankan Wiki Ninja Jaliya (Blog, MSDN Profile, Twitter)

昨年、マイクロソフトは Microsoft Teams を Skype for Business に替わる Office 365 のインテリジェント コミュニケーションの主要クライアントにしていくという計画を発表 ^*いたしました。この 1 年、マイクロソフトは、Microsoft Teams に新しい機能を続々と実装し、2018 年 8 月に Skype for Business Online の機能を Microsoft Teams に導入するロードマップ ^*が完了したことを発表 ^*し、Microsoft Teams でメッセージング、会議、通話をご利用いただけるようになりました。今後も引き続き、Microsoft Teamsに新しい機能を実装してまいります。マイクロソフトは、お客様に Microsoft Teams へのアップグレードをお薦めしております。
^*（英語）のサイトとなります。

Microsoft Teamsにアップグレードする方法について

• マイクロソフトによる自動アップグレード
  11 月 1 日より、パートナー様からご販売いただいたスイート製品^*１ を 500 ユーザー未満でご利用されている小規模テナントのお客様対して、Skype for Business から Microsoft Teams への自動アップグレードを提供しております。
• お客様・パートナー様主導によるアップグレード
  自動アップグレードの対象ではないお客様^*２ は、お客様の IT 管理者、またはお客様に代わってパートナー（販売店）様にて、お客様のテナント、またはユーザーを Skype for Business から Microsoft Teams にアップグレードいただくことが可能です。
  また、自動アップグレードの対象のお客様も、スケジュールされたアップグレード期日に先立って、お客様またはパートナー様によりアップグレードいただくことも可能です。

*1 Office 365（Business Premium、Business Essentials、E1、E3、E5、F1）、Microsoft 365（Business、E3、E5、F1）が対象となります。

*2 大規模テナントのお客様の他、Skype for Business Online 単体サービスをご利用中のお客様テナント、電話システムをご利用中のお客様テナント、Skype for Business Server とのハイブリッドでご利用中のお客様テナントは、自動アップグレードの対象ではありません。

マイクロソフトによる自動アップグレードについて

自動アップグレードの対象となるお客様には 30 日前より管理者様宛のメール、ならびに管理ポータルのメッセージ センターにて通知を行います。

通知を受け取られましたら、自動アップグレードをご希望のお客様は、そのまま自動アップグレードをお待ちください。自動アップグレードを延期されたいお客様は、Microsoft サポート、またはパートナー（販売店）様にご連絡ください。

お客様・パートナー様主導によるMicrosoft Teamsへアップグレードについて

• Microsoft Teams へのアップグレードの準備ができているお客様は、Skype for Business と Teams との並行利用または Teams への完全移行のためのベスト プラクティスやガイダンス、リソースを含むフレームワークを提供するセルフ ガイダンス（英語）を参照して、お客様ご自身でアップグレードいただけます。
• Microsoft Teams & Skype for Business 管理センターで、アップグレード ツールをご提供いたします。テナント管理者は、ユーザーごとまたはテナント全体で Skype for Business から Teams へのアップグレードを設定いただけます。PowerShell コマンドレットを利用して、グループや部署単位またはテナント全体でアップグレードを設定いただくことも可能です。
• 大規模なお客様、および電話システムやハイブリッドなど高度な機能を Skype for Business Online でご利用のお客様は、Teams のロードマップを評価し、機能がビジネス要件を満たしているかどうか判断し、Teams への移行計画を立案ください。

移行計画の策定、アップグレードにあたっては、導入パートナーにご相談ください。

■関連情報

• Skype for Business からMicrosoft Teams への移行
• サポート技術情報: Microsoft Teams now the primary client for meetings and calling in Office 365 (英語)
• Microsoft Teams is now a complete meeting and calling solution (英語)

開発ツール対応 OS 一覧

最終更新日: 2017/10/11
 
ご注意: この一覧は全て開発ツール自体の動作に関する情報であり、以下の開発ツールを使用してお客様が開発されたアプリケーションの対応に関するものではありません。これらの開発ツールを使用して開発されたアプリケーションは、全てお客様の責任において必要な環境下でテストしていただく必要があります。お客様の開発されたアプリケーションの動作に関して、弊社では一切の保証はいたしませんので、あらかじめご了承ください。

Visual C++ 6.0

○ (*1)

○ (*3)

×

×

×

×

×

×

×

×

×

×

Visual Basic 6.0

○ (*1)

○ (*3)

○ (*7)

○ (*7)

×

×

×

×

×

×

×

×

Visual InterDev 6.0

○ (*1)

×

×

×

×

×

×

×

×

×

×

×

Visual SourceSafe 6.0c (*2)

○ (*1)

○

×

×

×

×

×

×

×

×

×

×

Visual SourceSafe 6.0d

○ (*1)

○

×

×

×

×

×

×

×

×

×

×

Visual SourceSafe 2005

○ (*4)

○

○ (*10)

○ (*10)

○ (*10)

○ (*10)

×

×

×

×

×

×

Visual Studio .NET 2002

○

○

×

×

×

×

×

×

×

×

×

×

Visual Studio .NET 2003

○

○

×

×

×

×

×

×

×

×

×

×

Visual Studio 2005

○ (*5)

○ (*6)

○ (*8)

○ (*8)

○ (*8)

○ (*8)

×

×

×

×

×

×

Visual Studio 2008

○ (*5)

○ (*9)

○

○

○ (*11) (*12)

○ (*11)

×

×

×

×

×

×

Visual Studio 2010

○ (*13)

○ (*14)

○ (*15)

○ (*16)

○

○

○ (*17)

○ (*17)

○ (*17)

○ (*17)

○ (*17)

○ (*17)

Visual Studio 2012

×

×

×

×

○

○

○

○

○

○

○

○

Visual Studio 2013

×

×

×

×

○

○

○

○

○

○

○

○

Visual Studio 2015

×

×

×

×

○

○

○

○

○

○

○

○

Visual Studio 2017

×

×

×

×

×

○

×

○

×

○

○

○

*1: リモート デスクトップおよびユーザーの簡易切り替えは除きます。
*2: Visual SourceSafe 6.0c 以前のバージョンをお使いのお客様は適切なサービス パックの適用が必要です。詳しくは Visual SourceSafe データベース運用ガイドをご覧ください。
*3: Visual Studio 6.0 Service Pack 6 の適用が必要です。

» Visual Studio 6.0 Service Pack 6 のダウンロード (PDF)

*4: Windows XP Professional Service Pack 2 以上
*5: Windows XP Home Edition Service Pack 2 以上、Windows XP Professional Service Pack 2 以上、Windows XP Media Center Edition 2002 Service Pack 2 以上、Windows XP Media Center Edition 2004 Service Pack 2 以上、Windows XP Media Center Edition 2005 Service Pack 2 以上、および Windows XP Tablet PC Edition Service Pack 2 以上
*6: Windows Server 2003 Standard Edition SP1 以上、Windows Server 2003 Enterprise Edition SP1 以上、Windows Server 2003 Datacenter Edition SP1 以上、および Windows Server 2003 Web Edition SP1 以上

※ Visual Studio 2005 は、Intel Itanium (IA64) を搭載しているコンピューターにはインストールできません。

*7: Windows Vista および Windows Server 2008 以降の環境における Visual Basic 6.0 のサポートについては、「Windows Vista、 Windows Server 2008、Windows 7、および Windows 8 に対する Visual Basic 6.0 のサポートに関する声明」をご覧ください。
*8: Visual Studio 2005 を Windows Vista もしくは Windows Server 2008 環境で動作させるためには、Visual Studio 2005 Service Pack 1 および Visual Studio 2005 Service Pack 1 Update for Windows Vista の適用が必要です。

※ Visual Studio 2005 Team Foundation Server は Windows Server 2008 上での動作はサポートされません。

*9: Windows Server 2003 Service Pack 1 以上、もしくは Windows Server 2003 R2 以上

※ Visual Studio 2008 は、Intel Itanium (IA64) を搭載しているコンピューターにはインストールできません。

*10: Visual SourceSafe 2005 については、HTTP 経由のシナリオがサポートされません。
*11: Visual Studio 2008 Service Pack 1 の適用が必要です。
*12: Team Foundation Server (TFS) のアプリケーション層は 64-bit OS に対応しておりません。TFS を 1 台のコンピューターで構成する場合、Windows Server 2008 R2 にはインストールすることはできません。TFS を 2 台以上のコンピューターで構成する場合、データベース層のみ Windows Server 2008 R2 にインストールすることができます。アプリケーション層は Windows Server 2008 R2 にはインストールできません。詳しくはインストール ガイドをご覧ください。
*13: Windows XP Service Pack 3 以上
*14: Windows Server 2003 Service Pack 2 以上、もしくは Windows Server 2003 R2 以上

※ Visual Studio 2010 は、Intel Itanium (IA64) を搭載しているコンピューターにはインストールできません。

*15: Windows Vista Service Pack 2 以上
*16: Windows Server 2008 Service Pack 2 以上
*17: Visual Studio のパフォーマンス ツールは、Windows 8 を実行しているコンピューターではサポートされていません。(KB2748309)

その他のご注意

• 本ページに記載している多くの旧バージョンの製品については、パッケージでの販売を終了しております。しかし、MSDN サブスクリプションでは最新の Visual Studio ファミリをはじめ、一部の旧バージョンも提供しております。

• ここに記述されている情報は全て日本語版に関するものです。
• マイクロソフトでは、ユーザーが開発したアプリケーションが対応 OS で動作するかどうかに関しては一切保証しません。ユーザー自身の責任で OS 毎にテストしていただく必要があります。
• この表は各 OS 上の開発ツールの動作状況を示しています。組み合わせによっては、各 OS 特有の機能を使用したアプリケーションを構築できない場合があります。
• 必ず最新版サービス パックを適用してください。
• InstallShield for Microsoft Visual C++ 6.0、Seagate Crystal Reports for Visual Basic などのマイクロソフト製以外の製品の動作確認状況は上記の表に含まれておりません。これらの製品のテクニカル サポートにつきましては、"お使いになる前に"、または「[VB] Crystal Reports for Visual Basic のサポートについて」をご参照ください。
• マイクロソフトによるサポート サービスは、その製品がサポート ライフサイクル期間に提供されます。

» 開発ツールのサポート ライフサイクル

• 以前のバージョンの対応状況はこちらをご覧ください。

Find resources that help you build and sustain a profitable cloud business, connect with customers and prospects, and differentiate your business. Read previous issues of the newsletter and get real-time updates about partner-related news and information on our US Partner Community Twitter channel.

Looking for partner training courses, community calls, and events? Refer to the Hot Sheet training schedule for a six-week outlook that’s updated regularly as we learn about new offerings. To stay in touch with us and connect with other partners and Microsoft sales, marketing, and product experts, join our US Partner Community on Yammer.

New posts on the US Partner Community blog

• How to stay connected and find resources as a Microsoft partner
• Keep your privileged access secure with Azure AD PIM and PAM in Office 365: Part 1
• Time to upgrade: How to prepare for Windows Server 2008 end of support
• Embrace new Dynamics 365 features and offerings in the October 2018 release
• Announcing availability of a new step-by-step guide to help Microsoft partners develop and grow cloud opportunities
• Friends don’t let friends compromise security: Extending cybersecurity to supply chains
• Microsoft Information Protection and Unified Labeling
• Get started with the Partner Investment Engine (PIE)
• New Azure Government Services for partners

New events and webcasts this fall

• Microsoft Azure + AI Conference, December 3-6
• Microsoft Connect 2018, December 4
• Next Gen PPE Training Series
• Driving Compliance with Microsoft Teams
• Building a Microsoft Teams Practice
• What’s new with Windows 10
• Microsoft Security workshop with M365
• Building your Teamwork Practice with Teams and Modern SharePoint Solutions
• Learn the Microsoft Security Story using Microsoft Teams
• Microsoft 365 Features and Value Discovery Workshop
• StepUp Technical
• The Leading Edge

Upcoming US Partner Community calls

• Modern Workplace Partner Community call - Azure AD Privileged Identity Management, November 20, 10 am PT
• US Partner Investment Office Hours, November 21, 11 am PT

Learning news

• Calling All Microsoft 365 Enterprise Administrators: Take Our New Beta Exams MS-100 & MS-101!
• New Azure Role-Based Training and Certification Exam Marketing Assets
• Introducing the Microsoft Professional Program in Cybersecurity for LaaS Partners
• Learning program FAQ Update
• Are You a DevOps Engineer? Take the AZ-400 Beta Exam, and Prove You Know Your Stuff

MPN news

• Calling on our global partners to help drive digital peace
• Why marketing is as important as your product
• Attunix case study
• RackNap case study
• Business runs on trust
• OnePlace Solutions case study
• Build solutions that evolve with your customers

執筆者: Cloud Platform Team

このポストは、2018 年 11 月 14 日に投稿された Cloud Platform Release Announcements for November 14, 2018 の翻訳です。

Azure Virtual Machines (VM) | HPC 向けシリーズのプレビュー

HPC ワークロード向け H シリーズ VM のプレビューをリリース

ハイパフォーマンス コンピューティング (HPC) ワークロード向けの 2 つの H シリーズ VM、HB と HC のプレビューをリリースしました。

HB シリーズは、流体動力学、陽的有限要素解析、気象モデリングなど、メモリ帯域幅を重視する HPC アプリケーションに最適化されています。この VM は、AMD EPYC 7551 プロセッサ コアが 60 基、CPU コアあたりの RAM が 4 GB で、ハイパースレッディングを使用せず、マネージド ディスクを 4 台まで接続できます。AMD EPYC プラットフォームは、260 GB/秒を超えるメモリ帯域幅を特徴としています。

HC シリーズは、陰的有限要素解析、貯留層シミュレーション、計算化学など、高密度計算を重視する HPC アプリケーションに最適化されています。この VM は、Intel Xeon Platinum 8168 プロセッサ コアが 44 基、CPU コアあたりの RAM が 8 GB で、ハイパースレッディングを使用せず、マネージド ディスクを 4 台まで接続できます。Intel Xeon Platinum プラットフォームは、Intel の豊富なソフトウェア ツールのエコシステムをサポートしており、ほとんどのワークロードにおいて全コアでクロック速度 3 GHz を実現します。どちらの VM もプレビュー版をご利用いただけます。

詳細はこちらの Azure ブログ記事をご覧ください。この新しい VM の利用をご希望の場合は、申請フォーム (英語) からサインアップしてください。詳しい価格は、Linux VM または Windows VM のページでご確認いただけます。

Azure Event Hubs | Kafka 用 Event Hubs の一般提供

Apache Kafka 用 Azure Event Hubs をリリース

Apache Kafka 用 Azure Event Hubs は、Azure Event Hubs と Apache Kafka の強力な分散ストリーミング プラットフォームが 1 つになったサービスで、サーバーやネットワークを管理することなく、Kafka の幅広いエコシステム アプリケーションにアクセスできます。Event Hubs は、シンプルで信頼性と拡張性の高いフル マネージド型のリアルタイム データ インジェスト サービスです。分散ストリーミング プラットフォームとして、あらゆるソースからデータを収集して 1 秒間に何百万ものイベントを処理および格納できるため、動的なデータ パイプラインを構築してリアルタイムでビジネス課題に対応できます。Kafka 用 Event Hubs では、Kafka のエンドポイントを利用できるため、簡単な構成変更だけで、Kafka 1.0 以降のプロトコルで実行中のあらゆる Kafka クライアントと Event Hubs との間でイベントを発行、受信することができます。MirrorMaker のような Kafka エコシステム アプリケーションを簡単に利用できると同時に、Capture (Blob または Data Lake ストレージへの自動配信)、自動インフレ (スループットの自動スケールアップ)、geo ディザスター リカバリーといった Event Hubs の機能も活用できます。今回の統合により、オンプレミスからクラウドへデータを容易に送信し、Azure Stream Analytics や Azure Databricks などの Azure ネイティブなサービスで存分に分析できるようになります。

Azure SQL Data Warehouse | 行レベルのセキュリティのサポート

機密データを確実に保護するために、Azure SQL Data Warehouse (SQL DW) で行レベル セキュリティ (RLS) 機能をサポートします。これにより、どのユーザーがテーブル内のどの行にアクセス可能かというセキュリティ ポリシーを設定して、行アクセスを制御できるようになります。しかも、このレベルの細かい制御でもデータ ウェアハウスの再設計は必要ありません。そのため、データと異なる場所に格納されたアプリケーションではなくデータベース層自体にアクセス制限ロジックを配置でき、セキュリティ モデル全体をシンプルにまとめられます。また、行をフィルタリングするためのビューを用意する必要もありません。このエンタープライズ クラスのセキュリティ機能は、追加コストなしですべてのお客様にご利用いただけます。

詳細はこちらの Azure ブログ記事 (英語) をご覧ください。

Azure SQL Data Warehouse | Azure Data Lake Storage Gen2 との統合

Azure SQL Data Warehouse (SQL DW) が Azure Data Lake Storage Gen2 とネイティブに統合されました。これにより、外部テーブルを使用して ABFS から SQL DW へデータをロードできるようになり、Data Lake Storage Gen2 に格納しているデータ レイクを容易に統合できます。

詳細はこちらの Azure ブログ記事 (英語) をご覧ください。

Azure SQL Data Warehouse | メンテナンス スケジュール

Azure SQL Data Warehouse (SQL DW) のメンテナンス スケジュール機能をご利用いただけるようになりました。Azure Service Health の計画的メンテナンスの通知と Resource Health モニター サービスがシームレスに統合されます。これにより、Azure SQL DW サービスの新機能、アップグレード、パッチのロールアウト予定に合わせて、お客様のメンテナンス イベント計画を立てられます。このエンタープライズ クラスのセキュリティ機能は、すべてのお客様に追加コストなしでご利用いただけます。

詳細はこちらの Azure ブログ記事 (英語) をご覧ください。

Azure Functions | 米国政府および中国リージョンでランタイム 2.0 が利用可能に

Azure Government および中国リージョン向けに Azure Functions 2.0 をリリースします。これにより、パフォーマンス向上に加えて、新バージョンのサービス ランタイムに含まれる言語がサポートされるようになります。

詳細はランタイム 2.0 の更新内容をご覧ください。

Azure Functions | IoT Edge での Functions

Azure Functions ランタイム 2.0 を、IoT Edge でご利用いただけるようになりました。開発の際に C# スクリプトではなく Functions の C# プリコンパイル バージョンを使用できます。ローカル開発エクスペリエンスがよりリッチになり、クラウドの Azure Functions のエクスペリエンスに近くなります。

IoT Edge の最新の更新内容をご確認ください。Azure Functions を IoT Edge モジュールとしてデプロイする方法のチュートリアルも役立ちます。

以前デプロイした Azure Functions の既存コードをエッジ モジュールとして再構築する場合は、CSX を C# に移行する方法を参照してください。また、Azure Functions の C# を使用したプログラミング モジュールの詳細は、開発者向けリファレンスをご覧ください。

Azure Functions | 米国政府バージニア リージョンで従量課金プランが利用可能に

米国政府バージニア リージョンで Azure Functions の従量課金プランをご利用いただけるようになりました。従量課金プランは実行回数ごとに課金される方法で、アプリの負荷に基づいて動的にリソースが割り当てられます。一方 App Service プランでは、予測可能なコストとスケールの範囲で事前に定義した容量が割り当てられます。

価格モデルの違いはこちらをご確認ください。

Azure Virtual Machines | NDv2 のプレビュー

AI や HPC 向け GPU 対応 NDv2 Azure VM をリリース

Linux VM の価格 | Windows VM の価格 | Azure Virtual Machines の概要

NDv2 シリーズ VM のプレビュー提供を開始しました。このシリーズは、機械学習やハイパフォーマンス コンピューティングのワークロードの処理速度を向上させることを目的としています。

NVLink で相互接続された NVIDIA Tesla V100 GPU を 8 基、Intel Skylake コアを 40 個、システム メモリを 672 GiB 搭載しています。CPU クラスは前回からアップグレードされ、システム メモリも大幅に増設されています。

NDv2 VM はプレビュー版をご利用いただけます。リージョン別の提供状況については、こちらの Azure ブログ記事をご覧ください。プレビュー期間中のご利用を希望される場合は、申請フォーム (英語) からサインアップしてください。

Azure Cognitive Services | コンテナー サポートのプレビュー

Azure Cognitive Services の一部、Computer Vision、Face、Text Analytics で、コンテナーのサポート (プレビュー) をリリースしました。これにより、コンテナーを活用して Azure Cognitive Services をオンプレミスやエッジにデプロイできるようになります。Cognitive Services コンテナーでは、Azure と同じインテリジェント API を使用できるうえ、Docker コンテナー (英語) ならではの柔軟性も活かせます。クラウドにデータを送信できない環境で Cognitive Services のテクノロジを利用したい場合には、Cognitive Services でデータを完全に制御する必要があります。Cognitive Services コンテナーを活用すれば、ソリューションにデプロイ中のモデルのバージョン管理やアップデートが柔軟に行えるほか、移植可能なアプリケーション アーキテクチャを作成して、クラウド、オンプレミス、エッジにデプロイすることも可能です。

詳細はこちらのドキュメント (英語) をご覧ください。

Visual Studio 2017 | 最新バージョンのお知らせ

Visual Studio 2017 の最新版をリリースしました。今回より、以下の機能 (およびその他の新機能) を無料でご利用いただけます。

マイクロソフトのサポート ポリシーに基づき、この Visual Studio 2017 の最終更新プログラムは、「Service Pack」となり、2020 年 1 月 14 日以降はこのバージョンのみがサポートされます。

• インストール
  • Visual Studio のインスタンスと同時にインストールするワークロードとコンポーネントを指定したインストール構成ファイルをインポート、エクスポートできます。
• C++ 開発
  • Visual Studio Enterprise のユーザーは、C++ 向けデバッガーのステップ バック機能を使用できるようになりました。また、Desktop Bridge フレームワーク パッケージを更新し、ARM64 C++ のシナリオをサポートしました。
• UWP 開発
  • ARM64 のサポートを追加し、.NET UWP アプリ (.NET Native) をビルドできるようになったほか、.MSIX パッケージを作成できるようになりました。デザイナーのプラットフォーム限定モードやフォールバック コントロールに関してもエクスペリエンスを改善しました。
• .NET モバイル開発
  • Xcode 10 をサポートし、iOS 12、tvOS 12、watchOS 5 向けのアプリをビルドできるようになりました。また、+ Xamarin Android のビルドのパフォーマンスを改善しました。
• 他の言語
  • F# 開発者向けに、byref の使用に関するいくつかの点を改善しました。Vue CLI のバージョンを最新の0 に更新し、TypeScript プロジェクトでのプロジェクト参照をサポートしました。
• SharePoint 2019 サポート
  • SharePoint 2019 のプロジェクトを作成できるテンプレートを追加しました。既存の SharePoint 2013 および 2016 のプロジェクトは、この新しいテンプレートに移行できます。

詳細は Visual Studio ブログ (英語) やリリース ノートをご覧ください。最新の Visual Studio 2017 は、Visual Studio インストーラーまたは VisualStudio.Microsoft.com から今すぐダウンロードしていただけます。

Bot Framework SDK & Tools 4.1 のリリース

Bot Framework SDK バージョン 4.1 をリリースしました。これには、Bot Framework Emulator、Web Chat V4、C# SDK と JavaScript SDK のバージョン 4.1 が含まれています。今回の更新では、ボット開発のための SDK とツールを定期的にお届けできるようになりました。

Bot Framework SDK & Tools の詳細については、こちら (英語) をご覧ください。

Virtual Assistant ソリューション アクセラレータのプレビュー

会話アシスタント機能には多くの関心が寄せられています。企業では、この機能をブランドに合わせてカスタマイズしたり、顧客ごとにパーソナライズしたりして、さまざまなデバイスやアプリで提供したいと考えています。Virtual Assistant ソリューション アクセラレータを使用すると、独自のアシスタントの開発作業が簡素化され、ユーザーが数分でビルドを開始できるようになります。

こちらのページ (英語) で詳細をご確認のうえ、ぜひお試しください。

Azure Bot Service | プレビューのお知らせ

Azure Bot Service にトランスポート層セキュリティ (TLS) 1.2 の強制適用

2018 年 12 月 4 日より、Azure Bot Service のすべての接続にトランスポート層セキュリティ (TLS) 1.2 を使用することが求められます。
これは、データの安全性を最大限に高めるために必要な措置です。現在、マイクロソフト (英語)、カード業界 (PCI、英語) をはじめとするあらゆるインターネット コミュニティで、脆弱性が狙われている TLS 1.0 や TLS 1.1 からの移行が進められています。
今回の措置は、チャット クライアントまたはボットからの Azure Bot Service サーバーへのすべての接続が対象となります。今のところ、Azure Bot Service からボットへの接続は対象外です。

詳細情報

Azure Bot Service に対する接続のほとんどは、既に TLS 1.2 が使用されています。TLS 1.2 を使用していない一部の接続は、旧式のクライアントや古い OS からのものです。この場合、最新ブラウザーへのアップグレードや OS のパッチ適用によって TLS 1.2 を有効化する必要があります。

ボット側で古いプロトコルによる受信を許可することは当面可能ですが、今後廃止される予定です。そのため、サーバーで TLS 1.2 以降を許可するように設定しておくことをお勧めします。Azure Web Apps または Functions でボットをホストしている場合は、簡単に移行 (英語) できます。Windows Server 2008 (英語) や Windows 7 (Windows Server 2008 R2) などの旧バージョンの Windows でボットをホストしている場合は、パッチをインストールして、最新のプロトコルを有効化する必要があります。TLS 1.2 は、Windows Vista 以前ではサポートされません。

以下のクライアントでは TLS 1.2 は使用できません。これらをお使いの場合は、クライアントをアップデートしてください。また、サービスを利用できなくなることがないように、顧客にも同様の対応を推奨してください。

• Android 4.3 以前
• Firefox 5.0 以前
• Windows 7 以前のバージョン上の Internet Explorer 8 ～ 10
• Windows Phone 8.0 上の Internet Explorer 10
• Safari 6.0.4/OS X10.8.4 以前

参考資料

• TLS 1.0 の問題の解決方法 (英語)
• マイクロソフトにおける TLS 1.2 のサポート (英語)
• App Service や Functions でホストしているアプリで使用する TLS のバージョンが設定可能に (英語)
• Windows Server 2008 への TLS 1.2 サポートの追加 (英語)
• Windows の WinHTTP における既定の安全なプロトコルとして TLS 1.1 および TLS 1.2 を有効化する更新プログラム
• Windows Server 2008 SP2、Windows Embedded POSReady 2009、および Windows Embedded Standard 2009 に TLS 1.1 および TLS 1.2 のサポートを追加する更新プログラム

Azure Cognitive Services | 新機能

Azure Cognitive Services の新機能をリリースしました。

Custom Vision Service のロゴ検出

Custom Vision Service でロゴ検出をサポートしました。これにより、専門の知識がなくても独自のロゴ検出ツールを作成できるようになります。

翻訳品質の向上

Microsoft Translator API に、中国語と英語間、ドイツ語と英語間の新しい翻訳システムが導入され、翻訳品質が大幅に向上し、応用できるシナリオの幅が広がりました。これらの言語の翻訳品質向上には、人間のレベルに達したマイクロソフトの中英翻訳技術 (英語) が活かされています。

SQL Server 2014 Service Pack 3 | 一般提供

SQL Server 2014 Service Pack 3 の一般提供を開始しました。お客様や SQL コミュニティからのフィードバックに基づいて、パフォーマンス、スケーラビリティ、診断に関する 25 以上の機能を強化しています。この SP3 を適用するだけで、最新のハードウェア設計における SQL Server 2014 のパフォーマンスとスケーラビリティが向上します。今回のリリースは、SQL 製品チームによる継続的な価値提供への取り組みの成果でもあります。詳細は関連のブログ記事やサポート情報をご覧ください。

こんにちは。Azure サポートの宇田です。
今回は、ExpressRoute を複数ご契約いただく場合の留意点や、冗長構成の考慮点についてご説明します。

• Part1: ExpressRoute を導入する前に
• Part2: ExpressRoute のルーティング制御について
• Part3: ExpressRoute の導入手順について
• Part4: ExpressRoute の冗長構成について
• Part5: ExpressRoute のトラブルシューティング方法

単一の ExpressRoute 回線を契約した場合

まず初めに、シンプルに 1 回線だけ契約された場合からご説明します。

ExpressRoute を東京でご契約いただいた場合、既定 (Premium Add-on なし) の状態で、以下の図のように東日本・西日本リージョンの仮想ネットワークに接続が可能です。

ExpressRoute 回線を複数契約された場合

次に、ExpressRoute 回線を東京で 2 回線ご契約される場合を考えてみます。
(システム毎に回線を分離したい場合や、キャリア冗長としたい場合など)

以下のドキュメントに記載がある通り、1 つの仮想ネットワークには最大で 4 つまで ExpressRoute 回線を接続出来ますが、いずれも別の場所 (東京・大阪など) でご契約いただいた ExpressRoute が必要になります。つまり、2 回線ともに東京でご契約いただいた場合、1 つの仮想ネットワークに東京の 2 つの ExpressRoute 回線を接続していただくことができません。

• 1 つの仮想ネットワークを複数の ExpressRoute 回線に接続できますか。
  https://docs.microsoft.com/ja-jp/azure/expressroute/expressroute-faqs#can-i-have-one-virtual-network-connected-to-more-than-one-expressroute-circuit

はい。 1 つの仮想ネットワークを最大 4 つの ExpressRoute 回線に接続できます。
これらは、4 つの異なる ExpressRoute の場所で注文する必要があります。

大規模災害時などの疎通性の考え方

最後に、災害時の DR を考慮する際の留意点についてご説明します。

まず大前提として、Azure のリージョン (東日本・西日本リージョン) と、ExpressRoute の接続場所 (東京・大阪) は、必ずしも同一のデータセンター内とは限りません。(海外ですと、Azure リージョンが存在しない地域でも ExpressRoute の接続場所が用意されている場合がございます。)

• 地理的リージョン内の Azure リージョンと ExpressRoute の場所の対応
  https://docs.microsoft.com/ja-jp/azure/expressroute/expressroute-locations#azure-regions-to-expressroute-locations-within-a-geopolitical-region

これを踏まえ、大規模災害時などに東京の ExpressRoute 回線経由で西日本リージョンの仮想ネットワークへ接続出来るのかという点ですが、どこが被災したかによって状況が異なりますので、以下にそれぞれご紹介できればと思います。

Azure のデータセンターが被災した場合

データセンター側が被災したものの、ExpressRoute の接続場所 (MSEE) は無事という場合は、以下の図のように ExpressRoute 経由で西日本リージョンへ接続が可能と想定されます。

ExpressRoute の接続場所 (MSEE) が被災した場合

一方で、ExpressRoute の接続場所が被災した場合は、以下の図のように MSEE 経由で西日本リージョンへ通信を行うことができなくなることが想定されます。

ExpressRoute 回線自体も DR 対策を検討される場合

上記のような大規模災害時を想定し、ExpressRoute 回線の冗長化を検討される場合は、東京・大阪で 1 回線ずつご契約いただき、東日本・西日本リージョンの仮想ネットワークに対してメッシュでの接続をご検討ください。

この時、Azure とオンプレミス間は 2 つの経路で接続できる状態になりますが、既定の状態では等コストですので、アクティブ / アクティブな状態となり、両経路とも利用されることになります。

意図的に一方の経路を優先させたい (通常時は東京側を利用したい) という場合には、Azure からオンプレミスと、オンプレミスから Azure の双方向で、以下のように経路制御をいただければと思います。

・Azure -> オンプレミス方向の経路制御

Azure としては、プロバイダー様の PE ルーターから広報される BGP の経路情報に基づいてルーティングを行っています。
意図的に東京側を優先してオンプレミスへルーティングしたいという場合は、AS Path プリペンドでの経路制御をご検討ください。
具体的には、大阪の PE ルーターから広報する経路情報に AS Path を追加して、遠回りの経路と見せかけることで制御できますので、プロバイダー様 (L2 プロバイダー様の場合は、PE ルーターの管理者様) までご相談をいただければと思います。

・オンプレミス -> Azure 方向の経路制御

オンプレミス側で、東京・大阪のどちらの ExpressRoute 回線へルーティングするかは、お客様のネットワーク構成に依存します。
Azure 側からは制御できませんので、お手数ですがオンプレミス側のネットワーク管理者様や、プロバイダー様までご相談ください。

以上、ご参考になりましたら幸いです。

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

こんにちは、Teamsチームの吉野です。
本日はチャネルにメールで投稿する際に安全度を増す（？）ための設定を案内します。

チャネルを右クリックすると以下のようにメールアドレスを取得できます。

このメールアドレスはチームのメンバー以外でも送信することが可能です。
システムからのメールなど便利な面はあるのですがセキュリティを気にされることもあるかと思います。

詳細設定をクリックすると制限することが可能になります。

チームのメンバーやドメインを限定することにより、

なお、管理センターからは管理者がメール機能そのものの禁止やドメインの許可設定が行えます。
（各チャネルの設定よりも優先されます）

Hello All,

I will assume that you have set the permissions on your Site Collections correctly, but if that still leaves the security team uncomfortable we can always look to perform several other steps using Conditional Access and SharePoint admin.

The Microsoft team approaches this by classifying 3 types of sites Baseline, Sensitive, and Highly regulated each one escalating from the previous (Well actually there is a 4th which is public with minimal security). Here are those levels

And of course you need to setup the Site-Scoped limited access policies for SharePoint Online and OneDrive for Business. These policies utilize the device-based policies for SharePoint and OneDrive (Released Mar 2017) to help administrators ensure data on corporate resources is not leaked onto unmanaged devices such as non-domain joined or non-compliant devices. This is done by limiting access to content to the browser, preventing files from being taken offline or synchronized with OneDrive on unmanaged devices.

There are two things you need to do to configure these Site level policies

1. Tenant-level device-based policy must be configured to Full Access
2. Run the following script for each Site Collection you want to enforce the policy on
Connect-SPOService -Url
$Site = Get-SPOSite -Identity
Set-SPOSite -Identity $Site.Url -ConditionalAccessPolicy AllowLimitedAccess

You can also use the following values for the parameter 'ConditionalAccessPolicy': AllowFullAccess, AllowLimitedAccess, BlockAccess

While it might seem counterintuitive to allow external sharing, this approach provides more control over file sharing compared to sending files in email. SharePoint Online and Outlook work together to provide secure collaboration on files.

Now if a user connects to a Site Collection via an unmanaged/non-compliant device they will see a banner like this:

Note:

If access is limited or blocked to unmanaged devices, this impacts external users too, though you can can exempt them from this policy by running the following cmdlet:

Set-SPOTenant -ApplyAppEnforcedRestrictionsToAdHocRecipients $false

If you cannot see the Device Security Tab you need to enable MDM (See above for what this means) follow this article to enable and go thru settings

Pax

Some new links:

Docs BC (DEV): https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/

Docs BC (APP): https://docs.microsoft.com/en-us/dynamics365/business-central/

D365 BC for Partners (Blog): https://community.dynamics.com/business/b/businesscentraldevitpro/

D365 BC for Partners (Yammer): https://www.yammer.com/dynamicsnavdev#/home

BC DEV tools issues: https://github.com/Microsoft/AL/issues/

BC Event issues: https://github.com/Microsoft/ALAppExtensions/issues/

BC Ideas: https://experience.dynamics.com/ideas/list/?forum=e288ef32-82ed-e611-8101-5065f38b21f1

Create common environment/tenant: https://demos.microsoft.com/environments

Create trial BC under common account: https://trials.dynamics.com/Dynamics365/Signup/

P.S.

“Cumulative Update 01 for Microsoft Dynamics 365 Business Central has been released”

Hey… this news on the new site.

D365 BC for Partners (Blog): https://community.dynamics.com/business/b/businesscentraldevitpro/

Had some questions come up from the community to check the Log Analytics agent version.

Depending on how you are setup, the SCOM Integration makes this easy with Holman's blog for the agent management pack.

If you have admin right in Operations Manager console then you can check this directly from SCOM server:

If you are an admin in SCOM, you can check from MS

$Server = "DC01.yourlabnamehere.net"
(Get-SCOMAgent -Name $ServerName).Version

Alternatively, from server registry:

(Get-ItemProperty "HKLM:SOFTWAREMicrosoftMicrosoft Operations Manager3.0setup")

# Just the Agent version variable

(Get-ItemProperty "HKLM:SOFTWAREMicrosoftMicrosoft Operations Manager3.0setup").AgentVersion

Log Analytics

Kusto query

// Servers and Versions

Heartbeat
| project Computer,Version

// Specific version

Heartbeat
| where Version == "8.0.10918.0"
| project Computer,Version

// Summarize by Version

Heartbeat
| summarize by Version

If you're visual

From the Portal > Log Analytics > workspace > Workspace Summary > Agent Health

Scroll right to agent version

Monitor

Monitor > Overview > Agent Health Assessment

Scroll right to agent version

The time has come for me to change blog platforms.  I have tried to clone over many of my more popular or relevant posts to keep for future reference.  I don't plan to do any more blog posting on this site.  If you don't see your favorite but want to make sure it doesn't get lost, leave a comment on my new site.  Speaking of which, here is where you can find any of my future ConfigMgr/SCCM blogs:

https://learnconfigmgrintune.wordpress.com/

Summary

SharePoint 2019 delivers an updated modern look and feel for lists and libraries and enabled by default.

Modern:                                                                                                                                                              Classic:

However, if the classic experience is required for your farm, the modern experience can be disabled.

How to modify the default experience for list and libraries as a user

From the user perspective, switching from modern and classic is a simple click.

For example, users will see all lists and libraries. Once in classic mode, you will then see to return to modern mode.

How to modify the default experience for list and libraries as an Admin

Admins can manage the default experience for list and libraries at the site collection, web or library level.

To change disable / re-enable the modern user experience at the site collection level

#Site Collection Level
Add-PSSnapin microsoft.sharepoint.powershell -ea 0
$site = Get-SPSite http://spwfe

#Disable modern Lists and libraies at the Site Collection Level
$featureguid = new-object System.Guid "E3540C7D-6BEA-403C-A224-1A12EAFEE4C4"
$site.Features.Add($featureguid, $true)

#Re-enable the moden expirence at the site collection Level.
$featureguid = new-object System.Guid "E3540C7D-6BEA-403C-A224-1A12EAFEE4C4"
$site.Features.Remove($featureguid, $true)

To change disable / re-enable the modern user experience at the web level

#Web Level
Add-PSSnapin microsoft.sharepoint.powershell -ea 0
$site = Get-SPWeb http://spwfe

#Disable modern Lists and libraies at the Web Level.
$featureguid = new-object System.Guid "52E14B6F-B1BB-4969-B89B-C4FAA56745EF"
$site.Features.Add($featureguid, $true)

#Re-enable the moden expirence at the Web Level
$featureguid = new-object System.Guid "52E14B6F-B1BB-4969-B89B-C4FAA56745EF"
$site.Features.Remove($featureguid, $true)

To change disable / re-enable the modern user experience at the library level

Add-PSSnapin microsoft.sharepoint.powershell -ea 0
$web = Get-SPWeb http://spwfe
$list = $web.Lists["Documents"]

#Classic setting
$list.ListExperienceOptions = "ClassicExperience"
$list.Update()

#Modern setting
$list.ListExperienceOptions = "NewExperience"
$list.Update()

#User Default
$list.ListExperienceOptions = "Auto"
$list.Update()

More Information

I hope you found this tip useful, and if you are interested in the SPO equivalent, see the following articles.

Switch the default experience for lists or document libraries from new or classic

Change the default list and library experience

Check out the attached list of technical webinars for next week, to help you build your technical depth. Through these live, instructor-led webinars, you will receive interactive guidance with real-time Q&A capabilities - all at no cost to Microsoft Partner Network members!

Technical-Webinars_11-26-thru-11-30

To find additional dates and times for the webinars and consultations above, as well as the full suite of webinars and consultations available, visit aka.ms/TechnicalJourney.

As Intune Service Administrators at Microsoft, we often get a lot of inactive and stale Intune records due to the nature of test device enrollments. We want to keep our Intune environment and reports current by cleaning up these stale devices. With Intune device cleanup, we have the ability to configure the automatic cleanup rule which cleans up devices that are inactive, orphaned, or obsolete and have not checked in recently. The rule allows us to choose between 90 and 270 days to automatically remove inactive/obsolete device records from Intune. 

To get started, go to the Devices blade in Intune portal and navigate to "Device cleanup rules". Here you will be able to enable the cleanup rule to delete devices that haven't checked in for {X} days; the minimum is 90 days and the maximum is 270 days. At Microsoft, we have configured it as 90 days as we would like to keep device count as realistic as possible with the amount of test devices that get enrolled. Once this rule is enabled, Intune will automatically remove devices that haven’t checked in for the number of days you set. 

What happens behind the scene for Device Cleanup rules? 

After the Intune Service Admins enable the rule, Intune services run a background job every few hours to remove all applicable devices from the Intune portal and they won't show up in any Intune blade or device list anymore. This device removal is only applicable to Intune portal and devices do not get removed from Azure AD. Azure AD tenant admin has  to perform the device cleanup task in Azure AD portal to remove the stale record permanently. 

What device types get affected from this device cleanup? 

All enrolled devices including MDM, EAS/MDM, MDM/SCCM (Co Management) devices will be removed. This includes registered devices and also approval pending devices.

Does this device cleanup rule perform device wipe or retire? 

No, this automatic rule only removes the devices from the Intune portal which are orphaned devices. It means these device are no longer checking in with the service for the last x days chosen by the admin before getting removed from the Intune portal. 

Is it possible to have devices removed by  the device cleanup rule to come back in some scenarios?

Yes it is possible that some devices can come back in the Intune portal as there is service criteria to auto-recover the cleaned up devices if they check-in to the Intune service recently. The purpose of this behavior is to recover devices owned by somebody that took a long leave (e.g. Extended vacation, sabbatical, maternity leaves). The grace period for the device to show up in the Intune portal again is before the device cert expires, which is 180 days.  If you do not want devices to be able to check back in, consider filtering for stale devices and doing a bulk delete from the All devices view instead.

Microsoft is pleased to announce the final release of the security configuration baseline settings for Windows 10 October 2018 Update (a.k.a., version 1809, “Redstone 5” or “RS5”), and for Windows Server 2019.

For now, download the content here: Windows-10-1809-Security-Baseline-FINAL. It will be posted to the Security Compliance Toolkit download site very soon.

The downloadable attachment to this blog post includes importable GPOs, a PowerShell script for applying the GPOs to local policy, custom ADMX files for Group Policy settings, documentation in spreadsheet form and as a set of Policy Analyzer files. In this release, we have changed the documentation layout in a few ways:

• MS Security Baseline Windows 10 v1809 and Server 2019.xlsx – multi-tabbed workbook listing all Group Policy settings that ship in-box with Windows 10 v1809 or Windows Server 2019. Columns for “Windows 10 v1809,” “WS2019 Member Server,” and “WS2019 DC” show the recommended settings for those three scenarios. A small number of cells are color-coded to indicate that the settings should not be applied to systems that are not joined to an Active Directory domain. Cells in the “WS2019 DC” columns are also highlighted when they differ from the corresponding cells in the “WS2019 Member Server” column. Another change from past spreadsheets is that we have combined tabs that used to be separate. Specifically, we are no longer breaking out Internet Explorer and Windows Defender AV settings into separate tabs, nor the settings for LAPS, MS Security Guide, and MSS (Legacy). All these settings are now in the Computer and User tabs.
• A set of Policy Analyzer files:
  • MSFT-Win10-v1809-RS5-WS2019-FINAL.PolicyRules – a Policy Analyzer file representing all the GPOs in the combined Windows 10 and Server 2019 baselines.
  • MSFT-Win10-v1809-RS5-FINAL.PolicyRules – a Policy Analyzer file representing the GPOs intended to be applied to Windows 10 v1809.
  • MSFT-WS2019-MemberServer-FINAL.PolicyRules – a Policy Analyzer file representing the GPOs intended to be applied to Windows Server 2019, Member Server.
  • MSFT-WS2019-DomainController-FINAL.PolicyRules – a Policy Analyzer file representing the GPOs intended to be applied to Windows Server 2019, Domain Controller.
• BaselineDiffs-to-v1809-RS5-FINAL.xlsx – This Policy Analyzer-generated workbook lists the differences in Microsoft security configuration baselines between the new baselines and the corresponding previous baselines. The Windows 10 v1809 settings are compared against those for Windows 10 v1803, and the Windows Server 2019 baselines are compared against those for Windows Server 2016.
• Windows 10 1803 to 1809 New Settings.xlsx – Lists all the settings that are available in Windows 10 v1809 that were added since Windows 10 v1803. (We used to highlight these settings in the big all-settings spreadsheets.)
• Server 2016 to 2019 New Settings.xlsx – Lists all the settings that are available in Windows Server 2019 that were added since Windows Server 2016. (We used to highlight these settings in the big all-settings spreadsheets.)

Highlights of the differences from past baselines, which are listed in BaselineDiffs-to-v1809-RS5-FINAL.xlsx:

• Added two new Attack Surface Reduction rules in Windows Defender Exploit Guard: “Block Office communication applications from creating child processes” (which includes Outlook), and “Block Adobe Reader from creating child processes.” Note that these were added since the draft release of these baselines.
• Since the draft baseline, we removed the “Turn off printing over HTTP” setting in “Computer ConfigurationAdministrative TemplatesSystemInternet Communication ManagementInternet Communication settings.” This setting had been in our baselines at least as far back as Windows XP because of the mistaken belief that it distinguished between HTTP and HTTPS. Enabling this setting also disables printing over HTTPS, which breaks legitimate and necessary functionality for no security benefit.
• The MS Security Guide custom setting protecting against potentially unwanted applications (PUA) has been deprecated, and is now implemented with a new setting under Computer Configuration...Windows Defender Antivirus.
• We have enabled the “Encryption Oracle Remediation” setting we had considered for v1803. At the time we were concerned that enabling the newly-introduced setting would break too many not-yet-patched systems. We assume that systems have since been brought up to date. (You can read information about the setting hereand here.)
• Changes to Virtualization-Based Security settings (used by Credential Guard and Code Integrity):
  • “Platform Security Level” changed from “Secure Boot and DMA Protection” to “Secure Boot.” If system hardware doesn’t support DMA protection, selecting “Secure Boot and DMA Protection” prevents Credential Guard from operating. If you can affirm that your systems support the DMA protection feature, choose the stronger option. We have opted for “Secure Boot” (only) in the baseline to reduce the likelihood that Credential Guard fails to run.
  • Enabled the new System Guard Secure Launch setting which will enable Secure Launch on new capable hardware. Secure Launch changes the way windows boots to use Intel Trusted Execution Technology (TXT) and Runtime BIOS Resilience features to prevent firmware exploits from being able to impact the security of the Windows Virtualization Based Security environment.
  • Disabled the “Require UEFI Memory Attributes Table” option. This is a change from the draft release, and is intended to increase compatibility.
  • Removed Credential Guard from the Domain Controller baseline, while retaining the rest of the VBS settings. This is implemented in a new DC-only GPO named “MSFT Windows Server 2019 - Domain Controller Virtualization Based Security.” Note that this is a change from the draft baseline in which we had removed all VBS settings from the DC baseline. (Credential Guard is not useful on domain controllers and is not supported there.)
• Enabled the new Kernel DMA Protection feature described here. The “External device enumeration” policy controls whether to enumerate external devices that are not compatible with DMA-remapping. Devices that are compatible with DMA-remapping are always enumerated.
• Removed the BitLocker setting, “Allow Secure Boot for integrity validation,” as it merely enforced a default that was unlikely to be modified even by a misguided administrator.
• Removed the BitLocker setting, “Configure minimum PIN length for startup,” as new hardware features reduce the need for a startup PIN, and the setting increased Windows’ minimum by only one character.
• Since the draft release, we removed “Prevent users from modifying settings” from “Computer ConfigurationAdministrative TemplatesWindows ComponentsWindows SecurityApp and browser protection,” as it merely enforced a default that non-admins could not override.
• Enabled the new Microsoft Edge setting to prevent users from bypassing certificate error messages, bringing Edge in line with a similar setting for Internet Explorer.
• Removed the block against handling PKU2U authentication requests, as the feature is increasingly necessary.
• Removed the configuration of the “Create symbolic links” user rights assignment, as it merely enforced a default, was unlikely to be modified by a misguided administrator or for malicious purposes, and needs to be changed to a different value when Hyper-V is enabled.
• Removed the deny-logon restrictions against the Guests group as unnecessary: by default, the Guest account is the only member of the Guests group, and the Guest account is disabled. Only an administrator can enable the Guest account or add members to the Guests group.
• Removed the disabling of the xbgm (“Xbox Game Monitoring”) service, as it is not present in Windows 10 v1809. (By the way, consumer services such as the Xbox services have been removed from Windows Server 2019 with Desktop Experience!)
• Created and enabled a new custom MS Security Guide setting for the domain controller baseline, “Extended Protection for LDAP Authentication (Domain Controllers only),” which configures the LdapEnforceChannelBinding registry value described here.
• The Server 2019 baselines pick up all the changes accumulated in the four Windows 10 releases since Windows Server 2016.

We received and have been evaluating recommendations for more extensive changes to the baselines that we are continuing to evaluate for future releases.

We have replaced the collection of .cmd batch files for applying the baselines to local policy with a single PowerShell script that takes one of these five command-line switches to indicate which baseline you want to apply:

.BaselineLocalInstall.ps1 -Win10DomainJoined      - for Windows 10 v1809, domain-joined

.BaselineLocalInstall.ps1 -Win10NonDomainJoined   - for Windows 10 v1809, non-domain-joined

.BaselineLocalInstall.ps1 -WS2019Member           - for Windows Server 2019, domain-joined

.BaselineLocalInstall.ps1 -WS2019NonDomainJoined  - for Windows Server 2019, non-domain-joined

.BaselineLocalInstall.ps1 -WS2019DomainController - for Windows Server 2019, domain controller

A couple of important notes about using the BaselineLocalInstall.ps1 script:

• PowerShell execution policy must be configured to allow script execution. You can configure this with a command line such as the following:
  Set-ExecutionPolicy RemoteSigned
• exe must be in the Tools subdirectory or somewhere in the Path. LGPO.exe is part of the Security Compliance Toolkit and can be downloaded from this URL:
  https://www.microsoft.com/download/details.aspx?id=55319

Windows 10 v1809 has greatly expanded its manageability using Mobile Device Management (MDM). The Intune team is preparing documentation about the Microsoft Windows MDM security baseline and how to use Intune to implement the baseline, and will publish it very soon. We will post information to this blog when that happens.

以下当てはまるものありませんか？

• バックアップで痛い目に合ってる方
• バックアップシステムの更改をご検討の方
• データ保護対策でお悩みの方
• バックアップやアーカイブ、ストレージ関連でお悩みの方
• クラウドバックアップに興味をお持ちの方
• Windows/SQL Server のEOSを控えていらっしゃる方

上記一つでも当てはまったそこのあなた！

ハイブリッド・クラウド時代の次世代型データ保護製品として、
シンプル・低コスト・短時間で導入/運用可能なRubrikソリューションを本セミナーでご紹介させてください。

［概要］
■日程：2018/12/5 (水) 14:30~17:00（14:15 受付開始）
■場所：マイクロソフト 品川グランドセントラルタワー 30 階　30C-13
■参加：無料（※同業者様のご参加をお断りさせて頂く場合があります。あらかじめご了承ください。）
■定員：20名様

株式会社コミュニティネットワークセンター様の事例登壇あり。
（質疑応答、個別相談会）

［Agenda］
■14:30-15:10　マイクロソフトのクラウドサービス「Azure」 IaaS最前線
クラウドの利用やクラウドへの移行を検討されている方を対象に、マイクロソフトのクラウドサービスであ
る「Azure」で何ができるのか、どのようなメリットがあるのか、何が安心なのか、オンプレと比較して何
が優れているのかを最新情報を含めて解説します。
日本マイクロソフト株式会社
エバンジェリスト
田中達彦

■15:10-15:40　ついに来た!「ルーブリック」が変えるクラウド時代のデータ保護
これまでのシステム毎に構築されてきたバックアップやDRでは、爆発的に増えるデータへの対応やクラ
ウドの活用、そしてSDDCなど新たなテクノロジーへの対応に限界を感じていないでしょうか？データの
扱いはどうあるべきなのでしょう？ 今世界中で大きく注目され、遂に日本へ本格参入した新たな
データ保護ソリューション「ルーブリック」を是非ご確認ください。
ルーブリック・ジャパン株式会社
セールス・エンジニア
吉田 幸春

（休憩）

■15:50-16:20　ルーブリック製品デモ
誰でも簡単にできるルーブリックを使ったバックアップ・リストアとクラウドの活用についてご紹介し
ます。
ルーブリック・ジャパン株式会社
セールス・エンジニア
藤田達也

■16:20-16:50　お客様導入事例登壇
実際にご利用いただいているお客様に事例のご登壇をいただきます。今回は株式会社コミュニティネットワークセンター様にお話いただきます。
株式会社 コミュニティ ネットワークセンター
技術本部 サーバグループ
ニコライ ボヤジエフ 氏

▼本セミナーの参加登録はこちら

Following on from my earlier post https://blogs.technet.microsoft.com/jeremyknight/2018/10/01/introducing-the-exchange-online-fiddler-extension/ we have now made significant improvements to the extension and have just made version 1.0.50 available.

Improvements in this new version include:

• Performance troubleshooting enhancements to the inspector tab. -- See how long the Exchange Online server took to respond to requests.
• Updates to the rule set, new scenarios for highlighting / providing information on scenarios we have seen in support cases.
• Expanded out the menu to include more options, making it easier to use.
• Added X-HostIP column. Easier to see local vs. internet IP responding server / device.
• Title of the 'Exchange Online' menu will now show if an update is available.
• Minimal telemetry data collected for usage statistics.

The update is available now at: https://github.com/jprknight/EXOFiddlerExtension/releases.

For any questions see: https://github.com/jprknight/EXOFiddlerExtension/wiki.

For any issues see: https://github.com/jprknight/EXOFiddlerExtension/issues.

Happy troubleshooting!