Descripción de la actualización de seguridad

El martes, 12 de diciembre de 2017, Microsoft publicará nuevas actualizaciones de seguridad que afectan a los siguientes productos de Microsoft:

Descripción de las vulnerabilidades de seguridad

A continuación se proporciona un resumen en el que se muestra el número de vulnerabilidades tratadas en esta versión, desglosado por producto o componente y por impacto.

(1) Es posible que vulnerabilidades que aparecen en varios componentes se representen más de una vez en la tabla.

(2) En el momento de la publicación, las puntuaciones CVE solo estaban disponibles para Windows, Internet Explorer y Microsoft Edge.

Guía de actualizaciones de seguridad

La Guía de actualizaciones de seguridad es nuestro recurso recomendado para obtener información sobre actualizaciones de seguridad. Puede personalizar sus vistas y crear hojas de cálculo del software afectado, así como descargar datos a través de una API de RESTful. Le recordamos que la Guía de actualizaciones de seguridad ya ha sustituido a las páginas web de los boletines de seguridad habituales.

Portal de la Guía de actualizaciones de seguridad:  https://aka.ms/securityupdateguide

Página web de preguntas más frecuentes (P+F) sobre la Guía de actualizaciones de seguridad: https://technet.microsoft.com/es-es/security/mt791750

Detalles de la vulnerabilidad

A continuación, encontrará los resúmenes de algunas de las vulnerabilidades de seguridad de esta versión. Estas vulnerabilidades se han seleccionado entre el conjunto global de vulnerabilidades existentes en la versión por alguno de los motivos siguientes: 1) Hemos recibido consultas relacionadas con la vulnerabilidad; 2) la vulnerabilidad se ha puesto de relieve en la prensa especializada; o 3) la vulnerabilidad puede resultar más perjudicial que otras de la misma versión. Dado que no proporcionamos resúmenes para todas las vulnerabilidades de la versión, debería consultar el contenido de la Guía de actualizaciones de seguridad
para buscar la información que no esté contenida en estos resúmenes.

Nuevos avisos de seguridad

El 12 de diciembre de 2017, Microsoft publicó un nuevo aviso de seguridad. Este es el resumen:

Respecto a la coherencia de la información

Procuramos proporcionarle información precisa a través de contenido estático (este correo) y dinámico (basado en web). El contenido de seguridad de Microsoft publicado en la Web se actualiza con frecuencia para incluir la información más reciente. Si esto provoca incoherencias entre la información de aquí y la información del contenido de seguridad basado en web de Microsoft, la información autorizada es esta última.

Si tiene alguna pregunta respecto a esta alerta, póngase en contacto con su administrador técnico de cuentas (TAM) o director de prestación de servicios (SDM).

Saludos!

Microsoft CSS Security Team

Visão geral da atualização de segurança

Em terça-feira, 12 de dezembro de 2017, a Microsoft lançou novas atualizações de segurança que afetam os seguintes produtos da Microsoft:

Visão geral da vulnerabilidade de segurança

Veja abaixo um resumo mostrando o número de vulnerabilidades solucionadas neste lançamento, discriminadas por produto/componente e por impacto.

(1) Vulnerabilidades que sobrepõem componentes podem ser representadas mais de uma vez na tabela.

(2) No momento do lançamento, as pontuações de CVE só estavam disponíveis para o Windows, o Internet Explorer e o Microsoft Edge.

Guia de Atualizações de Segurança

O Guia de Atualizações de Segurança é nosso recurso recomendado para informações sobre atualizações de segurança. Você pode personalizar suas exibições e criar planilhas de softwares afetados, além de baixar dados por meio de uma API RESTful. Como lembrete, o Guia de Atualizações de Segurança agora substituiu formalmente as páginas de boletins de segurança tradicionais.

Portal do Guia de Atualizações de Segurança:  https://aka.ms/securityupdateguide

Página da Web de perguntas frequentes sobre o Guia de Atualizações de Segurança: https://technet.microsoft.com/pt-br/security/mt791750

Detalhes de vulnerabilidade

Veja a seguir resumos de algumas das vulnerabilidades de segurança neste lançamento. Essas vulnerabilidades específicas foram selecionadas de um conjunto maior de vulnerabilidades no lançamento por um ou mais dos seguintes motivos: 1) Recebemos consultas sobre a vulnerabilidade; 2) a vulnerabilidade pode ter recebido atenção na imprensa especializada; ou 3) a vulnerabilidade tem impacto potencialmente maior do que outras no lançamento. Como não fornecemos resumos de todas as vulnerabilidades presentes do lançamento, você deve examinar o conteúdo no Guia de Atualizações de Segurança
para obter informações não fornecidas nesses resumos.

Novo comunicado de segurança

Em 12 de dezembro de 2017, a Microsoft lançou um novo comunicado de segurança. Veja abaixo um resumo:

Sobre a consistência das informações

Nós nos empenhamos para fornecer a você informações precisas usando conteúdos estáticos (esta mensagem) e dinâmicos (baseados na Web). O conteúdo de segurança da Microsoft postado na Web é atualizado frequentemente para informar sobre novidades. Se isso resultar em uma inconsistência entre as informações descritas aqui e as informações no conteúdo de segurança baseado na Web publicado pela Microsoft, as informações nesse conteúdo publicado prevalecerão.

Em caso de dúvidas sobre este aviso, entre em contato com seu Gerente Técnico de Conta (TAM)/Gerente de Prestação de Serviços (SDM).

Agradecemos sua atenção.

Atenciosamente,

Equipe de Segurança Microsoft CSS

[The blog post below is based on the information collected by Derek Smay and Alexander Peter, two Microsoft Premier Field Engineers located in the US]

Overview

One of the changes in the November 2017 CU for SharePoint 2013 affects the maintenance of the [dbo].[TimerJobHistory] table in the SharePoint configuration database, which can experience significant growth if it is not trimmed on a regular schedule.

Historically SharePoint 2013 preserved the timerjob history for all timerjobs which ran in the last 7 days. Starting with November 2017 CU for SharePoint 2013 (build 15.0.4981.1002), the maintenance of the [dbo].[TimerJobHistory] table has been updated in a way that it will never keep more than 10,000 job records.

To maintain the [dbo].[TimerJobHistory] table SharePoint only relied on the Delete Job History timer job, which is responsible to purge records older than 7 days. The default schedule is to run once a day but it is possible to change the schedule by updating the frequency in the Central Administration Site. The Delete Job History timer job, invokes the [dbo].[proc_DeleteOldTimerJobHistory] stored procedure which does the actual work.  If this timer job is not enabled or does not complete successfully, the [dbo].[TimerJobHistory] table can grow to hundreds of millions of records and hundreds of Gigabytes, which can impact performance and availability.

With November 2017 CU, an additional stored procedure, [dbo].[proc_DeleteOldTimerJobHistoryByRows], was added, which limits the number of rows in the [dbo].[TimerJobHistory] table table to 10,000 records. Be aware that both of these stored procedures actually maintain three different tables: [dbo].[TimerJobHistory], [dbo].[TimerScheduledJobs] and [dbo].[TimerRunningJobs]. Of these three, the largest table is [dbo].[TimerJobHistory].

The new stored procedure is not called from any specific timerjob - it is executed as the final step of each single timer job running on your system. That means the maintenance of the [dbo].[TimerJobHistory] does no longer rely the successful execution and on proper schedule of a single timerjob.

This is the logic built into the execution of SharePoint timer jobs after November 2017 CU:

1. Execute the logic of the timer job including the execution of one or more stored procs to complete intended task of the timer job
2. Execute the [dbo].[proc_AddTimerJobHistory] proc to document the execution of the completed timer job to the [dbo].[TimerJobHistory] table
3. Execute the [dbo].[proc_DeleteOldTimerJobHistory] proc to limit the number of records in [dbo].[TimerJobHistory] table to a maximum of 10,000 by removing the oldest records.

This new enhancement eliminates the possibility of the SharePoint configuration database becoming bloated.  By imposing a ceiling on the [dbo].[TimerJobHistory] record count, a number of benefits are recognized such as disk space consumption for the database and its backups, I/O activity, backup impact on network throughput as well as maintenance activities (i.e. CHECKDB, Index, etc).

After running November 2017 CU you should never have to worry about [dbo].[TimerJobHistory] to exceed 10,000 rows. And indeed, this will clearly keep this table in check BUT be careful if there was a problem with the maintenance of your [dbo].[TimerJobHistory] table before installing of November 2017 (or later) CU:

Potential Problem

After installing November 2017 CU each and every timerjob will be responsible to maintain the size of the [dbo].[TimerJobHistory] table. In case that the [dbo].[TimerJobHistory] had several million rows due to the fact that the Delete Job History timer job was disabled or did not work correctly the new maintenance stored procedure will take a very, very long time to complete. As several SharePoint timerjobs will start and end each second that will cause this stored procedure to run in parallel on your SQL server in multiple different SQL sessions.

In this case you can see your SQL server to run on high CPU on each of the available cores till the [dbo].[TimerJobHistory] has been trimmed to the new maximum size.

To prevent this from happening you should ensure that the the Delete Job History job has been running successfully. If you have a SharePoint Config database that is large in size, check the row count and size of [dbo].[TimerJobHistory] table.

SharePoint 2016?

The code change introduced in November 2017 CU for SharePoint 2013 is not included in SharePoint 2016 and is currently not planned to be ported to SharePoint 2016. The reason is that the maintenance of the [dbo].[TimerJobHistory] table in SharePoint 2016 is done differently than in SharePoint 2013. E.g. the Delete Job History job does bulk deletes of 1000 records rows rather than on row after the other and it only keeps records for 3 days compared to 7 days in SharePoint 2013.

But be aware that the proper maintenance of the the [dbo].[TimerJobHistory] table in SharePoint 2016 requires that the Delete Job History job runs successful on a regular basis.

For those of you who were wondering how to fill those public holidays over the next month, you now have the answer. This was previously known as the Windows 10 Deployment and Management Lab Kit, but has been updated  for Windows 10, Version 1709 along with some other updates.

Description

You have a SharePoint 2013 farm on a patch level before April 2017 CU and you plan to keep it running after April 10th, 2018? Start patching!

As communicated earlier, Mainstream support for SharePoint 2013 will end April 10th, 2018. After this date only security fixes will be provided for SharePoint 2013. Regular hotfixes can no longer be requested.

But this is not the only thing to consider after this date: starting with April 10th, 2018 the required patch level to request support for SharePoint 2013 will also change.

Currently all patch levels starting with SharePoint 2013 SP1 are supported. Starting with April 10th, 2018 this will change. In order to request support from Microsoft after April 10th, 2018 the SharePoint server farm has be on a patch level of April 2017 CU or later. A year later, after April 10th, 2019, the SharePoint server farm has be on a patch level of April 2018 CU or later.

This change is outlined in the Updated Product Servicing Policy for SharePoint 2013 published on TechNet.

Below is a table which outlines the required patch level for SharePoint 2013 till end of the extended support phase:

In my last post, I talked about issues you might encounter with Windows AutoPilot.  But what if you still can’t figure it out?  Typically the support and development teams would want more information to see what’s going on.  While I’m sure most IT pros would like to see log files or event logs that show the step-by-step flow, you’ll have to dig a little deeper in order to get something that can be used for a “post-mortem” analysis.  What does that mean?

First, Windows AutoPilot uses Event Tracing for Windows (ETW) to capture events during the AutoPilot process.  Those events need to be enabled and captured so that they can be inspected and interpreted.  How do you do that?  Here are the basic steps:

• On the first OOBE screen where you select a language, press Shift-F10 to open a command prompt.
• Insert a USB key containing the AutoPilot.wprp file (attached to this blog, extract it from the zip file) that defines the events to collect, or map a drive to a network share that contains the file.
• Start the trace using the Windows Performance Recorder (WPR) tool that is built into Windows.  (I talked about that a few years ago in a different context, https://blogs.technet.microsoft.com/mniehaus/2012/09/13/using-the-windows-performance-toolkit/.)  The command line to use:wpr.exe -start <folder location>AutoPilot.wprp
• Exit from the command prompt.
• Finish your AutoPilot process, continuing at least as far as you need to go to reproduce the issue.
• Stop the recording using WPR.EXE, specifying where to put the resulting trace (press Shift-F10 to open another command prompt if you are still in OOBE):
  wpr.exe -stop C:AutoPilot.etl

That part is easy enough.  The next challenge is reading and interpreting that file.  There are some options for doing that:

• Windows Performance Analyzer, provided as part of the ADK.
• Microsoft Network Analyzer (formerly called Network Monitor).
• TRACEFMT.EXE, a command-line utility that can convert the binary ETL file into XML or other formats.

My personal preference is to use Windows Performance Analyzer (WPA).  To get started with this process, let’s look at an ETL file captured from a 100% successful AutoPilot deployment, which I captured using the process described above.  After opening the file in WPA, you will see this view:

Exciting, right?  Well, not until you dig in more.  First, click the triangle before the “System Activity” label to get to this view:

Then double-click on the “Generic Events” block to show the details:

Now we can at least see some data.  Let’s focus in on two specific providers:

• Microsoft.Windows.Shell.CloudExperienceHost.Common.  This is where you’ll find the AutoPilot-generated events.  Some of these are prefixed with “ZTD” (related to the old codename for AutoPilot), while others aren’t prefixed.
• Microsoft.Windows.Shell.CloudDomainJoin.Client.  Events that are part of the initial “is this an AutoPilot deployment,” the AAD join process, and MDM enrollment are from this provider.

So let’s expand those for two “normal” cases.  First, for a device that is configured for AutoPilot:

Compare that to a device that was not enrolled in AutoPilot, but was still joined to Azure AD and automatically enrolled in Intune:

Not surprisingly, there are fewer events for the non-AutoPilot scenario.  But let’s dig into those events a little more, first the “GetCloudAssignedAadServerData” event.  Click on the triangle to the left of the “GetCloudAssignedAadServerData” task name, then select the “win:Stop” opcode (which shows the result).  Scroll to the right to see the data for an AutoPilot-defined machine:

Notice the “wasConfigured” value is “True,” indicating that this device is indeed registered with AutoPilot.  Compare that with a device that isn’t:

And not surprisingly, that shows “False” for the device that isn’t registered.  OK, so back to the registered device.  To see what Azure AD tenant it is registered with, we can check the “LogTenantId” and “LogTenantDomain” tasks.  Expand the “win:Info” opcodes for each and again scroll to the right:

There, you can see the Azure AD tenant ID (a GUID, which you can also find in the Azure Portal in the Azure AD tenant’s properties) and the tenant name (in this case, “contosomn.onmicrosoft.com”).  (Do you see the “IsDevicePersonalized” task name?  That’s for a coming AutoPilot feature that enables a device to be assigned to a user to further customize the “welcome” experience.  That’s not enabled yet, so it always returns “0” today.)

Let’s look at one more item, the “GetCloudAssignedForceStandardUser” task name (with the same routine: expand, select win:Stop, scroll right):

This shows that it’s configured (wasConfigured is “True”) to not force the Azure AD user to be a standard user (forceStandardUser is “False”).

Now lets look at a different trace, this one showing a failure with Azure AD join, error 801C0003 (“Something went wrong”) covered in the previous troubleshooting blog.  We’ll take a different approach this time, just searching for a specific “Event Name” value.  Click on the magnifying glass at the top of the “Generic apps” (right-hand) pane to get a search box, and search for “CDJUIError”.  That will take you directly to the row that has the error, showing you the 801C0003 error code (which you can then look up, see the link at the bottom of the previous blog):

That same approach would work for any Azure AD join issue.  But what about MDM enrollment issues?  Let’s look at another error, the 80180018 error (“Something went wrong”) from the previous post indicating that the device could not be enrolled in MDM.  Guess what?  It shows up in the exact same “CDJUIError” field:

That leaves one key piece of information:  What are the actual profile settings (e.g. skip privacy settings, skip EULA, etc.) that were configured for the device?  Those are reported in a bitmap:

SkipCortanaOptIn = 1,
OobeUserNotLocalAdmin = 2,
SkipExpressSettings = 4,
SkipOemRegistration = 8,
SkipEula = 0x10

The first four were present in Windows 10 1703, while the last one was added in Windows 10 1709.  In my case, I know that I enabled all options except the “OobeUserNotLocalAdmin” one (I wanted the user to have admin rights), so the value should be 1+4+8+16 = 29.  If we look at the trace, we see that is shown in all the “ZTP_GetConfigActivity” tasks (again, expand the entries, expand the win:Stop opcodes, and then one more level with process “Unknown”):

Sure enough, each of those (which are checking individual settings given the complete bitmap value) shows the value 29 in the “Field 2” column.  If you configured different options, the value would be different in that column.

I won’t claim that I’m particularly good with ETW or Windows Performance Analyzer, but hopefully this will give you some hints on what to look for in the traces.  If you pick up any additional tidbits looking at these traces, let me know.  Also, in case you were to open a support case for AutoPilot, don’t be surprised if they ask you to recreate the problem with a trace running, using the steps described at the top of this blog, sending the resulting ETL file so that they can walk through it and look at what happened.

AutoPilot.wprp.zip

Microsoft 365 のご紹介をはじめ、クラウド時代を支える OS 管理やセキュリティの最新情報等、IT 環境の刷新を検討されている企業の IT 担当者様にお役立ていただけるセミナーを各種ご用意しています。 時間を問わず視聴いただけるオンデマンド セミナーも、ぜひご活用ください。

▼ 詳細はこちらから

執筆者: Tobias Ternstrom (Principal Group Program Manager, Database Systems Group)

このポストは、11 月 15 日に投稿された MariaDB, PostgreSQL, and MySQL: more choices on Microsoft Azure の翻訳です。

先日の Microsoft Connect(); では、皆様にオンラインでご参加いただきましたが、その際にはマイクロソフトがどのように開発者の選択肢を充実させ、コミュニティに参加し、共同作業のためのプラットフォームの改良に取り組んでいるかをお伝えすることができました。

そして今日は素晴らしいお知らせがあります。マイクロソフトが Platinum スポンサーとして MariaDB Foundation (英語) に参加することを発表しました。これによりマイクロソフトは、Michael "Monty" Widenius 氏と MariaDB コミュニティとの緊密な協力のもとで、今著しい成長を見せている MariaDB のさらなる改善に取り組めるようになります。数か月前、私はスウェーデンの家族を訪ねたことがきっかけで、Monty とこの話をするようになりました。私たちは最初の時点から、何かおもしろいことを一緒に始めたいと話していました。私も Monty もスウェーデン語を話すので、スウェーデン語で会話することにしたのですが、私の「スウェーデン語のデータベース」が驚くほど貧弱で、呆れてしまいました。しかし、MariaDB とマイクロソフトが力を合わせれば何か大きなことができるだろういう思いは一緒だったのです。

今回、MariaDB が Azure に導入されることになり、とても嬉しく思っています。Azure のフル マネージド サービスとして提供される MariaDB (英語) のプレビューにぜひサインアップしてご利用ください。

私は、マイクロソフトが持つオープンな姿勢と、オンプレミスでも Azure でも関係なくすべてのお客様をサポートできるようにしたいという考え方に誇りを持っています。現在はコミュニティと共に、Azure のデータベース エンジンの変更に関するプル リクエストに取り組んでいます。これが実現すれば、クラウド上のデータベース運用においても、ノート PC やオンプレミスでのアプリケーション開発においても、オープン ソースのオープン性を確保しながら一貫したエクスペリエンスを提供できるようになります。

Azure Database for PostgreSQL と Azure Database for MySQL に Azure Database for MariaDB が加わることにより、開発者の選択肢がさらに広がります。このサービスでは、数分以内に新規インスタンスをプロビジョニングしたり、必要に応じてオンラインでコンピューティング能力をすばやく拡大縮小できます。また、高可用性やセキュリティが組み込まれているため、一般提供時には 99.99% の可用性が SLA で保証されます。さらに Azure では、Cognitive Services API や Bot Framework からアプリに、最新のエクスペリエンスを簡単に追加することができます。Sunil Kamath による Azure Database for PostgreSQL を使用したインテリジェント アプリ構築のデモをご覧ください (英語)。

今年の Azure Database for PostgreSQL と Azure Database for MySQL のプレビュー リリース以降、新しい PostgreSQL 拡張機能やコンピューティング サービス レベルが追加されています。現在、ブラジル、カナダ、インドなど 16 のリージョンで提供中ですが、これに加え 40 を超えるすべての Azure リージョンへの拡大を目指しています。現在、マイクロソフトのマネージド サービス機能は、世界中のお客様に活用されています。

「Azure ポータルから PostgreSQL データベースをセットアップするのはとても簡単でした。その後、エクスポートした既存システムのデータベースを Azure Database for PostgreSQL にインポートしましたが、かかった時間はわずか 2 ～ 3 時間でした」– Eric Spear 氏 (Higher Ed Profiles、最高経営責任者)

「当社のサイトの読み込み時間は非常に短くなったのですが、インフラストラクチャは以前よりも強力でスケーラブルなうえ、コストは 45% も削減できました」– Kevin Lisota 氏 (GeekWire、開発者)

MariaDB を Azure に導入すれば、お客様の選択肢はさらに広がります。皆様にはぜひフィードバックをお送りいただき、今後の開発に役立てさせていただければ幸いです。これからも一緒にさまざまなことを成し遂げていきましょう!

このポストは、12 月 6 日に投稿された Cloud Platform Release Announcements for December 6, 2017

の翻訳です。

この記事では、クラウド プラットフォーム チームが進める一連の新しい更新をまとめてご紹介します。

マイクロソフトでは、ユーザーの皆様によるクラウドの利用をサポートする取り組みを日々行っています。私たちは幅広い製品ポートフォリオを通じてマイクロソフトならではの最新技術、総合的なモバイル ソリューション、開発ツールを提供しており、ユーザーの皆様にはこれらをご活用いただくことで皆様が本来持つ力を余すところなく発揮していただきたいと考えております。今回お届けする最新リリース情報は以下のとおりです。

• Open Service Broker for Azure に関する情報開示
  
• Azure Reserved Virtual Machine Instances の一般提供
  
• Microsoft IoT Central のプレビュー
  
• Azure IoT Hub Device Provisioning Service の一般提供
  
• Azure Virtual Machines – M シリーズの一般提供
  
• N シリーズ Virtual Machines – NCv2 と ND の一般提供
  
• Project Honolulu のプレビュー
  
• R3 on Azure の発表 – パートナーシップを強化
  
• Azure Cosmos DB – 拡張 IP ファイアウォールのプレビュー
  
• Azure Cosmos DB – 強化された Graph API の一般提供
  
• Azure Location Based Services プレビューに関する情報開示
  
• Power BI Desktop – 新機能のリリース
  
• Power BI サービス – 新機能のリリース
  
• Azure SQL Database – 3 つの新機能
  
• Visual Studio 2017 の更新プログラム.
  
• Visual Studio for Mac の更新プログラム.
  

• System Center Configuration Manager – 共同管理機能のリリース

Open Service Broker for Azure に関する情報開示

Azure チームは、Kubernetes Open Source コミュニティと共に、お客様が Kubernetes と Azure でより多くのことを実行できるようにするための機能強化を継続的に行っています。Azure チームが手掛ける 2 つの新しいオープン ソース プロジェクトである Open Service Broker for Azure (OSBA) と Kashti では、コンテナーを活用して、新規または既存のアプリケーションを簡単に刷新、管理できるようにし、デジタル トランスフォーメーションを促進することを目指しています。また、あらゆるランタイムをサポートする Virtual Kubelet のプラグ可能なアーキテクチャと、既存の Kubernetes プリミティブによって、各段に容易な実装を可能にします。

Open Service Broker API (英語) をベースに構築された OSBA は、Kubernetes や Cloud Foundry などのクラウド ネイティブなプラットフォーム上のアプリケーションのバックエンド サービスの標準規格として、Azure Cosmos DB、Azure Database for PostgreSQL、Azure Blob Storage といった主要な Azure サービスに接続することができます。また、新しい Kubernetes Service Catalog と組み合わせることで、SLA で保証される Azure データ サービスを Kubernetes API で管理することもできます。詳しくは、OSBA に関するブログ記事 (英語) や GitHub のページ (英語) をご覧ください。

Kashti は、Brigade パイプライン向けのダッシュボードおよび視覚化ツールです。このプロジェクトは、先日プラハで開催された Open Source Summit で発表されました。Brigade は、複数のタスクをまとめてスクリプト化し、コンテナー内で実行することができる開発者や運用管理者向けの作業効率化ツールです。Kubernetes のサービスとして構築された Kashti は、Helm を通じてインストールすることができます。これを使用すると、ダッシュボード UI で Brigade を拡張し、Brigade のイベントやプロジェクトをブラウザーから簡単に管理、確認できるようになります。詳しくは、Kashti に関するブログ記事 (英語) や Github のページ (英語) をご覧ください。

あらゆるランタイムをサポートする Virtual Kubelet のプラグ可能なアーキテクチャと、既存の Kubernetes プリミティブによって、実装が各段に容易になります。マイクロソフトは 7 月に Azure Container Instances (ACI) の Kubernetes 用コネクタをリリースしました。これは、ACI で Kubernetes を拡張するための実証プロジェクトとして開発されたサーバーレス コンテナー ランタイムです。仮想マシンを管理する必要がなく、秒単位で課金されます。Kubelet は ACI や同等のランタイムを扱っているお客様にご利用いただけます。

マイクロソフトは、Azure のエクスペリエンス向上のために、オープン ソースおよび Kubernetes コミュニティへの投資と貢献を続けてまいります。

Azure Reserved Virtual Machine Instances の一般提供

Azure Reserved Virtual Machine Instances を正式リリース
Azure Reserved Virtual Machine Instances は、仮想マシンのインスタンスを予約制にすることで、Azure の利用料金を大幅に抑えるサービスです。Azure Hybrid Use Benefit を併用した場合には従量課金制と比較して最大 82%、仮想マシン全体でも最大 72% のコストを削減することができます。Azure Reserved Virtual Machine Instances は、ビジネス ニーズの変化に応じて柔軟かつ簡単に変更、キャンセルできるほか、購入手順もわかりやすくなっています。詳しくはこちらのページをご覧ください。

Microsoft IoT Central のプレビュー

Microsoft IoT Central (英語) は、現実世界とデジタル世界をつなぐ製品の構築をサポートするフルマネージド型の IoT 向け SaaS (サービスとしてのソフトウェア) ソリューションです。これにより、IoT 製品の開発、コネクテッド デバイスを通じた新たなインサイトの取得、顧客向けの製品やエクスペリエンスの改良などが実現し、企業の新たなビジネス チャンスにつながります。Microsoft IoT Central では、一般的な IoT プロジェクトの管理に伴う手間、運用コスト、間接費用を削減し、IoT ソリューションの管理を簡素化することができます。

このたび、Microsoft IoT Central のプレビュー提供を開始しました。より細かいカスタマイズや完全な管理が可能な業界トップクラスの PaaS (サービスとしてのプラットフォーム) ソリューションである Azure IoT Suite と並ぶサービスとしてご利用いただけます。Azure IoT Suite、Azure IoT Edge などの幅広い IoT ソリューション ポートフォリオに今回 Microsoft IoT Central が加わったことで、世界中のすべてのお客様のあらゆるニーズにお応えできるようになりました。

利用を開始するには、こちら (英語) からアクセスしてください。

Azure IoT Hub Device Provisioning Service の一般提供

このたび Azure IoT Hub Device Provisioning Service の一般提供が開始され、Azure IoT サービスのサポートが受けられるようになりました。Device Provisioning Service では、Azure IoT Hub へのプロビジョニングをゼロタッチで構成することが可能になり、これまで 1 つずつ処理していた時間のかかるプロセスをクラウドのスケーラビリティで実行できます。Device Provisioning Process はサプライ チェーンの課題を念頭に設計されており、何百万ものデバイスを安全かつスケーラブルにプロビジョニングできるインフラストラクチャを提供します。

一般提供の開始により、プロトコルのサポートも拡大します。IoT Hub がサポートするすべてのプロトコル (HTTP、AMQP、MQTT、WebSocket 上の AMQP、WebSocket 上の MQTT) が Device Provisioning Service の自動デバイス プロビジョニングでもサポートされます。また、デバイスとクライアント サイドの SDK 言語サポートも拡大し、C、C#、Java、Node (サービス SDK のみ、デバイス SDK は近日中)、Python (英語) (デバイス SDK のみ、サービス SDK は近日中) を利用できるようになります。Device Provisioning Service を開始する際は、クイック スタート ガイドをご参照ください。

Device Provisioning Service の技術的な概念については、こちらのドキュメントをご覧ください。

Azure Virtual Machines – M シリーズの一般提供

SAP HANA などの要求水準の高いインメモリ アプリケーションに対応する、メモリ、vCPU、ストレージ、拡張性を増強した M シリーズ Virtual Machines

SAP HANA などの大規模インメモリ ワークロード向けに最適化された、最も高いパフォーマンスを誇る Azure Virtual Machines M シリーズをリリースします。このシリーズでは、要求の高い環境にも対応する大容量の RAM と高性能 vCPU を採用しています。最大 128 の仮想 CPU (vCPU) と 1 ～ 3.8 テビバイト (TiB) の RAM を搭載し (注: 3.8 TiB RAM と 128 vCPU の構成は近日提供予定)、Premium Storage もサポートしているため、大規模なエンタープライズ ワークロードにも対応可能です。また、高速ネットワークのサポートにより、最大 30 Gbps (ギガビット毎秒) の VM 間データ転送が可能なため、リアルタイムでのデータベースの高速レプリケーションや高速バックアップにも最適です。M シリーズのリリースにより、急速に拡大するクラウド環境におけるヘッドルームの問題を解決することができます。まずは、米国東部 2、米国西部 2、西ヨーロッパでの提供を開始します。その他のリージョンでの提供状況は、こちらのページでご確認ください。

N シリーズ Virtual Machines – NCv2 と ND の一般提供

NCv2 シリーズおよび ND シリーズ VM の一般提供を開始します。人気の高い NC シリーズの次世代バージョンである NCv2 シリーズは、NVIDIA Tesla P100 GPU を搭載しています。この最新 GPU を従来の HPC ワークロードに活用することで、パフォーマンスが向上し、貯留層モデリング、DNA 塩基配列の解析、タンパク質解析、モンテ カルロ シミュレーションなどの複雑なシナリオにも対応できるようになります。NCv2 では、既存の NC シリーズの 2 倍以上の計算性能を実現しています。また、NC シリーズと同様に InfiniBand ネットワークを備えており、石油・ガス、自動車、ゲノミクスなどの高速インターコネクトを必要とするワークロードに対応しているほか、スケールアウト機能や、単一インスタンスのパフォーマンスも改善しています。

ND シリーズは、AI やディープ ラーニングのワークロードのニーズに特化した GPU ファミリの新しいラインアップです。NVIDIA Tesla P40 GPU を搭載し、トレーニングや推論において優れたパフォーマンスを誇ります。このインスタンスでは、CNTK、TensorFlow、Caffe などのフレームワークを活用する AI ワークロードや単精度浮動小数点演算において高いパフォーマンスを発揮します。GPU のメモリ サイズ (24 GB) も大幅に増強されているため、より大規模なニューラル ネットワーク モデルにも対応できます。NC シリーズと同様に、2 番目に少ない待機時間、RDMA を利用した高スループットのセカンダリ ネットワーク、InfiniBand との接続性などを備えた構成が利用できるため、多数の GPU を利用した大規模なトレーニング ジョブを実行することができます。

詳しくは、Azure Virtual Machines のページをご覧ください。

Project Honolulu のプレビュー

Project Honolulu は、ローカルにデプロイできるブラウザー ベースの柔軟な管理プラットフォームおよび管理ソリューションです。Windows および Windows Server のトラブルシューティング、構成、メンテナンスを行うためのコア ツールが含まれています。Project Honolulu のプレビューには、新しいコンピューター管理ソリューションでの Windows 10 の管理、対象のマシンに直接接続できるリモート デスクトップ ツール、パフォーマンスの改善やバグ修正などが追加される予定です。Project Honolulu の詳細とダウンロードについては、こちら (英語) をご確認ください。

R3 on Azure の発表 – パートナーシップを強化

先日マイクロソフトは、R3 とのパートナーシップを強化することを発表しました。金融機関やフィンテック業界がブロックチェーン プロジェクトを試験段階から基幹業務へと移行する中、台帳のスタックとインフラストラクチャのシームレスな統合や、ブロックチェーン アプリケーションの開発、管理、最適化を実現できる堅牢なプラットフォームやツールが求められています。拡大するニーズに応えるために、マイクロソフトは R3 との戦略的パートナーシップ (英語) を強化し、Corda や R3Net などの R3 の分散型台帳プラットフォームと Azure の統合を進めていきます。詳しくはこちら (英語) をご覧ください。

Azure Cosmos DB – 拡張 IP ファイアウォールのプレビュー

Azure Cosmos DB のネットワーク セキュリティ – 新しい IP ファイアウォール ルール
現在 Azure Cosmos DB では、特定の IP アドレスにのみデータベースへのアクセスを許可する IP ベースのファイアウォール ルールをサポートしています。このたび、お客様の Azure Cosmos DB アカウントへのアクセスを制限できる新しいファイアウォール ルールをサポートします。この機能の詳細については、こちらのドキュメントをご覧ください。

Azure Cosmos DB – 強化された Graph API の一般提供

Azure Cosmos DB Graph API で PHP のサポートを強化
Azure Cosmos DB Graph API では、Apache Tinkerpop が推奨する Gremlin フレームワーク gremlin-php を新たにサポートします。Azure Cosmos DB Graph API を PHP で使用する際は、新しいクイックスタート ガイド (英語) を参照してください。

Azure Location Based Services プレビューに関する情報開示

Azure Location Based Services のプレビューを発表

料金 | 概要ページ

先日、Azure Location Based Services のプレビューを発表しました。これは、位置情報を活用したアプリやソリューションを開発する開発者、エンタープライズ企業、パートナー企業向けに、一連の地理空間サービス API を提供する新しいサービスです。REST API や JavaScript ベースの一般的な Map Control を使用でき、短期間での製品化が可能になります。

IoT、都市交通、フィールド サービス、物流などのユースケースで重要度が高まっている位置情報や地理空間データに関して、次のような統合機能を Azure で利用できるようになります。

• グローバル マップおよびマップ コントロール
  
• 商用シナリオなどでの包括的な経路選択オプション
  
• ジオコーディングおよび企業検索
  
• 交通状況や事故の動的分析
  

• タイム ゾーン情報
  

詳しくはサービス ページをご覧ください。プレビューをお試しになるには、こちらからサインアップしてください。プレビュー期間中の料金については、料金ページをご確認ください。

Power BI Desktop – 新機能のリリース

Power BI Desktop の新機能や更新をリリースしました。

• Esri Plus サブスクリプション: Power BI と ArcGIS の統合により、これまで専用ツールに限定されていた地図や高度な GIS 技術を使用した新しいデータを、ビジネス ユーザーが活用できるようになりました。さらに、Power BI Desktop の 2017 年 11 月のリリースより、ArcGIS Maps for Power BI の新しい Plus サブスクリプションの一般提供を開始しました。これは、地図、世界の統計データ、検証済みの整形されたデータなどを利用して、精密なグラフィックを作成し、将来の計画や意思決定に利用できるサブスクリプションです。詳しくはこちらのブログ記事 (英語) をご覧ください。
  
• レポート機能の強化: 表やマトリックスでのルール ベースの条件付き書式、表やマトリックスでのセルの文字列の配置、選択ウィンドウからのオブジェクトの表示順の制御、レポート上のオブジェクトのロック、フィルター処理のパフォーマンス向上など、さまざまなレポート機能を継続的に強化しています。
  
• カスタム ビジュアルを追加: 画像タイムライン、ソーシャル ネットワーク グラフ、ベン図、HTML ビューアーの 4 つの新しいカスタム ビジュアルを利用できるようになりました。
  

• 分析とデータ接続に関する機能強化: 多次元 AS モデルで複数の行カードがセル レベルの書式設定に対応したほか、Impala コネクタでの Windows 認証や、「例から列を追加する」際の条件列の変換が可能になりました。最新の Power BI Desktop をダウンロードして、今すぐ新機能をご利用ください。
  

今回ご紹介した新機能やその他の機能については、Power BI ブログ (英語) をお読みください。

Power BI サービス – 新機能のリリース

Power BI アプリをユーザーが外部のゲスト ユーザーにシームレスに配信できるようになりました。受信者は自身の組織のセキュリティ資格情報や個人のメール アドレスを使用して、安全にサインインできるほか、コンテンツ所有者は引き続き内部データを管理することができます。

この新機能は、Power BI と Azure Active Directory (AD) B2B コラボレーションの統合によって実現しました。統合の詳細については、こちらのドキュメントをご覧ください。

Azure SQL Database – 3 つの新機能

Azure SQL Database エンジンに関する機能を更新

Azure SQL Database エンジンに関する 3 つの新機能を正式にリリースしました。再開可能なオンライン インデックス再構築機能 (英語) では、再構築操作を一時停止した場合に、一時停止または失敗した時点から操作を再開することができます。データベース スコープのグローバル一時テーブル (英語) は、特定のデータベース範囲内でグローバル一時テーブルを使用する機能で、同一データベースの全ユーザー セッションでテーブルを共有できるようになります。カタログ照合順序機能では、システム ビューとシステム テーブルのメタデータ カタログにおける既定の照合順序を指定して、データベースの既定と一致させることができます。

Visual Studio 2017 の更新プログラム.

Visual Studio 2017 の新たな更新プログラムをリリースしました。マイクロソフトでは、Visual Studio 2017 の更新時には必ずユーザーの皆様のフィードバックに耳を傾け、ご意見が寄せられた機能を重点的に改善しています。

今回の更新プログラムでは、プロジェクトの読み込み時間が短縮されており、その分多くの時間をコーディングに割けるようになりました。また、[プログラムの追加と削除] から Visual Studio インストール環境を変更できるようになりました。

新機能としては、Xamarin.iOS 11.4 と Xamarin.Android 8.1 対応の最新のモバイル アプリ ツールのほか、開発者が iOS および Android デバイスで直接、アプリを継続的に展開、テスト、デバッグできる Xamarin Live Player が含まれています。また、C++、C#、F# に対する言語サポートも強化されています。

Visual Studio Enterprise 2017 ユーザー向けには、Live Unit Testing 機能が強化されたほか、特定のプロジェクト タイプで IntelliTrace でのデバッグ中のステップバックが可能になりました。また、スナップポイントとログポイントを使用して、Azure App Services で実行される ASP.NET と ASP.NET Core アプリケーションに対するデバッグを実行できるようになりました。

機能の詳細については、リリース ノートをご確認のうえ、今すぐ最新バージョンをダウンロードしてください。

Visual Studio for Mac の更新プログラム.

Visual Studio for Mac の新たな更新プログラムをリリースしました。デバイスを自動的にセットアップして開発とプロビジョニングを簡素化する fastlane の統合により、iOS でのスムーズなモバイル開発エクスペリエンスが実現します。また、新しい iOS 11、tvOS 11、watchOS 4 の API が完全にサポートされ、.NET Core も 2.0 に更新されています。さらに、VSTest のサポートにより、MSTest や Xunit などのさまざまな人気のテスト フレームワーク向けの統合エクスペリエンスが実現します。

リリース ノートはこちら (英語) からご覧ください。更新プログラムはこちらのページ、または Visual Studio for Mac 更新ツールからダウンロードしてください。

System Center Configuration Manager – 共同管理機能のリリース

System Center Configuration Manager の最新リリースの主要機能の 1 つである「共同管理」では、Windows 10 デバイス管理を刷新するための実質的な新しい移行パスを提供します。これまでの方法では、お客様のシナリオによって、Configuration Manager エージェントが必要であったり、Windows 7 デバイスを管理する必要があったりと、簡単に移行できない場合がありました。そのため、Configuration Manager と Active Directory を使用した管理から、Intune と Azure Active Directory (AD) による最新の管理方法へと移行するためのシンプルで制御可能な方法が求められていました。これを可能にするのが、共同管理機能です。

Anniversary Update (2016 年 6 月) より、Windows 10 デバイスがオンプレミスの Active Directory とクラウドの Azure AD に同時に参加できるようになりました。共同管理機能ではこれを応用して、Configuration Manager エージェントと Intune MDM の両方でデバイスを管理します。これにより、企業は特定の管理ワークロードを扱いやすい単位でクラウドに移行することができます。たとえば、デバイス コンプライアンス チェック、リソース アクセス ポリシー、Windows 10 の更新管理などを Intune へ移行しつつ、ソフトウェア配布やデバイスの詳細なセキュリティ構成といった他のワークロードは Configuration Manager で引き続き管理することが可能です。詳しくはこちらのブログ記事 (英語) をご覧ください。

我們聽到許多人希望 OMS 可以擴展對 Kubernetes 的支持，因此如同之前發布的 Mesosphere DC/OS，現在您在 Azure Container Service 、Mesosphere DC/OS 和 Kubernetes 的 container 都可以有一貫的 Container 監控解決方案。

您可以在 Kubernetes 環境中上傳我們的 yaml 檔案，並以 daemon-set 形式運行 Linux 用的 OMS。 關於 yaml 檔案，請至 OMS 代理 Linux yaml 檔案。

或您可以透過 kubectl cli. 執行：

#sudo kubectl create -f omsagent.yaml

#sudo kubectl get ds

NAME       DESIRED   CURRENT   NODE-SELECTOR   AGE

omsagent   3         3         <none>          33m

除了蒐集 container 效能、容量、搜尋記錄，和事件之外，OMS 代理 Linux 現在可以蒐集主機 syslogs。

若您有興趣了解更多詳細資訊，請參考此篇："用微軟 OMS 監控 Azure Container Service 叢集"。

我該如何試用這個?

獲取一個免費的微軟 Operations Management + Security (#MSOMS) 帳號，如此一來您可以測試 Container 監控解決方案的特色。您也可以免費訂閱微軟 Azure。

[ブログ更新日：2017年12月11日]

Posted by：ブラッド スミス
プレジデント兼最高法務責任者
(Brad Smith - President and Chief Legal Officer)

AI for Earth　戦略的アプローチの拡大による 5,000 万ドルのコミットメント

パリ協定の起草から 2 年目を迎える今、世界の政府機関、そして、市民活動とビジネスのリーダーたちがパリに集結し、今日最も重要な課題であり機会でもある気候変動について議論します。今回、この会議でマイクロソフト代表団の代表することを大変うれしく思っています。地球が直面する環境問題に対する専門家の警告には厳しいものがありますが、マイクロソフトは、この問題の理解と解決にテクノロジが貢献できることを信じています。これこそが、パリでAI for Earth プログラムの拡充について発表した理由です。そして戦略計画の拡大に加え、世界中で地球環境の保護に取り組む個人や組織に向けて、人工知能（AI）テクノロジを提供するために今後 5 年間で 5,000 万ドルを投資することとしました。

マイクロソフトは、AIが真の意味での革新であると考えています。AIを民主化し、世界中の個人や組織がその機能やパワーを活用して現実的な結果を出すことに企業としてフォーカスしています。地球の自然を監視し、モデル化し、管理するという差し迫った課題に対応する上でも、AI は大きく貢献します。

データは、大気、水資源、土地、そして、野生動物の健康の状況など、地球の健全性について知るきっかけとなります。しかし、大量のデータを保管、それを有用なインテリジェンスに変換するためには、テクノロジの力が必要です。AI は学習することで、地表、空中、宇宙のセンサーが生成するローデータを、人間とコンピューターが理解しやすい形に分類できます。AI は、私たちの環境システムとその地球規模での変化を観測する能力を強化し、データを有用な情報に変換し、自然資源を有効活用するための具体的な措置を講じる上での大きな助けとなります。

AI による変革は既に始まっています。エネルギー分野では、ノルウェイの再生可能エネルギー企業 Agder Energi が、マイクロソフトのクラウドと AI を活用して送電線網のデータの獲得・分析・活用を強化しています。電気自動車によるノルウェイの電力システムの負担が増す中で、Agder はこれらのテクノロジにより変動するエネルギー需要を予測し、対応できるようになりました。データと AI は、既存のインフラを強化し、高コストの新規プロジェクトの必要性を軽減します。AI は、より効率的で信頼性が高い自律型電力網の構築に貢献すると共に、顧客や国家がより多くの再生可能エネルギーを使用できるようにし、電気に基づく未来への移行を支援します。

同様に、AI とクラウドのテクノロジがビルの電力効率性の向上に使用されています。シンガポールでは、国家の産業基盤開発を担う JTC が運用業務をMicrosoft Cloud 上に集約し、39 棟のビルの監視・分析・最適化を行なっています。JTC は、センサーのデータとアナリティクスを活用し、障害が起こる前に問題を発見・修復し、最初の 3 棟のビルだけでエネルギーコストを 15 パーセント削減しました。

これらのステップをグローバルな規模に拡大すればどのような効果が得られるか想像してみるとよいでしょう。米国では、総エネルギー消費の 40 パーセントがビル関連です。これは、ビルのエネルギー効率を 15 パーセント向上できれば、グローバルのエネルギー消費を 6 パーセント削減できることを意味します。そして、AI の進化が続く中でさらに多くを学び、より高い目標を目指す機会が生まれます。

AI の農業分野への応用の見通しも同様に明るいものです。オーストラリアでは、高い労働コストと輸入コスト、乾燥した気候、世界で最も激しい天気の変動が農業の大きな課題となっていました。タスマニア州のアグテック（農業技術）企業である Yield は、センサー、アナリティクス、アプリを活用し、農地単位にまで詳細化したリアルタイムの天候データを生成することで、農家が水などの消費を削減しつつ、収穫を増大できるようにしました。漁業分野では、Yield は地域の牡蠣養殖業者と協力し、機械学習を使用した養殖生産高増加のための最初の製品を開発しました。既にこのソリューションは雨による収穫の中止を 30 パーセント削減し、収穫期を年間 4 週間延長できています。

このような結果に触発され、AI for Earth プログラムもさらに拡大することにしました。将来的には、世界中の農家と協力していくことを確約します。あらゆる農家がブロードバンドと接続し、あらゆる農地にインターネットのセンサーがある未来を構想しています。Microsoft Research の最新の研究成果に基づき、土壌と降雨の状況をより適切に分析するだけでなく、予測分析によって収穫高を増大させ、環境への悪影響を削減し、農家の人々がAI を活用できるよう支援していきます。世界の人口が増加し続ける中で、これらの変革は急がねばなりません。

マイクロソフトは、AI for Earth が環境を保護するソリューションを構築するグループや個人を強く後押しすると考えています。そのため、単に多くのリソースを投入するだけではなく、AI を気象、水資源、農業、生物学的多様性という4つの主要領域に適用し、規模を拡大していくという長期的なコミットメントの元にこの取り組みを行なっています。

マイクロソフトはこれを 3 つのステップで実現します。第一に、新しい AIアプリケーションの構築とテストのための助成金の授与を、世界中で拡大します。6 カ月前の AI for Earth の立ち上げ以来、マイクロソフトは Microsoft Azure と AI テクノロジのアクセスのために 10 カ国以上で 35 件以上の助成金を授与しています。また、AI の最適な活用を目指して、大学や民間非営利団体などに高度な研修を提供しています。既に、気象、水資源、農業、生物学的多様性などへ AI を適用するプロジェクトが、世界中で成功し始めています。

次に、これらのプロジェクトと、この分野におけるマイクロソフトの研究開発成果が成熟するにつれ、最も有望なプロジェクトを識別し、その規模を拡大するための追加投資を行ないます。また、AI と環境保護の専門家を集めてマイクロソフト内に新設された学際チームとの緊密な連携も行ないます。有望な AI テクノロジの適用規模拡大を援助する中で、サービスの商業化も支援し、できるだけ迅速かつ広範に、グローバルな影響力を発揮できるようにします。これらの取り組みは、リアルタイムの正確な保護と土地被覆図の改良、FarmBeats プログラムによる少ないリソースで生産高を増加させる精密農業、そして、Project Premonition による効率的な生物学的多様性管理と保護へのアプローチなど、マイクロソフトの既存の取り組みに追加して行なわれます。

最後に、これらのプロジェクトをさらに進展させ、AI の新たな技術進化をプラットフォームへサービスとして取り込み、他者が独自の環境保護の取り組みで活用できるようにする機会を特定し、追求します。ここでは、他者が提供するプラットフォームも含まれるでしょうし、マイクロソフトのプラットフォームへサービスとして取り込まれる可能性もあります。

地球の気候問題は今、私たち全員が迅速なアクションを取る必要性に迫られています。今日の気候問題は、過去の産業革命の副産物であるところが大きいことが、科学的に証明されています。テクノロジが推進する第四次産業革命に突入する中で、テクノロジを進化させることに加え、過去の問題を解決し、より良い未来を作るためにテクノロジを活用していかなければなりません。

ｰｰｰ

本ページのすべての内容は、作成日時点でのものであり、予告なく変更される場合があります。正式な社内承認や各社との契約締結が必要な場合は、それまでは確定されるものではありません。また、様々な事由・背景により、一部または全部が変更、キャンセル、実現困難となる場合があります。予めご了承下さい。

{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"OS": {
"type": "string",
"defaultValue": "Windows",
"allowedValues": [
"Linux",
"Windows"
],
"metadata": {
"description": "DSC extension selection setting. Linux, Windows"
}
},
"vmName": {
"type": "string",
"metadata": {
"description": "Name of the existing VM to apply the DSC configuration to"
}
},
"modulesUrl": {
"type": "string",
"defaultValue": "https://github.com/Azure/azure-quickstart-templates/raw/master/dsc-extension-azure-automation-pullserver/UpdateLCMforAAPull.zip",
"metadata": {
"description": "URL for the DSC configuration package. NOTE: Can be a Github url(raw) to the zip file (this is the default value)"
}
},
"configurationFunction": {
"type": "string",
"defaultValue": "UpdateLCMforAAPull.ps1\ConfigureLCMforAAPull",
"metadata": {
"description": "DSC configuration function to call. Should contain filename and function in format fileName.ps1\configurationfunction"
}
},
"registrationKey": {
"type": "securestring",
"metadata": {
"description": "Registration key to use to onboard to the Azure Automation DSC pull/reporting server"
}
},
"registrationUrl": {
"type": "string",
"metadata": {
"description": "Registration url of the Azure Automation DSC pull/reporting server"
}
},
"nodeConfigurationName": {
"type": "string",
"metadata": {
"description": "The name of the node configuration, on the Azure Automation DSC pull server, that this node will be configured as"
}
},
"configurationMode": {
"type": "string",
"defaultValue": "ApplyAndAutoCorrect",
"allowedValues": [
"ApplyOnly",
"ApplyAndMonitor",
"ApplyAndAutoCorrect"
],
"metadata": {
"description": "DSC agent (LCM) configuration mode setting. ApplyOnly, ApplyAndMonitor, or ApplyAndAutoCorrect"
}
},
"configurationModeFrequencyMins": {
"type": "int",
"defaultValue": 15,
"metadata": {
"description": "DSC agent (LCM) configuration mode frequency setting, in minutes"
}
},
"refreshFrequencyMins": {
"type": "int",
"defaultValue": 30,
"metadata": {
"description": "DSC agent (LCM) refresh frequency setting, in minutes"
}
},
"rebootNodeIfNeeded": {
"type": "bool",
"defaultValue": true,
"metadata": {
"description": "DSC agent (LCM) rebootNodeIfNeeded setting"
}
},
"actionAfterReboot": {
"type": "string",
"defaultValue": "ContinueConfiguration",
"allowedValues": [
"ContinueConfiguration",
"StopConfiguration"
],
"metadata": {
"description": "DSC agent (LCM) actionAfterReboot setting. ContinueConfiguration or StopConfiguration"
}
},
"allowModuleOverwrite": {
"type": "bool",
"defaultValue": false,
"metadata": {
"description": "DSC agent (LCM) allowModuleOverwrite setting"
}
},
"timestamp": {
"type": "string",
"metadata": {
"description": "The current datetime, as a string, to force the request to go through ARM even if all fields are the same as last ARM deployment of this template; example in parameters file is in MM/dd/yyyy H:mm:ss tt format"
}
}
},
"variables": {

},
"resources": [
{
"condition": "[equals(parameters('OS'), 'Linux')]",
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "[concat(parameters('vmName'),'/Microsoft.OSTCExtensions.DSCForLinux')]",
"location": "[resourceGroup().location]",
"apiVersion": "2016-04-30-preview",
"properties": {
"publisher": "Microsoft.OSTCExtensions",
"type": "DSCForLinux",
"forceUpdateTag": "RerunExtension",
"typeHandlerVersion": "2.7",
"autoUpgradeMinorVersion": true,
"settings": {
"ExtensionAction": "Register",
"NodeConfigurationName": "[parameters('nodeConfigurationName')]",
"RefreshFrequencyMins": "[parameters('refreshFrequencyMins')]",
"ConfigurationMode": "[parameters('configurationMode')]",
"ConfigurationModeFrequencyMins": "[parameters('configurationModeFrequencyMins')]",
"advancedOptions": {
"forcePullAndApply": true
}
},
"protectedSettings": {
"RegistrationUrl": "[parameters('registrationUrl')]",
"RegistrationKey": "[parameters('registrationKey')]"
}
}
},
{
"condition": "[equals(parameters('OS'), 'Windows')]",
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "[concat(parameters('vmName'),'/Microsoft.Powershell.DSC')]",
"apiVersion": "2016-04-30-preview",
"location": "[resourceGroup().location]",
"properties": {
"publisher": "Microsoft.Powershell",
"type": "DSC",
"forceUpdateTag": "RerunExtension",
"typeHandlerVersion": "2.72",
"autoUpgradeMinorVersion": true,
"protectedSettings": {
"Items": {
"registrationKeyPrivate": "[parameters('registrationKey')]"
}
},
"settings": {
"ModulesUrl": "[parameters('modulesUrl')]",
"SasToken": "",
"ConfigurationFunction": "[parameters('configurationFunction')]",
"Properties": [
{
"Name": "RegistrationKey",
"Value": {
"UserName": "PLACEHOLDER_DONOTUSE",
"Password": "PrivateSettingsRef:registrationKeyPrivate"
},
"TypeName": "System.Management.Automation.PSCredential"
},
{
"Name": "RegistrationUrl",
"Value": "[parameters('registrationUrl')]",
"TypeName": "System.String"
},
{
"Name": "NodeConfigurationName",
"Value": "[parameters('nodeConfigurationName')]",
"TypeName": "System.String"
},
{
"Name": "ConfigurationMode",
"Value": "[parameters('configurationMode')]",
"TypeName": "System.String"
},
{
"Name": "ConfigurationModeFrequencyMins",
"Value": "[parameters('configurationModeFrequencyMins')]",
"TypeName": "System.Int32"
},
{
"Name": "RefreshFrequencyMins",
"Value": "[parameters('refreshFrequencyMins')]",
"TypeName": "System.Int32"
},
{
"Name": "RebootNodeIfNeeded",
"Value": "[parameters('rebootNodeIfNeeded')]",
"TypeName": "System.Boolean"
},
{
"Name": "ActionAfterReboot",
"Value": "[parameters('actionAfterReboot')]",
"TypeName": "System.String"
},
{
"Name": "AllowModuleOverwrite",
"Value": "[parameters('allowModuleOverwrite')]",
"TypeName": "System.Boolean"
},
{
"Name": "Timestamp",
"Value": "[parameters('timestamp')]",
"TypeName": "System.String"
}
],
"advancedOptions": {
"forcePullAndApply": true
}
}
}
}
]
}

function Get-AzureExtensionHighestVersion {
   [CmdletBinding()]
   PARAM ([string]$extension, [string] $location='AustraliaEast') 

   $sortProps = @{Expression = "PublisherName"; Descending = $True}, @{Expression = "Type"; Descending = $True},@{Expression = "Version"; Descending = $True}
   $Results= Get-AzureRmVmImagePublisher -Location $location |
     Get-AzureRmVMExtensionImageType |
      Get-AzureRmVMExtensionImage |
       Where-Object {$_.Type -LIKE "*$extension*"}

  #replace version text with version object type
  $versions=$Results | Select-Object -Property PublisherName, Type, @{N='Version';E={([version] $_.Version)}}

  # first sort the whole table, then groupby on a dummy key of Publisher+Type
   # - then we only want the first from each group. voila!

  $output = $versions | Sort-Object $sortProps |
  Select-Object *,@{N='XXX';E={$_.PublisherName+' '+$_.Type }} | Group-Object -Property XXX |
     Foreach-Object {$_.Group[0] | Select-Object Type,PublisherName,Version}

  $output
}

Get-AzureExtensionHighestVersion DSC

Mike Tholfsen – The Future of OneNote in Education from Jared DeCamp on Vimeo.

For anyone that oversees the use of technology for eLearning in their school, this video is well worth watching. In it, Mike Tholfsen does a great job going over the current, new and future features of OneNote with a specific focus on how it can be used in education. Furthermore, he hints at new and exciting features being announced in the short term to come.

I highly recommend watching the entire 30 minutes but particularly want to call out the following three features:

• The combination of OneNote, Office Lens and Immersive Reader. This allows for an impressive workflow of taking a photograph of text from a book using Office Lens, sending it to OneNote where the text is scanned by Optical Character Recognition (OCR) and then Immersive Reader can have the text highlighted and read back to you. This is huge when it comes to literacy and comprehension, meaning a student can take text from any source and quickly have Immersive Reader breaking down the text for them.

The original text from a book photographed using Office Lens and then scanned by OCR to make the text readable by Immersive Reader.

The same text from the original photograph now being read back by Immersive Reader

• Office Lens and Immersive Reader: The read aloud feature of Immersive Reader has been added to the Office Lens app, meaning a photo can be taken and the text read aloud directly from within the app. Useful for when you don’t want to involve OneNote for a quick read.
• Open Up Resources:  A new partnership where curriculum specific resources are prepared and formatted for OneNote and can be pushed directly into the student sections of OneNote like other page content. Additionally, appropriate assessment is pre-built to match the teaching curriculum and these are made in Microsoft Forms and automatically added to your tenant when the resources are added to the Class OneNote NoteBook.

You’ll need to type the links above as they are in an image and not hyperlinks.

Finally, there were two great links for keeping across the developments of OneNote in Education:

• http://aka.ms/OneNoteWhatsNew  General overview of latest features in OneNote.
• http://aka.ms/OneNoteMatrix A useful table showing the different features of OneNote and how they work on various Operating Systems and versions

摘要：使用 DNS 分析來獲得 DNS 基礎架構的安全性、性能，與操作相關的洞察報告

DNS 分析現在有公開預覽版了。此篇文章會簡介它的一些功能，例如，指出嘗試解析惡意網域名稱的用戶端、指出過時的資源紀錄、指出經常查詢的網域名稱等等，且無須任何預配置。

與惡意網域通訊

利用微軟威脅情報資料，DNS 分析可以偵測嘗試存取惡意網域的用戶端 IP 。在許多情況下，受惡意程式碼感染的裝置會透過解析惡意程式碼網域名稱，「撥出」至惡意網域的「命令與控制項」中心。在下列範例中，DNS 分析偵測到透過 IRCbot 進行的通訊。

此資訊讓您可以識別起始通訊的用戶端 IP、解析微惡意 IP 的網域名稱、網域名稱解析成的 IP 位址、惡意 IP 位址、問題的嚴重性、將惡意 IP 列入黑名單的原因，和偵測時間。

注意：基於隱私原因，圖中 Live IP 位址已被遮住

識別經常查詢的網域名稱和 talkative DNS 用戶端

此解決方案提供您企業環境中 DNS 用戶端最常查詢的網域名稱。您可以檢視查詢過的所有網域名稱清單，並在記錄搜尋中深入了解特定網域名稱的查閱要求詳細資料。

DNS 用戶端分析了違反閾值的用戶端在所選時間周期內的查詢數目。您可以在記錄搜尋中檢視所有 DNS 用戶端的清單，和他們執行查詢的詳細資料

追蹤動態 DNS 註冊

此解決方案能追蹤來自不同客戶端的 DNS 更新要求，和了解這些更新要求是否成功。

接著，您可以依下列步驟，利用此資訊找到註冊失敗的根本原因：尋找對於用戶端嘗試更新之名稱具有權威性的區域、使用此解決方案來檢查該區域的清查資訊、確認已啟用該區域的動態更新、檢查該區域是否已設定安全動態更新。

查明過時的資源記錄

此解決方案提供 Log Search 中所選定的時間段，一個過時資源記錄列表。此列表涵蓋資源記錄名稱、資源記錄類型、相關的 DNS 伺服器、記錄建立的時間，以及區域名稱。基於此資訊，DNS 管理員可以自 DNS 伺服器移除過時的資源。

了解 DNS 伺服器和區域的負載量

了解負載，對於 DNS 基礎架構的容量規劃和性能非常重要。您可以透過觀察每個伺服器和區域的 DNS 查詢速率趨勢，知曉 DNS 負載在您 DNS 伺服器和 DNS 區域的分布狀況。

DNS記錄的集中圖表

在記錄搜尋中可以檢視此解決方案管理的 DNS 伺服器所產生的所有 DNS 事件及所有 DNS 清查相關資料。輸入 Type=DnsEvents 結果會列出與查閱查詢、動態註冊，和設定變更相關之所有事件的紀錄資料。輸入 Type=DnsInventory 結果會列出 DNS 伺服器、DNS 區域和資源記錄的資料。利用 Log Search facet 控制項來篩選搜尋結果，以便分析資料，產生可實現的預測，並建立有意義的報告。

此解決方案如何運作?

此解決方案自安裝了 OMS 代理程式的 DNS 伺服器收集三種類型的數據：DNS 清查、DNS 事件，和 DNS 性能計數器。DNS 清查相關資料 (DNS 伺服器數目、區域和資源記錄等)的收集方式是執行 DNS PowerShell Cmdlet。DNS 事件相關資料(查詢查閱、動態註冊、設定更改)是收集自 Windows Server 2012 R2 及更高版本中，增強的 DNS 記錄和診斷提供之分析與稽核事件記錄。

現在就開始使用

您可以在以下這篇文章獲得更詳細的步驟指引：開始使用 DNS 分析。

Microsoft Teams サポートチーム 小松です。

現在、既知の情報として以下の現象について認識しております。

Teamsでは製品の実装上の制限により、同じ名前のチャネルを再作成できません。
同じ名前で作成しようとすると、”同じ名前のチャネルが既にあります。別の名前をお試しください。” と表記されます。

こちらについては、Office 365 側でアーカイブデーターを管理する上での実装となり、
現在、実装の変更の予定はございません。
そのため、チャネル名を削除する場合は、十分ご注意いただきご利用いただきますようお願いいたします。

[公開技術情報]
TITLE: Microsoft Teams の既知の問題
URL: https://docs.microsoft.com/ja-jp/microsoftteams/known-issues
-抜粋-
問題のタイトル: 既存のチャネル名を再作成できません
動作 / 症状: チャネル名は一度作成されると、削除しても再作成できません。 システムでは、このデータは情報保護シナリオ用に維持されます。
既知の回避策: 回避策なし。

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

こんにちは、Azure ID サポートチームの高田です。

本日は、Azure AD のサインイン画面の変更とそれに伴うフェデレーション環境への影響についておまとめしました。

まず、Microsoft では、11 月より Azure AD のサインイン画面にいくつか変更を加えております。具体的には、新しいサインイン エクスペリエンスが導入されており、Azure AD へのサインイン時に以下のような画面が表示されることにお気づきの方もいらっしゃると思います。

▼古いサインイン エクスペリエンス

▼新しいサインイン エクスペリエンス

※画面遷移の説明は、下記ブログを参照ください。

The new Azure AD sign-in and “Keep me signed in” experiences rolling out now!
https://cloudblogs.microsoft.com/enterprisemobility/2017/11/15/the-new-azure-ad-sign-in-and-keep-me-signed-in-experiences-rolling-out-now/

この [サインインの状態を維持しますか？] の画面は、古いサインイン画面の [サインインしたままにする] チェックボックスと同じ設定を表しています。Azure AD の [会社のブランド] から構成できる [サインインしたままにするオプションを表示する] の設定が [はい] の場合に表示されます。

既定ではこのオプションは [はい] の状態で、明示的に [いいえ] にしていない限り、基本的に上記の [サインインの状態を維持しますか？] の画面が表示されることとなります (オプションを [いいえ] にした場合、[サインインの状態を維持しますか？] の画面は表示されず、サインイン状態は維持されない動作です)。

※[会社のブランド] を構成する手順につきましては、下記の公開情報を参照ください。

クイック スタート: Azure AD のサインイン ページに会社のブランドを追加する
https://docs.microsoft.com/ja-jp/azure/active-directory/customize-branding

※ 以下は、上記設定画面における既知の問題と対処方法を案内している公開情報です。

「サインインしたままにするオプションを表示する」 の設定が保存できない
https://answers.microsoft.com/thread/e8a32fbe-8d80-43f3-b99c-af585b4c57b

この [サインインの状態を維持しますか？] の画面は、 [サインインしたままにするオプションを表示する] オプションを [はい] にしていても、以下の場合に表示されません。

1. Azure AD がユーザーのサインインをリスクある状態と判断した場合
2. フェデレーション ユーザーにてサインインを試行し、AD FS にて Windows 統合認証が用いられた場合

上記 1 については、同一のマシンを複数人で共有していたり、短時間に長距離を移動したユーザーが該当します。
リスクの高いサインインについては以下の資料も参考にしていただければと思います。

Azure Active Directory ポータルのリスクの高いサインイン レポート
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-reporting-security-risky-sign-ins

上記 2 は、社内にいるユーザーが AD FS を利用してサインインする場合を示しています。

Windows 統合認証を用いてサインインする場合、ユーザーから見るとアプリケーションへのアクセスから Azure AD へのリダイレクト、さらに AD FS へのリダイレクト後の Windows 統合認証がすべて自動的に完了する流れとなります。[サインインの状態を維持しますか？] の画面は、一連の処理の流れを止めることとなるため、Windows 統合認証の場合に表示されないよう実装されました。AD FS にて Windows 統合認証が用いられたとき、[サインインの状態を維持しますか？] の選択は表示されませんが、選択としては [いいえ] の状態で認証が完了しています。このため、サインインの状態は維持されません (Azure AD から永続的なクッキーは発行されません)。

AD FS を利用する場合でも、社内からではなく外部から WAP (Web Application Proxy) を介してアクセスするような場合や、社内からのアクセスであっても、Firefox 等、AD FS の標準設定では Windows 統合認証が使用できないブラウザをお使いの場合は、フォーム認証が用いられます。このときは、1 に合致していない状況であれば [サインインの状態を維持しますか？] の画面が表示されます。

フェデレーション環境をお持ちのお客様において、AD FS で Windows 統合認証が行われた場合もサインインの状態を維持したい (Azure AD から永続的なクッキーを発行したい) とお考えのお客様においては、後述の対応を実施いただければと思います。

以下では AD FS 側でクレーム ルールを変更し、組織内からの認証の場合は、psso (Persistent SSO) と呼ばれるクレームをトークンに含めるように構成します。これを受け取った Azure AD は、サインイン状態を維持させるよう永続的なクッキーをクライアントに発行します。この際、「サインイン状態を維持しますか？」画面は表示されませんが、サインイン状態を維持するクッキーが発行されます ([サインインの状態を維持しますか？] 画面で手動にて [はい] を押下したのと同じ状態となります)。

AD FS サーバー上の手順を以下におまとめいたしましたので、ご確認いただけますと幸いです。

1. AD FS サーバーに管理者でログオンします。
2. AD FS の管理コンソールを開きます。
3. 画面左側のツリーから [証明書利用者信頼] を選択します。
4. [Microsoft Office 365 Identity Platform] を右クリックし、[要求規則の編集] を選択します。
5. [発行変換規則] で [規則の追加] をクリックします。
6. 変換要求規則の追加ウィザードでドロップダウンから [カスタム規則を使用して要求を送信] を選択し、[次へ] をクリックします。
7. [要求規則名] の下のボックスに Keep Users Signed In と入力し、次に進みます。
8. [カスタム規則:] ボックスに次のように入力します。
   c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "true"]
   => issue(Type = "http://schemas.microsoft.com/2014/03/psso", Value = "true");
9. [完了]をクリックし、ウィザードを終了します。

上記クレーム ルールを追加しますと、社内からの (WAP を経由しない) アクセスの場合は、http://schemas.microsoft.com/2014/03/psso のクレームがトークンに追加されます。Azure AD はこのクレームを確認し、永続的なクッキーをクライアントに発行します。AD FS ファーム全体 (全ユーザー) が対象となるルールですが、新しく psso のクレームを追加するだけですので、既存のクレーム ルールに影響を及ぼすことはありません。また、上記ウィザードの完了後すぐに効果が及びます。

なお、クレームルールの追加により予期しない動作が生じた場合は、追加したルールを削除すれば元に戻すことが可能ですので、その際は、追加したルールを削除することで対応ください。

上記内容が少しでもお客様の参考となりますと幸いです。

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

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

By James Kehr, Networking Support Escalation Engineer

The next Container network type on the list is called, transparent. Production Container workloads, outside of swarms and special Azure circumstances, should be using a transparent network. Unless you need to use L2 bridging in an SDN environment, but production will mostly use the transparent network type.

Transparent Networks

The transparent network essentially removes WinNAT from the NBL path. This gives the Container a more direct path through Windows. Management of transparent network attached Containers is as easy as managing any other system. It’s like the virtual network is transparent to the system admins…hmmm.

The only configuration needed with a Container on a transparent network is the IP address information. Since the Container is directly attached to the network infrastructure this can be done through static assignment or regular old DHCP. The Container connects to a normal vmSwitch on the default Compartment 1 (see part 2). On top of easy management, the NBL only travels through four or three hops within Windows, depending on whether LBFO NIC teaming is enabled or not. This decreases latency to normal Hyper-V guest like numbers.

There is at least one circumstance where your Containers will end up on a separate network compartment. This primarily happens when the Container is attached to a Hyper-V created vmSwitch. Hyper-V traffic will use Compartment ID 1, and Container traffic will use something else, like Compartment ID 2. Each Container network attached to the Hyper-V vmSwitch will use a unique Compartment ID. This is done to keep traffic secure and isolation between all the various virtual networks. See part 2 for more details about Compartments.

The traffic looks identical to the Hyper-V traffic, except you see the Container traffic on the host system, where the endpoint is not visible in Hyper-V. The Container vmNIC sends an NBL to the vmSwitch, which routes the traffic to the host NIC, where the NBL is converted to a packet, and off to the wire it goes.

The total time for the ping (Echo Request) to go from the Container to the wire in this example was 0.0144 milliseconds, or 14.4 microsecods. About 47 times faster than the NAT network with PortProxy example. That is quite the significant improvement.

Transparent Container networks offer easier management, less resource consumptions, and significantly improved throughput when compared to NAT networks. Especially when compared to NAT with PortProxy’s. Which is why production Container workloads should, in basic production circumstances, use the Transparent network.

L2Bridge networks

For the purposes of this article the L2Bridge network is identical to a Transparent network. The NBL traverses through Windows in the exact same way. The difference between Transparent and L2Bridge are spelled out in the Windows Container Networking doc.

https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/container-networking

l2bridge - containers attached to a network created with the 'l2bridge' driver will be will be in the same IP subnet as the container host. The IP addresses must be assigned statically from the same prefix as the container host. All container endpoints on the host will have the same MAC address due to Layer-2 address translation (MAC re-write) operation on ingress and egress.

There doesn’t appear to be any obvious way to see the MAC address rewriting in an ETW trace, so there’s nothing new to look at. The L2Bridge is used mainly with Windows SDN. And that’s that.

Hyper-V Isolation

One of the touted features of Docker on Windows is Hyper-V isolation. This feature runs the container inside of a special, highly optimized VM. This adds an extra layer of security, which is good. But there’s no way to troubleshoot what happens to the network traffic once it leaves the host and goes to the optimized VM. Hyper-V isolation is a networking black hole.

The obvious question is… why? The answer boils down to how the optimization is done. Neither the optimized VM nor the Container image have a way to capture packets. The Container because that subsystem is shared with the host kernel, as discussed in part 1. The VM doesn’t have packet capture because it is optimized to the point that it only includes the minimum number of components and features needed to run a Container. That list does not include packet capture. And that’s assuming you could even access the VM, which I haven’t found a way to do.

How exactly does someone go about troubleshooting networking on an isolated Container, then? The Container lives separately from the optimized VM. Isolation is performed when the correct parameter is applied as part of the docker run command when starting the Container. Specifically, the “--isolation=hyperv” parameter. Remove the isolation parameter so the Container starts normally, and then all the normal troubleshooting rules apply. While it’s not a complete apples-to-apples comparison, it does provide some ability to troubleshoot potential networking issues within the Container.

That concludes this series on Windows Virtualization and Container networking. I hope you learned a thing or three. Please keep in mind that technologies such as Containers and Windows networking change a lot. Especially when the technology is young. Don’t be afraid to dig in and learn something new, even if this article just acts as a primer to get your started.

-James

The below PowerShell script can be used to automatically close old SCOM alerts. This script looks for active alerts along with the time when alert was created (alert age). If the alert age is greater than the specified number of days ($alertsTobeClosedBefore) then the script will close the alert for you. This script can help clean up some environments with lot of old alerts which are still active.

Script:

$alertsTobeClosedBefore = 5

$currentDate = Get-Date

Get-SCOMAlert | Where-Object {(($_.ResolutionState -ne 255) -and (($currentDate - $_.TimeRaised).TotalDays -ge $alertsTobeClosedBefore))} |Resolve-SCOMAlert

こんにちは。Azure Identity サポートチームの橋本です。

先日 12 月 12 日に公開された Azure AD Connect で利用するアカウントのセキュリティ強化に関する下記セキュリティ アドバイザリについて補足情報をお知らせします。

Microsoft Security Advisory 4056318
Guidance for securing AD DS account used by Azure AD Connect for directory synchronization

• セキュリティ アドバイザリの概要について
• 対処策について

セキュリティ アドバイザリの概要について

Azure AD Connect (AADC) はオンプレミスの Active Directory に接続するためのアカウントをインストール時に作成します。

このアカウントは、同期処理を実施するためにオンプレミス AD に対してパスワードリセットなど （Exchange ハイブリッドを構成した場合はディレクトリ オブジェクトへの書き込みや、パスワードの書き戻しを構成している場合はパスワードのリセット） などの比較的強い権限を持ちます。

この権限を持つこと自体は AADC の動作上、必要なことであり、今回のアドバイザリでも、このことを問題にしているわけではありません。

※ アカウントに必要な権限の詳細については、Azure AD Connect: アカウントとアクセス許可 をご確認ください。

このように比較的強い権限を保持するアカウントであるため、しっかりアクセス権を設定して保護を実施しましょうということが、このセキュリティ アドバイザリ情報です。

具体的には、推奨される対処として該当アカウント オブジェクトに対してアクセス権を設定して保護を強力にする方法について記載しています。

対処策について

AADC のオンプレミス AD に接続する際に使用するアカウントへのアクセス権を限定したものに変更します。

これから新規インストールする場合

バージョン 1.1.654.0 以降を利用して新規でインストールする場合には、AADC のインストール時に自動生成される接続用アカウントについては限定されたアクセス許可が付与された形で生成されるように改善されましたので対処は不要です。ただし、新規インストール時であっても、構成時に [必須コンポーネントのインストール] 画面にて、 既存のサービス アカウントを接続用アカウントとして指定する場合は、以下の手順にて別途アクセス許可を変更する必要があります。

既に Azure AD Connect が構成されている場合

多くのお客様はこちらに該当するかと思います。

1.1.654.0 に含まれるアップグレードは新規インストール時に自動生成される接続用アカウントのみが対象となります。既存の AADC に対してアップグレードを行った場合や、再インストール時に既存のアカウントを指定した場合はアクセス許可は変更されないため、別途以下でご案内しているスクリプトなどによる直接の変更が必要です。

既存の構成へ対処が必要な場合は、以下の手順にてセキュリティ設定を変更します。

この手順を実施することで、[Active Directory ユーザーとコンピューター] から当該サービス アカウントのプロパティを開き、[セキュリティ] - [詳細設定] から確認できる、サービス アカウントへのアクセス許可設定が以下のように限定されたものに変更されます。

スクリプトによるアクセス許可の変更後の設定:

設定手順

1. 1. AADC サーバー上で、デスクトップ上のショートカットなどより AADC の構成ウィザード ("C:Program FilesMicrosoft Azure Active Directory ConnectAzureADConnect.exe") を実行します。
   2. [構成] をクリックします。
   3. [現在の構成を表示する] を選択し、[次へ] をクリックします。
   4. [同期されたディレクトリ] 配下の [ACCOUNT] に表示されているアカウントを確認します。
      このアカウントがオンプレミス AD への接続用のサービス アカウントです。
      例: contoso.localMSOL_546eeedf0b95
   5. [終了] をクリックし、画面を閉じます。
   6. ドメイン コントローラーに管理者権限でログオンします。
   7. PowerShell を管理者として実行し、以下のコマンドなどを実行し、手順 4 で確認したアカウントの DistinguishedName を確認します。
      

      Get-aduser <アカウント名>例:  Get-aduser MSOL_546eeedf0b95出力例: DistinguishedName : CN=MSOL_546eeedf0b95,CN=Users,DC=contoso,DC=local

   8. AdSyncConfig.psm1 をダウンロードします。※ もしファイルのダウンロード時に警告が表示された場合、ダウンロードしたファイルのプロパティを開き、以下のチェックが行われているかご確認ください。
      チェックが行われている場合は、チェックを外して [OK] をクリックしてください。
   9. 管理者として実行している PowerShell にて、AdSyncConfig.psm1 をダウンロードしたディレクトリに移動し、以下のコマンドを実行します。
      

      import-module .AdSyncConfig.psm1

   10. 続けて以下のコマンドを実行します。
       認証ダイアログが表示されるので、オンプレミス AD のエンタープライズ管理者等、アカウントの設定を変更できる権限を持つアカウントの資格情報を入力します。

       Set-ADSyncRestrictedPermissions -ObjectDN "<AD 接続用サービスアカウントの DistinguishedName>" -Credential $credential

       例: Set-ADSyncRestrictedPermissions -ObjectDN "CN=MSOL_546eeedf0b95,CN=Users,DC=contoso,DC=local" -Credential $credential

   11. スクリプトを続行するか確認が行われる場合は、"Y" キーを押して ENTER キーを押します。
       以下のメッセージが表示されていれば成功です。

       Setting Restricted permissions on <アカウントの DistinguishedName> completed successfully.

関連情報:

Microsoft Security Advisory 4056318
https://docs.microsoft.com/en-us/security-updates/securityadvisories/2017/4056318

1. ご不明な点等がありましたら、ぜひ弊社サポート サービスをご利用ください。
   ※本情報の内容（リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。