みなさま、こんにちは。System Center Support Team です。

今回は System Center Endpoint Protection (以下、SCEP) 、または Windows Defender をご利用の皆様に、System Center Configuration Manager (以下、SCCM) から定義ファイルを配信する上でできる限りクライアントがダウンロードされる容量を少なくする方法についてご紹介いたします。

まず、SCEP の定義ファイルにつきましては、2018 年 3 月 8 日現在、1 日に 6 回リリースされております。このように毎日頻繁にリリースされるため、SCCM で配信する場合は、次の公開情報の通り、自動展開規則の機能を使用して、定義ファイルを配信する必要があります。

定義ファイルの更新を配布するように自動展開規則を構成するには

自動展開規則を使用する場合、「プロパティ フィルター」を使用して SCCM に同期された更新プログラムから SCEP の定義ファイルだけを自動展開するように構成する必要がありますが、この設定においてクライアントにダウンロードされる容量を少なくするためのポイントがあります。それは「置き換えられる」を「いいえ」に設定することです。

「置き換えられる」を「いいえ」に設定しなかった場合、 SCEP 定義ファイルの展開は可能ですが、上述の通り 1 日 6 回リリースされますので、以下の通り 6 つの定義ファイルが展開されることになります。

定義ファイルを最新化するためには、最新の 1 つの定義ファイルのみダウンロードされればよいのですが、「置き換えられる」：「いいえ」を設定しなかった場合、最大で 6 つの定義ファイルがクライアントにダウンロードされることになります。これでも最新の定義ファイルのインストールが完了すれば、定義ファイルは最新化されますが、本来は 1 つの定義ファイルのみダウンロードすれば良いにもかかわらず、古い定義ファイルもダウンロードされることになりますので、適用までに時間を要する、もしくはクライアントと配布ポイント間のネットワーク トラフィックが増大する可能性があります。

そのため、もしクライアントと配布ポイント間のトラフィックにおいて、SCEP 定義ファイルのダウンロードにかかるサイズが大きくなっている場合は、上述の設定をすることで、低減できますのでご確認くださいますようお願いいたします。

また、SCEP 定義ファイルは 1 つの定義ファイルにつき、6 世代前までの差分の定義ファイルを持っておりますので、1 日複数回など頻繁に更新を行うことで、ダウンロードされる定義ファイルのサイズも少なくなります。こちらもクライアントと配布ポイント間のネットワーク トラフィックを低減させる方法の 1 つですので、ご検討くださいませ。

Participating in Microsoft certifications or programs will help your referrals.

Many customers are looking for qualified experts to help implement Microsoft technology and business solutions. Here at Microsoft, we often get direct requests for help from customers through our marketing activities and from our internal Microsoft sales agents. Customers also use the Find a solution provider experience to find companies that can help them meet their business needs.

We want to connect you with customers who need your solutions and expertise. The most important step you can take to start getting sales leads from us is to create a business profile that showcases your company's offerings, solutions, and expertise. Your business profile will be listed in all the places customers and internal Microsoft sales agents search for qualified partners.

After you publish your business profile, you'll start to receive sales leads through the Referrals feature in Partner Center. It's important to respond to referrals within the required time frames to continue to receive these leads and, most importantly, to win deals. See Respond to referrals for details about how to manage sales leads in Partner Center.

Learn more

Co je jazyk DAX?

Jazyk DAX je kolekce funkcí, operátorů a konstant, které lze použít ve vzorci nebo výrazu k výpočtu a vrácení jedné nebo více hodnot. Jednodušeji řečeno, jazyk DAX vám pomůže vytvořit nové informace z dat, která už jsou ve vašem modelu.

Pokud to s Power BI myslíme vážně, je nutné si uvědomit, že si nevyjdeme jen se surovými daty, ale budeme muset nad nimi provádět různé operace. Dnes si ukážeme, jak dopočítávat hodnoty pro jednotlivé řádky. A aby nám téma bylo bližší, vzal jsem aktuální čísla ze sklizně 2017 uveřejněné ČSÚ 16.2.2018 https://www.czso.cz/csu/czso/definitivni-udaje-o-sklizni-zemedelskych-plodin-2017

Připravil jsem si pro Vás trénovací data ke stažení: výnosyDAX soubor excelu a výsledný Power BI (zip) sklizeň

Ukázka importu dat.

Načtená data

Úprava dat

Odstranění prázdných řádků

Připravená data

Vytvoření vypočteného sloupce

Přidáme nový sloupec a zadáme tento vzorec

Pšenice celkem = List2[Pšenice jarní Plocha] + List2[Pšenice ozimá plocha]

Tím dostaneme součet plochy pšenice jarní a pšenice ozimé, pokud máme výsledek dobře, je možné to ověřit s hodnotou ve sloupci Pšenice celkem plocha

Stejným způsobem si vyzkoušíme sečíst Brambory ranné Plocha a Brambory ostatní Plocha  výsledek zde ovšem není shodný s Brambory celkem Plocha, zde je to vinou členění a v tabulce nejsou uvedeny všechny podkategorie.

Další vzorec co si vyzkoušíme, bude výpočet hektarového výnosu u pšenice tzn. Celková sklizeň / Celková plocha a výsledek je výnos v t/ha.

Stejný způsob vyzkoušíme u Brambor celkem

vynos brambory = List2[Brambory celkem Sklizeno]/List2[Brambory celkem Plocha]

Pevně věřím, že i tento krátký úvod do jazyka DAX Vám pomůže efektivněji využít nástroj Power BI.

S pozdravem Karel Rejthar – MIEE

Organizations using Windows Information Protection (WIP) may experience issues accessing the Intune Company Portal app.  Fortunately, exempting Intune Company Portal app and any other application from a WIP policy is straight forward.

To learn more about creating Windows Information Protection policies please visit: https://docs.microsoft.com/en-us/windows/security/information-protection/windows-information-protection/create-wip-policy-using-mam-intune-azure

Let’s get started

By exempting an application the following pertains:

If you're running into compatibility issues where your app is incompatible with WIP, but still needs to be used with enterprise data, you can exempt the app from the WIP restrictions. This means that your apps won't include auto-encryption or tagging and won't honor your network restrictions. It also means that your exempted apps might leak.

 

Source: https://docs.microsoft.com/en-us/windows/security/information-protection/windows-information-protection/create-wip-policy-using-mam-intune-azure#add-apps-to-your-allowed-apps-list

Since the Intune Company Portal App doesn’t store any sensitive company data, exempting it shouldn’t be an issue, however always check in with your security team to make sure.

The first step to exempting the Intune Company Portal App for Windows is to locate the app in the store.  I’ve done this for you below and even though the app may be accessed from the consumer and business store, all we really care about is the AppID at the end, i.e. “9wzdncrfj3pz”. 

As we can see, the AppID is the same regardless of what portal it was accessed from:

Windows Store Intune Company Portal app: https://www.microsoft.com/en-us/store/p/company-portal/9wzdncrfj3pz

 

Windows Store for Business Intune Company Portal app: https://businessstore.microsoft.com/en-us/store/details/company-portal/9wzdncrfj3pz

Creating the WIP exemption policy

To create an app policy within Intune to exempt the Intune Company Portal app navigate to portal.azure.com à Intune à Mobile Apps à App protection policies à Add a policy

1. Give the policy a name and select Exempt apps
2. Select Add apps
3. From the drop-down menu select Store apps

At this point you’ll need to have some information handy about the app.  Fortunately, there is an easy method of extracting this data using the URL below.  I’ve already accessed the URL below; however, you can do this for any store app to find the name, publisher info, and product name.

Access following and replace the ID with the ID of the app you’d like to exempt, in this case, the Intune Company Portal app ID: 9wzdncrfj3pz

 

https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/9wzdncrfj3pz/applockerdata

 

 

For more details about accessing app package info please visit: https://docs.microsoft.com/en-us/windows/client-management/mdm/get-product-package 

The following is the output you’ll see in the browser in JSON format:

{

  "packageFamilyName": "Microsoft.CompanyPortal_8wekyb3d8bbwe",

  "packageIdentityName": "Microsoft.CompanyPortal",

  "windowsPhoneLegacyId": "0b4016fc-d7b2-48a2-97a9-7de3b5ea7424",

  "publisherCertificateName": "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"

}

Now that we have the JSON information about the Intune Company Portal store app (using the URL above), we need to add that data to the policy as shown below. 

Once finished adding the information, select OK and assign the policy.  On the Windows device, either wait for your devices to sync with Intune of force a sync from Settings à Accounts à Access work or school.

Once the policy updates you’ll be able to access the Intune Company Portal app:

If you’re interested, I go into detail about WIP a previous post: https://blogs.technet.microsoft.com/cbernier/2017/05/19/windows-information-protection-explained-windows-10-creators-update/ 

That’s it, if you’re not utilizing Windows Information Protection today, I highly encourage everyone to look into the benefits of protecting corporate information across personal and corporate owned devices with Intune, including Windows, iOS, and Android.

Tim Tetrick

For people experienced with the AWS platform, it can be challenging to know how to get started on Azure.  One of our Microsoft Cloud Solution Architects, after discussing this with an experienced AWS developer at a recent User Group, thought it would be useful to pull together resources to help.  Please find his guidance below and you can also find his excellent original blog post here.

Overview of Azure for AWS Professionals

This article helps Amazon Web Services (AWS) experts understand the basics of Microsoft Azure accounts, platform, and services. It covers key similarities and differences between the AWS and Azure platforms in terms of structure, operations and architecture.

https://docs.microsoft.com/en-au/azure/architecture/aws-professional/

AWS to Azure services comparison

These links help you understand how Microsoft Azure services compare to Amazon Web Services (AWS). Whether you are planning a multi-cloud solution with Azure and AWS, or migrating to Azure, you can compare the IT capabilities of Azure and AWS services in all categories. Note that in some cases there are multiple Azure services listed for some AWS services. Some Azure services may appear similar to one another, but depth functional grouping and breadth of capabilities can vary.

https://docs.microsoft.com/en-au/azure/architecture/aws-professional/services

A downloadable version is also available at https://aka.ms/awsazureguide

Online Learning

Azure is a diverse and rich platform and as a result there is a variety of training resources available. The following free courses provide a good starting point for those with experience with the AWS platform.

Microsoft Azure Administration for AWS Administrators

Learn how to map AWS services to their Azure counterparts, and how to perform the most important AWS administrative tasks in Azure. Gain a well-rounded understanding of the similarities and differences between AWS and Azure.

• Free Pluralsight Course
• Hands on Lab

Microsoft Azure Architecture for AWS Architects

This course provides an easy to consume, yet critical way as an AWS architect to translate your knowledge to Azure. This will enable you to architect Azure-based solutions with minimal relearning.

• Free Pluralsight Course
• Hands on Lab

Getting hands on for Free

The best way to learn is by doing and the best type of doing is free. You can sign up for a free Azure account that will give you what you need to get started actually deploying and running solutions in Azure. Just head over to https://azure.microsoft.com/en-us/free/ to register for your free Azure Account. This will provide you with $260 of credit for first 30 days, 12 months of popular free services and more than 25 services that are always free.

Then head over to https://azure.microsoft.com/en-us/tools/ to download all the free Developer Tools, SDK's and command-line utilities you need.

弊社では、来たる 2018 年 7 月に、米国 ラスベガス にて、全世界のパートナー企業の経営者様およびセールス & マーケティングご担当者様を対象とした弊社最大規模のパートナー イベント 「Microsoft Inspire」 を開催する運びとなりましたので、ここにご案内申し上げます。

Microsoft Inspire では、「Where the world meets to transform business」をテーマにパートナー様とマイクロソフトが 「Connect」、「Learn」、「Collaborate」し、デジタルトランスフォーメーションを加速させクラウド ビジネスの利益性が最大限にどのように高められるのか、継続したビジネスの成長のための新しい機会はどこにあるのか、明確に定義されたビジョンを持って必要とされているビジネス ニーズを満たすための課題、他社との差別化の必要性、パートナーシップの重要性など、変化する市場の動向を逃さないためにどのように変革していくのかについて、パートナー様にとって有意義なご提案をさせていただきます。

本年は、7 月 15 日から 19 日まで、5 日間にわたり、弊社のビジョン、戦略、製品、それらをベースとしたソリューション情報ならびに業界情報などを、製品、セールス、そしてマーケティングの観点から、盛りだくさんのブレイクアウト セッション、ハンズオン トレーニング、展示会を通じて、具体的な情報をご提供いたします。パートナー様のビジネス機会につながる最新かつ実践的な情報をご提供し、パートナー様と共にビジネスの拡大を目指したいと思っております。

あわせて、弊社トップ エグゼクティブによる基調講演にて、最新の方針や戦略をパートナー様と共有させていただきます。また、140 ケ国以上から 17,000 名を超えるパートナーの皆様が一堂に会することにより、ビジネス情報交換の場としても非常に貴重な機会を創出します。日本の重要なパートナー企業の皆様に弊社の世界規模の一大イベントにご参加いただくことで、今後のビジネス推進の一助となることを願っております。

ご多用中とは存じますが、ぜひご参加のご検討を賜りますよう、心よりお願い申し上げます。

日本からご参加のパートナー様向け参加ツアーの詳細につきましては、以下のサイトよりご確認いただき、2018 年 5 月 11 日（金） 17:00 まで に参加お申し込みを完了ください。

▼  Inspire 2018 ツアーのお申し込みはこちらから

いつも Exchange Server をご利用いただきありがとうございます。
今回は、Exchange 2013 の Outlook Web App (OWA) 上で、ユーザーの写真を登録、変更する操作を有効化または無効化する方法と、その設定方法に関する TechNet 上の記載についてご案内します。

Exchange 2013 の OWA では、ユーザーの写真を登録する方法として以下の 2 つの操作方法が実装されています。

 操作 A: OWA 右上のユーザー名をクリックして変更する方法
 操作 B: OWA 右上の歯車アイコンをクリックしてオプション画面より変更する方法

これらの操作は、Exchange 2013 ではそれぞれ独立した処理として実装されており、操作 A が OWA 仮想ディレクトリの設定により制御され、操作 B は OWA メールボックス ポリシーにより制御されます。
このため、Set-OwaVirtualDirectory コマンドによりクライアント アクセス サーバーの OWA 仮想ディレクトリの SetPhotoEnabled パラメーターを False に設定した場合、操作 A による写真の変更操作が無効化されますが、操作 Bによる写真の変更操作は無効化されません。
その逆に、Set-OwaMailboxPolicy コマンドにより OWA メールボックス ポリシーの SetPhotoEnabled パラメーターを False にして操作 B による写真の変更操作を無効化しても、操作 Aによる写真の変更操作は無効化されません。

これは Exchange 2013 の想定された動作となり、変更することができませんので、何卒ご理解くださいますようお願い申し上げます。

なお、本ブログ公開時点では TechNet 上のそれぞれのコマンドの SetPhotoEnabled パラメーターの説明は下記の通り同じ内容の説明文となっており、いずれかのコマンドで写真の変更操作を無効に設定すれば、操作 A および操作 B のいずれも無効化できるように読み取れます。
 
Set-OwaVirtualDirectory および Set-OwaMailboxPolicy の SetPhotoEnabled に関する説明抜粋
「SetPhotoEnabled パラメーターは、ユーザーが Outlook Web App で送信者の写真を追加、変更、削除できるかどうかを指定します。このパラメーターの有効な値は、$true または $false です。既定値は $false です。この値を $true に設定すると、ユーザーは 2 つの方法で送信者の写真を管理できるようになります。ユーザーは Outlook Web App の右上で名前をクリックし、[変更] をクリックしてから、使用する写真を参照します。Outlook Web App の右上にあるギア アイコンをクリックしてから、[オプション] > [アカウント] > [マイ アカウント] > [編集] > [変更] の順にリックして、写真を管理することもできます。」
 
しかし、実際の Exchange サーバーでは上述の通りそれぞれのコマンドにより無効化できる操作方法が限定されているため、この記述は誤りとなります。
さらに、「既定値は $false です。」との記載となっておりますが、この点も誤りとなり、既定値は $true で写真の変更操作が可能な値となります。

TechNet の記載をご参考にしていただいた管理者様には誠に申し訳ございませんが、上記に記載の通りの動作となりますことをご承知おきくださいますようお願いいたします。
引き続き、公開文書の正確性の向上に努めてまいりますので、今後ともご愛顧を賜りますよう、何卒よろしくお願い申し上げます。
 
参考情報
Title: Set-OwaVirtualDirectory
URL: https://technet.microsoft.com/ja-jp/library/bb123515(v=exchg.150).aspx

Title: Set-OwaMailboxPolicy
URL: https://technet.microsoft.com/ja-jp/library/dd297989(v=exchg.150).aspx

こんにちは。Exchange サポートの小間です。今回は EWS Managed API で「うるう日」をまたぐ予定表アイテムの取得を行う際の注意点を紹介します。

本ブログ執筆時点の次のうるう日は 2020/02/29 なので、例として 2018/03/01 からうるう日の翌日の 2020/03/01 までの 2 年分の予定表アイテムを取得するシナリオを考えます。C# と EWS Managed API で実装する場合は、以下のようなコードがまずは思い浮かびます。
 

          ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2013_SP1);
          service.Credentials = new WebCredentials("UPN", "password");
          service.Url = new Uri("https://outlook.office365.com/EWS/Exchange.asmx");

          DateTime startDate = new DateTime(2018, 3, 1, 0, 0, 0);
          DateTime endDate = startDate.AddYears(2);
          const int NUM_APPTS = 1000;

          CalendarFolder calendar = CalendarFolder.Bind(service, WellKnownFolderName.Calendar, new PropertySet(BasePropertySet.IdOnly));
          CalendarView cView = new CalendarView(startDate, endDate, NUM_APPTS);
          cView.PropertySet = new PropertySet(
              AppointmentSchema.Subject,
              AppointmentSchema.Start,
              AppointmentSchema.End);

          FindItemsResults<Appointment> appointments = calendar.FindAppointments(cView);

 
一見このコードは問題がなく、2018/03/01 から 2020/03/01 までの 2 年分の予定表アイテムを取得するように思えますが、実際にこのコードをタイムゾーンが日本時間に設定された端末上で実行すると「The specified view range exceeds the maximum range of two years.」というメッセージとともに失敗します。FindAppointments の実行時には開始日と終了日が最大 2 年となる制限がありますが、その制限を超えたリクエストが行われているためです。

タイムゾーンの変換の影響を受けた結果、このような動作になっています。コード上で指定した時間がローカル時間として扱われ、EWS Management API が UTC 時間に変換をして SOAP リクエストを送信した結果、2 年を超えてしまっています。もう少し詳しく見てみましょう。

開始日として指定したのは「new DateTime(2018, 3, 1, 0, 0, 0)」で、これをローカル時刻である日本時間であると仮定すると日本時間 2018/03/01 0:00:00 ですが、UTC 時間では 2018/02/28 15:00:00 となります。そして終了日として指定したのは開始日の 2 年後ですが、これも日本時間であると仮定すると日本時間 2018/03/01 0:00:00 になります。これを UTC 時間で表現するとうるう日である 2020/02/29 15:00:00 となります。つまり実際に送信される SOAP リクエスト上では 2018/02/28 15:00:00 から 2020/02/29 15:00:00 までの予定表アイテムをリクエストしていることになり、これは 2 年と 1 日ということになります。結果として 2 年を超えているためエラーになります。

対処策としては、タイムゾーンを意識した時間の指定を行うことです。コードを以下のように変更することでエラーなく 2018/03/01 から 2 年分の予定表アイテムを取得できます。
 

          ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2013_SP1);
          service.Credentials = new WebCredentials("UPN", "password");
          service.Url = new Uri("https://outlook.office365.com/EWS/Exchange.asmx");

          DateTime localStartDate = new DateTime(2018, 3, 1, 0, 0, 0, DateTimeKind.Local);
          DateTime utcStartDate = localStartDate.ToUniversalTime();
          DateTime utcEndDate = utcStartDate.AddYears(2);
          const int NUM_APPTS = 1000;

          CalendarFolder calendar = CalendarFolder.Bind(service, WellKnownFolderName.Calendar, new PropertySet(BasePropertySet.IdOnly));
          CalendarView cView = new CalendarView(utcStartDate, utcEndDate, NUM_APPTS);
          cView.PropertySet = new PropertySet(
              AppointmentSchema.Subject,
              AppointmentSchema.Start,
              AppointmentSchema.End);

          FindItemsResults<Appointment> appointments = calendar.FindAppointments(cView);
 
このコードでは、まずは時間がローカル時間であることを明示して DateTime のオブジェクトを作成し、その上で UTC 時間に変換したものを開始日として使用しています。終了日についても、UTC 時間に変換した開始日に 2 年足した値を使っています。そのため SOAP リクエスト上では 2018/02/28 15:00:00から 2020/02/28 15:00:00 までのちょうど 2 年の予定表アイテムを取得するリクエストになり、エラーは発生しなくなります。なおユーザーの視点では、日本時間の 2018/03/01 から 2 年分の予定表アイテムを取得したにも関わらず 日本時間の 2020/02/28 までの情報しか取得できていないように見えてしまいます。そのため追加で日本時間 2020/02/29 の予定も取得する必要があります。

予定表アイテムを扱う際にはタイムゾーンの違いを考慮した開発を行うことで、ご紹介したようなうるう日のシナリオ以外でも予期せぬ問題を未然に防ぐことができますので参考になりましたら幸いです。

今後も当ブログおよびサポート チームをよろしくお願いいたします。
 
※サンプル コードについて
掲載されているサンプル コードは本ブログ記事の説明のための部分コードであり、弊社にてその動作を保証するものではございません。
ご使用の際にはお客様のシステムに合わせて修正していただき、十分なテストを実施していただきますようお願いいたします。
なお、サンプル内で使用しておりますコードの詳細な情報に関しては、Microsoft Docs や MSDN などをご参照くださいますようお願いいたします。
 
※ 本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

(この記事は 2018 年 3 月 6 日に Outlook Blog に投稿された記事 OWA mobile apps to be retired in May の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

このたびマイクロソフトは、OWA (Outlook Web App) for iPhone/iPad/Android の提供を終了することを発表いたします。マイクロソフトは過去数年間にわたり、iOS および Android デバイス用の Outlook ネイティブ アプリにおけるユーザー エクスペリエンスの改善とセキュリティの強化に力を注いできました。Outlook は、皆様からのフィードバックを基に改良を重ね、モバイル デバイスで Office 365 の機能を使用するうえで最適なアプリとして、高い評価を得ています。OWA モバイル アプリの提供終了に伴い、今後は次のプロセスを通じて、ユーザーの皆様の Outlook への移行をサポートします。

• 2018 年 4 月より、OWA for iPhone/iPad/Android は iTunes Store および Google Play ストアでダウンロードできなくなります。
• また、2018 年 4 月より、OWA モバイル アプリのユーザーに、アプリの提供終了日と Outlook for iOS/Android のダウンロード ページへのリンクをお知らせするメッセージが、アプリ内で繰り返し表示されるようになります。
• 2018 年 5 月 15 日より、OWA モバイル アプリの使用ができなくなります。Office 365 のユーザーがアプリを開こうとすると、Outlook for iOS/Android のダウンロードを促すメッセージが表示されます。

Outlook for iOS/Android への移行は簡単です。詳しい手順は、こちらのガイドをご確認ください。本日 Office 365 のメッセージ センターで通知を受信した Office 365 管理者の皆様は、組織内に OWA モバイル アプリを使用しているユーザーがいらっしゃるということなので、所定のご対応をお願いいたします。メッセージ センターで通知を受信していない場合は、ご対応いただく必要はありません。OWA モバイル アプリの提供終了に関する詳細や不明点については、こちらの記事をご覧ください。

Outlook for iOS/Android は、Microsoft Cloud で完全に動作するアーキテクチャとなっており、各種アプリ ストアでは星 4.5 以上の評価を獲得しています。今後マイクロソフトは、モバイル製品ポートフォリオの合理化に伴い、エンタープライズ クラスのメール、予定表、検索機能を業界最高レベルで提供し、モバイル デバイスで Outlook を使用して Office 365 の機能を最大限に活用できるよう、重点的に取り組んでまいります。

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

Azure Site Recovery 是許多 Azure 客戶業務連續性策略的重要部分。客戶靠 Azure Site Recovery 來保護其重要 IT 系統、維護合規性，並確保其業務在發生災難時不會受到不利影響。

運行業務連續性計畫，並確保此計畫符合您組織的業務連續性目標是非常複雜的。了解計畫是否有效的唯一方法是做定期測試。即使做了定期測試，也依然無法完全確定它下一次可以無縫運作，因為可能有其他因素影響，例如：配置飄移 (configuration drift) 與資源可用性 (resource availability)。

在我們看來，監控不應如此困難。Azure Site Recovery 中的全面監控功能讓您可以從各方面了解業務連續性目標是否獲得滿足。此外，透過故障預備模型 (failover readiness model) 可以監控資源可用性，並根據最佳實踐效果提出配置建議，還可以協助告知您，如何準備好應對當前災難。

那麼，現在我們一起來看看有那些新功能吧~~!!

• 更完善的儲存庫概觀頁面：新的儲存庫概觀頁面包含一個儀表板，它展示了您需要了解的所有訊息，讓您可以知道您的業務連續性目標是否獲得滿足。除了解業務連續性計畫現階段運行狀況的資訊外，儀錶板內也會提供能展現最佳效果的建議，並內建可用於解決您潛在故障問題的工具。
• 複寫運行狀態模型：基於對各種複寫參數的評估、持續且即時地監控伺服器的複寫作業運行狀況。
• 簡化的疑難排除使用經驗：從儲存庫儀表板開始，使用直觀的導航體驗進一步深入了解各個組件，以及其他故障排除工具（包括用於複寫機器的全新儀表板）。
• 深入檢測異常問題的工具可用於偵測錯誤，並為修復提供規範性指導。

透過一流的監控，Azure Site Recovery 可為企業提供災難保險，並採用災難復原策略，在您最需要災難復原時，您可以使用它。

您可以觀看以下 demo 影片，來探索這個新的使用者體驗：

您可以從我們的文件中了解更多關於利用 Azure Site Recovery 進行監控和故障排除的訊息。

Azure Site Recovery 是一項涵蓋您遷移和災難復原需求的全方位服務。我們的任務是利用 Microsoft Azure 的強大功能實現災難復原民主化，以便讓您擁有涵蓋組織所有 IT 應用程式的災難復原計畫。

現在開始試用 Azure Site Recovery 吧!!!

いつも弊社製品をご利用いただきまして誠にありがとうございます。
Windows プラットフォーム サポートの吉永です。

今回は弊社にお問い合わせいただきました “記憶域スペースにて作成いただいた仮想ディスク” がメンテナンスに伴うデタッチの実施後や、サーバー再起動実施後に正しくアタッチが行われなかった場合に、それ以降自動でのアタッチが行われなくなるという点についてご紹介させていただきます。

なお、記憶域スペースは Windows Server 2012 / Windows 8 からの新機能となっており、ソフトウェア定義ストレージ (ディスクの仮想化) 機能を提供しております。
複数の物理ディスクをプールとして管理し、その中から必要な容量の仮想ディスクを切り出して利用することで、物理ディスクを複数束ねて、物理ディスクの容量以上のディスクを利用したり、I/O の負荷を分散させたり、また、物理ディスクの耐障害性などを実現することができます。
詳細については、以下の情報をご参照ください。

<参考情報>
記憶域スペースの概要
URL : https://technet.microsoft.com/ja-jp/library/hh831739(v=ws.11).aspx

記憶域スペースを用いて仮想ディスクを作成いただいた場合、作成したディスクはサーバーにアタッチ (接続)した状態でご利用いただくこととなります。
また、標準では、自動でのアタッチが有効になっているため、サーバーの再起動などを実施いただいた場合についても、サーバー起動時に自動でアタッチされる動作となっております。

しかしながら、この 「自動でのアタッチが突然行われなくなったと」 いったお問い合わせをいただくことがございますが、これは作成いただいた仮想ディスクの IsManualAttach と呼ばれる属性による動作となります。

IsManualAttach 属性について

IsManualAttach は仮想ディスクのアタッチを手動で実行するかどうかの属性です。
この属性については、以下の 2 通りの属性がございます。

<IsManualAttach : False>
> 手動でのアタッチが無効の状態。
そのため、サーバー再起動時には自動でのアタッチが行われます。

<IsManualAttach : True>
> 手動でのアタッチが有効の状態。
そのため、サーバー再起動時には自動でのアタッチは行われません。

なお、上記の属性については、 Get-VirtualDisk コマンドにて確認が可能です。

■ 実行コマンド
Get-VirtualDisk |fl

■ 実行例
IsManualAttach : False (or True)
-------------------- Get-VirtualDisk |fl 実行例より抜粋 --------------------
FriendlyName : 記憶域階層
HealthStatus : Healthy
Interleave : 262144
IsDeduplicationEnabled : False
IsEnclosureAware : False
IsManualAttach : False >>>>> こちらのステータスが対象となります。
------------------------------------------------------------------------------

IsManualAttach 属性が変更される動作について

上記の IsManualAttach属性については、仮想ディスク作成時の規定では、 IsManualAttach : False となっているため、サーバー再起動時にも自動で仮想ディスクのアタッチが行われます。
ただし、以下のようなシチュエーションが発生した場合、IsManualAttach の属性が False から True に変更されます。

<手動でのデタッチを行った場合>
> サーバーマネージャーなどから手動でのデタッチを行った場合、 IsManualAttach の属性は False から True へと変更されます。
なお、デタッチを行ったのち、同様にサーバーマネージャーなどから手動でアタッチを行っても、IsManualAttach 属性は False のままとなります。

<サーバー再起動時などに自動でのアタッチに失敗した場合>
> IsManualAttach が無効で自動でのアタッチが行われる環境において、サーバー再起動時などにディスクへの接続を行うことができず、自動でのアタッチに失敗した場合、 IsManualAttach の属性は False から True へと変更されます。
そのため、そのままの場合については、自動でのアタッチは行われません。

IsManualAttach 属性が False から True になるシチュエーションについては、上記の通りとなりますが、True へと変更された属性は、自動的に False に戻ることはございません。

対処策

先述させていただきましたように IsManualAttach は一度 True に変更されると、それ以降 False に戻ることはございません。

そのため、メンテナンスなどに伴い手動でディスクのデタッチを行った場合や、何らかの障害により、自動でのアタッチが行われなかった場合などのシチュエーションが発生した場合については、それ以降自動でのアタッチが行われなくなります。

よって、これらの状態を回避されたい場合については、以下の方法にて対応をいただければと存じます。

1. 作業後に IsManualAttach 属性の変更を行う

   メンテナンスなどに伴い、手動でのデタッチを行う場合は、作業終了後、以下のコマンドにて IsManualAttach 属性の変更を行うことで、自動でのアタッチを再度有効にすることが可能となります。
   実行コマンドは以下となります。

   <IsManualAttach を有効にする>
   Set-VirtualDisk -FriendlyName <仮想ディスクのフレンドリ名> -IsManualattach $True

   <IsManualAttach を無効にする>
   Set-VirtualDisk -FriendlyName <仮想ディスクのフレンドリ名> -IsManualattach $false

2. スタートアップ プログラムとして、アタッチ コマンドを実施する

   意図せず、手動でのアタッチが有効となり、それ以降自動でのアタッチが行われないことを避けるためには、スタートアッププログラムとして、アタッチ コマンドを実行させることで、 IsManualAttach 属性にかかわらず、毎回コマンドによるアタッチを行うことが可能となります。
   実行コマンドは以下となります。

   ■ 実行コマンド
   connect-VirtualDisk -FriendlyName <仮想ディスク名>

   ■ ステータス
   アタッチされた場合にも、戻り値などはございません。
   また、すでにアタッチされている場合についても、同様に戻り値はございません。
   なお、実行結果については、前述させていただきました “Get-VirtualDisk |fl” にて確認が可能でございます。

   ■ 実行例
   PS C:UsersAdministrator> connect-VirtualDisk -FriendlyName 記憶域階層
PS C:UsersAdministrator>

注意事項

先述させていただきましたように IsManualAttach が True になる要因については、何かしらの要因により、自動でのアタッチを行えなかった場合と、手動でのアタッチを行った場合となります。

そのため、”スタートアップ プログラムとして、アタッチ コマンドを実施” いただく場合については以下の点にご注意いただく必要がございます。

• スタートアップ プログラムにて、コマンドによるアタッチを実施いただく場合についても、当該のディスクへのアクセスを行うことが出来ない場合については、アタッチが行われません。
• 通常、IsManualAttach が True になった場合については、手動でのデタッチが行われた、もしくは自動でのアタッチを行えなかった場合となるため、自動でのアタッチが実施されなくなった場合はそれらの要因が発生したことを認識いただくことが可能となります。
  ただし、IsManualAttach の属性に限らず、コマンドによるアタッチを実施した場合については、 IsManualAttach の属性の変化を検知することが出来ない場合がございますので、その点についてはご留意いただく必要がございます。

以上のことより、毎回自動でアタッチが実施されないと運用上影響が発生する場合については、上記の内容を踏まえ、スタートアップ プログラムとして、アタッチ コマンドを実施するかどうかについてご検討いただけますと幸いです。

本ブログが少しでも皆様のお役に立てますと幸いです。

執筆者: John 'JG' Chirapurath (General Manager, SQL Server & Azure Data Services)

このポストは、2018 年 3 月 5 日に投稿された Gartner reaffirms Microsoft as a leader in Data Management Solutions for Analytics の翻訳です。

このたびマイクロソフトは、Gartner が発表した 2018 Magic Quadrant for Data Management Solutions for Analytics (DMSA、英語) で再び「リーダー」に選出されました。また、Magic Quadrant for Analytics and Business Intelligence Platforms (英語) と Magic Quadrant for Operational Database Management Systems (英語) でも「リーダー」に選出されています。これはマイクロソフトのグローバルなリーダーシップ、そしてデータ資産に関する徹底した取り組みが評価された重要なマイルストーンです。

Gartner の定義では、DMSA は、単一または複数のファイル管理システム (通常、データベース) をサポートしデータを管理する完全なソフトウェア システムです。DMSA には、リレーショナルな処理、リレーショナルではない処理 (グラフ処理など)、機械学習、Python や R などのプログラム言語など、分析処理をサポートする各種の最適化が含まれます。

出典: Gartner (2018 年 2 月)*

マイクロソフトは、ビッグ データ プラットフォームを進化させ、分析を簡素化して利用しやすくすることに積極的に取り組んでおり、データからインテリジェントなアクションを導き出す作業を支援しています。具体的には、これを SQL Server 2017 および主要な Azure サービスである Azure SQL Data Warehouse (フル マネージド型 MPP アーキテクチャのクラウド データ ウェアハウス)、Azure Databricks (Apache Spark をベースとする分析プラットフォーム)、Azure HDInsight (フル マネージド型オープン ソース分析プラットフォーム) などで実現しています。

強力なビッグ データ ソリューションおよびデータ ウェアハウス ソリューションを構築するプラットフォームとしてマイクロソフト製品をお選びいただくメリットは次のとおりです。

生産性: SQL、Spark、Hadoop、フルマネージド型クラウド サービスを業界最高レベルでサポートしているため、データ ウェアハウスや Spark 環境をわずか数分で、ワンクリックでプロビジョニングできます。また、30 種類以上のネイティブなデータ コネクタによりデータ統合を促進できるほか、データ サイエンティスト、データ エンジニア、ビジネス アナリストのそれぞれが好みのツールや言語を使用することができます。こちらでは実際の事例として、Rockwell 社がどのようにして市場投入期間を 80% 短縮し、コストを削減し、顧客対応を改善したかをご覧いただけます。

ハイブリッド: SQL Server のパフォーマンスとセキュリティを、プライベート クラウドや Azure のマネージド サービスで一貫して利用できるのは、マイクロソフト製品だけです。また、Azure で SQL Server Integration Service パッケージを実行すると、既存のデータ変換の管理のコスト削減や簡素化を実現できるというメリットもあります。このほか、オンプレミスと Azure で共通の ID を使用し、一貫したユーザー エクスペリエンスを実現することもできます。Carnival 社では、ハイブリッド ソリューションを構築して船舶での清水の使用量を予測し、1 隻あたり年間 20 万ドルのコストを削減しました。その詳細はこちら (英語) でお読みいただけます。

インテリジェント: オンプレミス、クラウド、ハイブリッドの各環境での機械学習モデルの構築やデプロイを柔軟に実施できます。また、マイクロソフトやオープン ソースのサポートが充実しているため、お好みのデータ サイエンス ツールを使用できます。このほか、Power BI やその他の最先端の BI ツールとの統合も充実しているため、社内全体に容易にインサイトを配信できます。ASOS.com では、1,300 万のパーソナライズされたエクスペリエンスを配信し、秒間 33 件の注文に対応しています。その詳細はこちら (英語) でお読みいただけます。

信頼性: 暗号化、監査、脅威検出、Azure Active Directory、VNET など、高度な組み込みのセキュリティ機能が提供されます。また、Azure では世界 42 のリージョンで各業界や各地域のコンプライアンスに準拠するサービスを 50 以上提供しており、どこからでもデータを確認できます。このほか、返金制度付きの SLA が適用されるため、安心してご利用いただけます。GE Healthcare 社は、Azure のデータ サービスを利用して同社の重要なソリューションを配信しています。その理由はこちら (英語) でお読みいただけます。

Azure SQL Data Warehouse では、管理コストを削減しながら分析能力を大幅に向上させることができます。マイクロソフトは、Forrester Consulting に委託して総合経済効果 (Total Economic Impact: TEI) 調査 (英語) を実施し、各企業がクラウドにデータを移行した結果の詳細について調べました。この業界におけるマイクロソフトのリーダーシップについては、Gartner の 2018 Magic Quadrant for Data Management Solutions for Analytics レポートでもご確認いただけます。

*このグラフは、より大規模な調査ドキュメントの一部としてガートナーから発表されたものであり、そのドキュメント全体の文脈において解釈されるべきものです。ガートナーの発行物は、リクエストによりマイクロソフトからご提供することが可能です。ガートナーは、ガートナー・リサーチの発行物に掲載された特定のベンダー、製品またはサービスを推奨するものではありません。また、最高のレーティングまたはその他の評価を得たベンダーのみを選択するようテクノロジの利用者に助言するものではありません。ガートナー・リサーチの発行物は、ガートナー・リサーチの見解を表したものであり、事実を表現したものではありません。ガートナーは、明示または黙示を問わず、本リサーチの商品性や特定目的への適合性を含め、一切の保証を行うものではありません。

Josh and Sarah over on the EMS blog just posted a great article on using GraphAPI to automate the deletion of stale devices from Intune - check out the details here: https://blogs.technet.microsoft.com/smeems/2018/03/07/device-cleanup-with-graph-api/

What is DEP?

The Device Enrolment Program (DEP) helps businesses and education institutions to automatically enrol their devices into Intune. You can also configure the Enrolment Profile in Intune to skip certain Setup Assistant screens, so users can start using their devices soon after unboxing them and wouldn’t need to enrol them manually.

Has anything changed?

Starting with iOS 11, all iOS devices, no matter where they have been purchased, may be enrolled via DEP. This blog posts covers the steps required to enrol these devices in Intune.

Here are some of the requirements:

• An Apple DEP account, to create a new account, go to deploy.apple.com and create your program account. You will need to provide an email address associated with your business. If you have an existing DEP account, please skip this step
• A macOS with Apple Configurator2 Version 2.5 or above installed
• An iOS device with iOS 11 or above

Step 1:

Configure DEP enrolment and create an Enrolment Profile in Intune. See https://docs.microsoft.com/en-us/intune/device-enrollment-program-enroll-ios. Follow steps under the following sections and skip the steps to upload serial number and assigning them to a MDM server in the DEP portal. If DEP enrolment is configured already and an Enrolment Profile exists, please skip this step

• Get the Apple DEP token
• Create an Apple enrolment profile

Step 2:

Remove your iOS device from Find My iPhone using Find My iPhone on iCloud.com to turn off the Activation Lock. It will be managed via Intune once the device is enrolled. You can also turn this off via Settings on the device. If you are going to use a new device, this step can be skipped.

Step 3: 

Create a mobileconfig file in Apple Configurator (AC) that has details to automatically connect to a Wi-Fi network. You will need it later. In AC, click on File-New Profile- Wi-Fi -Configure-Enter details such as SSID, Proxy, Security Type etc. and save it.

Step 4:

Connect iOS device to macOS and open Apple Configurator2. Device should now be visible under All Devices Tab. Click on the device and now Prepare should light up.

Step 5:

Click on Prepare - Select Manual Configuration - Add to Device Enrollment Program - Next. All other settings are optional

Please note the new functionality only allows you to add the device to DEP in Apple portal. Rest of the steps such as assigning them to MDM server and assigning profiles in Intune on Azure portal would still need to be performed.

About Activate and complete enrollment setting:

Don’t tick “Activate and complete enrollment” if it's a new device and if the desire is device starts up to the Setup Assistant, and the user completes the enrollment.

Tick “Activate and complete enrollment” If it's an existing device that already has a record in Apple DEP and Intune, and Enrollment Profile has been assigned to it in Intune.

Step 6:

• In Enroll in MDM Server dialog box, Click on Next

• In Define an MDM Server dialog box, Enter Name and URL, and click on Next

URL: https://appleconfigurator2.manage.microsoft.com/MDMServiceConfig?id=<Intune_tenant_ID>&AADTenantId=<AAD_tenant_ID>

If Intune and AAD tenant ID are not known, alternatively, you can create a test Apple Configurator profile in Intune console and export it to grab the URL. See Export the Profile section here

• Select Baltimore CyberTrust Root and click on Next

Step 7:

If you are doing this for the first time, you will be presented with following screen. Click on Next

Step 8:

Enter Apple DEP account details and click on Next

Step 9:

In Create an Organization dialog box, select Generate a new supervision identity and click on Next

Step 10:

In Configure iOS Setup Assistant, Choose any of the three options available in drop down. These settings will be controlled by Intune once Enrollment Profile is pulled by device. Click on Next

Step 11:

In Choose Network Profile dialog box, choose the mobileconfig file you created in Step 3 and click on Prepare

Step 12:

Enter macOS creds and click on Update Settings

Step 13:

Device will now restart. It may take some time before this happens.

Note: If Activation Lock was not turned off, Apple Configurator will throw an error at this stage saying, "The device may be activation locked". In the test I performed it failed once as device was locked. I had to unlock it and go through the entire process again.

When it finishes and if you don't see any errors in AC, on the device, you will see Setup Assistant and will be asked to select language. Do not select anything yet. At this point in time, your device should have been added to DEP.

Step 14:

Go to deploy.apple.com and enter your creds. Under Device Enrollment Programme - Manage Servers, you will now see a new MDM server in the list called "Device Added by Apple Configurator 2". Click on it and in the top right corner, click on Download Serial Numbers. Open the csv file. Confirm Serial_No matches with what you see on the back of the device. Copy the serial number and click on OK

Step 15:

In Apple DEP portal, Click on Manage Devices and paste the Serial Number. Assign it to MDM server linked with DEP Enrollment configuration in Intune. Click on OK and OK

Step 16:

Go to portal.Azure.com - Intune - Device enrollment - Apple enrollment - Enrollment Program Devices. Under Enrollment Program Devices blade - click on Sync - Request Sync. Wait for a few minutes and refresh Enrollment Program Device blade. You should now see the device added to Intune.

Step 17:

Select the newly added iOS device and click on Assign Profile. Choose the Enrollment Profile and click on Assign at the bottom of the blade. This step is important.

Step 18:

If the sync run in Step 17 is still running wait for it to finish and initiate a new sync. Wait for new sync to finish.

Step 19:

On the device, select Language - Country - Connect to Wi-Fi - Next - You should now see a screen saying Remote Management - Click on Next

Notice the Leave Remote Management option at the bottom of the screen. User can click on it to cancel the enrolment and use it as a regular device. Once the device is enrolled, user would have the ability to unenroll it within next 30 days. After 30-day grace period, device will be locked to DEP.

Step 20:

Enter the creds if you enabled User Device Affinity in the Enrollment Profile. Depending upon what settings were configured in Enrollment Profile, Setup Assistant will take you to Homescreen.

Device should now be in supervised mode and enrolled in Intune. Check the Management Profile under General - Device Management on the device.

From Intune on Azure portal:

~ Karan Rustagi | Senior Service Engineer | https://blogs.technet.microsoft.com/karanrustagi/

213 Microsoft Team blogs searched, 47 blogs have new articles. 455 new articles found searching from 01-Feb-2018 to 28-Feb-2018

BlogMS-Monthly-Report-February-2018

This is the final Module for  the Skype for Business Broadcast Series - but we are still not finished with the Skype for Business Online Meeting Series so stay tuned for more.

Up until now we have focused on Video only within a Skype for Business Broadcast Meeting, to finish up this series we will show you how to add content to a broadcast.

When mixing video and PPT content, the presenters are given new presentation options. While it is not all that difficult to figure out, sometimes its just easier to see first hand.

So, with that in mind, we will jump right into a Broadcast already in progress.

 So here we are in a meeting as a Presenter, Our Video is already active and we are broadcasting.

And from the attendee side, we see that Video is active.

So now the Presenter can add a PPT. By clicking the content icon (seen below), you have the option to "Share PowerPoint files". Select this option and then select a PowerPoint presentation to upload.

Once the Powerpoint is loaded, we have new options from a display point of view. “Video Only”, “Video and Content”, and “Content Only”. We have already covered “Video Only”, no need to show it again.

Though the PowerPoint is displaying on the Presenter's window, it has not yet been broadcast to the meeting. WE will need to select a layout that allows the PowerPoint to be seen by attendees.

Selecting "Content only" gives us the view below.

Selecting “Video and Content”, will add a smaller Video window to the right of the content. This way not only can the attendee see the content, but the Presenter as well to allow for a more personalized experience as well as taking non-verbal queues from the Presenter now that you can see him/her.

There are no other views to discuss, so the meeting may continue until its normal end. Like before though, if for any reason the Broadcast is stopped, the it is over and cannot be restarted. Once you are finished with the Broadcast, you would then click the “Stop Broadcast” button and then exist the meetings.

Thanks you for taking the time to go thru the Skype for Business Broadcast meeting blog. I hope that you have learned at least one thing from this Skype for Business Broadcast Series. Please feel free to ask questions, or post comments.

Enjoy your Broadcast meetings.

Here is another case from the "Tales of the Weird and Unusual" bin here from your Support Escalation team at Microsoft Exchange Support.  Over the last couple of weeks we have seen a few cases where customers are reporting very high memory utilization within their Exchange 2016 environments, however the catch is all of these customers were running on Windows Server 2016.  While memory utilization on Exchange can sometimes take a very serious note in several cases we were seeing where customers were adding in additional RAM into their environments, but still seeing high memory utilization or we were seeing the servers complain about not having enough memory.  As a result, we would also see excessive system paging.  We may even see error messages in our application logs such as the following:

Time: 1/2/2018 1:15:00 PM
ID: 906
Level: Warning
Source: ESE
Machine: MBX01.contoso.com
Message: Information Store - MBXDB1  A significant portion of the database buffer cache has been written out to the system paging file. This may result in severe performance degradation.
See help link for complete details of possible causes.
Previous cache residency state: 100% (4657 out of 4657 buffers) (867 seconds ago)
Current cache residency state: XX% (XXXX out of XXXX buffers)
Current cache size vs. target: XX% (XXX / XXX MBs)
Physical Memory / RAM size: 96 GB

You may even seen errors such as the following:

Time: 1/1/2018 1:57:29 PM
ID: 1009
Level: Warning
Source: MSExchangeFastSearch
Machine: MBX01.contoso.com
Message: The indexing of mailbox database MBXDB1 encountered an unexpected exception. Error details: Microsoft.Exchange.Search.Core.Abstraction.OperationFailedException: The component operation has failed. ---> Microsoft.Exchange.Search.Core.Abstraction.ComponentFailedPermanentException: Failed to read notifications, MDB: MBX-GUID-GOES-HERE. ---> Microsoft.Mapi.MapiExceptionMdbOffline: MapiExceptionMdbOffline: Unable to read events. (hr=0x80004005, ec=1142)

Now, if we are in a virtualized environment, one of the items your storage teams may report is your disk I/O rises dramatically.  If you are using high speed storage, such as SSD's, you may not see anything even show up on your disk latencies, but your storage team would notice the increased disk I/O.

What you also may see is SystemCacheWs using a great deal of working set memory.

If you start seeing the above issues, your issue may be fixed by applying one or more of the items below.

Our most common causes are as follows:

1. Not using static resources within your virtualized host.
2. Anti-Virus Exclusions not being abided by.
3. Update to the Windows System when using ReFS.

Static Resources and Virtualization:

We have discussed virtulization in great deal at https://technet.microsoft.com/en-us/library/jj619301(v=exchg.160).aspx, and there have been other articles put out by fellow engineers, but one of the biggest disagreements we see is with the static resources within our virtualized host, and why we have to do it.  In our TechNet articles we state the following:

Some hypervisors have the ability to oversubscribe/overcommit or dynamically adjust the amount of memory available to a specific guest machine based on the perceived usage of memory in the guest machine as compared to the needs of other guest machines managed by the same hypervisor. This technology makes sense for workloads in which memory is needed for brief periods of time and then can be surrendered for other uses. However, it doesn't make sense for workloads that are designed to use memory on an ongoing basis. Exchange, like many server applications with optimizations for performance that involve caching of data in memory, is susceptible to poor system performance and an unacceptable client experience if it doesn't have full control over the memory allocated to the physical or virtual machine on which it's running. As a result, using dynamic memory or memory overcommit features for Exchange isn't supported.

In non-geek speak, what does this mean?  This means we need to make sure we are using static resource allocations within our virtualization environment, otherwise we can see unexpected behavior, which would include (but is not limited to) resource constraints, poor system performance, and client connectivity issues.

But, my virtualization team told me we are!  

Great!  We can check this!  Here's how we can check!  We can use perfmon, and then look up a specific counter to see if we have static resources allocated to our Exchange servers!  If you look for the VM Memory ==> Memory Reservation in MB that counter will show you if you have a static memory allocation for your Exchange server.  If you don't, you will see something similar to below:

If you see zeros all across, then you know you need to set static resources.

Anti-Virus Exclusions and You:

The other common item we see causing higher memory usage can be Anti-virus software.  Modern AV software is very, very good at what it does, to the point we need to make sure we have our exclusions configured correctly, otherwise we can see memory go out of control, among a number of other performance issues.  Even if our AV exclusions are configured correctly today, we still should check the exclusions and verify them with an EICAR test from time to time.  As discussed in a previous blog post, if our exclusions are not configured correctly, we can see errors in our application logs like this:

Time:     1/1/2017 1:01:10 AM
ID:       489
Level:    Error
Source: ESE
Machine:  mail.contoso.com
Message:  msexchangerepl (4456) An attempt to open the file "D:DatabasesDB01.EDB" for read only access failed with system error 32 (0x00000020): "The process cannot access the file because it is being used by another process. ".  The open file operation will fail with error -1032 (0xfffffbf8).

Additionally, some of our customers have reported high disk I/O times, however we see no corresponding spike on our storage array.

Great!  How can I check if my AV exclusions are not set right!

There are three easy ways we can detect if our AV exclusions are not configured correctly.

1. Check our application logs for the Event ID 489.  If we see we are unable to open files because they are being locked, this is a sign our exclusions are not configured correctly.
2. Disk performance counters.  If we open up performance monitor, and we look at the following counter:
   1. MSExchange Database ==> Instances, and then you add in the I/O Database Reads (Attached) Average Latency and I/O Database Writes (Attached) Average Latency, and add in your specific databases that are mounted on your server, as seen below:

   2. If you see spikes on your databases, specifically above 50ms, AND we do not see any corresponding spike in disk latency (LogicalDisk --> Average Disk Sec Read Logical Disk --> Average Disk Sec Write counters) then there is a high degree of likelihood we either have reconfigured backups or our Anti-Virus is scanning our databases, resulting in latencies.  Because AV has to load our database files somewhere while it scans the metadata and does exactly what it is supposed to do, we can see very high latencies and see very high memory usage which may or may not be attributed to the AV software itself.  Because modern AV software runs as part of the system, you will not necessarily see the spike go to the av process.
   3. Perform an EICAR test.  Place the EICAR test file in one of our database paths for example, and see if your AV software detects it.  If it does, then we know we need to adjust our AV configuration.

Again, this isn't the fault of AV doing anything wrong or bad.  Modern AV software is very good at what it does, and if the AV software gets into memory, and the filter drivers start to scan your Exchange databases and delay or prevent Exchange from performing certain tasks, this can cause higher memory usage which does not have an attributable process.

ReFS on Windows Server 2016

The last item we have seen is when you are using ReFS with Windows Server 2016.  We discuss this here where we state:

To provide greater resiliency for its metadata, the Resilient File System (ReFS) in Windows Server 2016 uses allocate-on-write semantics for all metadata updates. This means that ReFS never makes in-place updates to metadata. Instead, it makes all writes to newly allocated regions. 

However, allocating-on-write causes ReFS to issue more metadata I/O to new regions of the volume than write-in-place file systems do. Additionally, ReFS uses block caching logic to cache its metadata in RAM. This is not as resource-efficient as file caching logic. 

Together, the ReFS block caching logic and allocate-on-write semantics cause ReFS metadata streams to be large. ReFS uses the cache manager to create the metadata streams, and the cache manager lazily unmaps inactive views. In some situations, this lazy unmapping causes the active working set on the server to grow. This creates memory pressure that can cause poor performance.

Antes de tudo, para que todos estejam no mesmo passo, seja um iniciante no SCCM ou um administrador experiente, vamos revisar brevemente os componentes do SCCM e Windows:

WSUS – Role do Windows Server da qual se conecta no Catálogo de Updates da Microsoft para geração de seu metadata, contendo a lista de updates para as categorias e produtos selecionados em sua configuração. O WSUS também é o ponto de contato para os clientes realizarem seu Scan de update.

Software Update Point (SUP) - Role do SCCM que se conecta ao WSUS para gerenciar sua configuração e sumarizar a lista de updates sincronizada pelo WSUS para a base do SCCM.

Internet Information Services(IIS) – Role do Windows com o objetivo de servidor web. O cliente SCCM faz sua conexão com os servidores SCCM(DP e MP) e servidor WSUS, utilizando páginas HTTP/HTTPS hospedadas no IIS.

WSUS Administration Console – O SCCM com sua role de Software Update Point não precisa estar no mesmo servidor que o WSUS, porém no caso de servidores diferentes, o SCCM se comunica com o WSUS através da API da console, por esse o motivo a console deve ser instalada no Software Update Point.

Windows update Agent(WUA) - Componente do Windows, responsável pelo Scan e instalação de updates seja ele via WSUS/SCCM ou via internet.

Management Point(MP) –  Role do SCCM, no contexto de Software Update, ele é o responsável por disponibilizar as políticas do SCCM, além de informar ao cliente qual WSUS e Distribution Point utilizar.

Distribution Point(DP) – Repositório onde o cliente se conecta para o download de updates.

Reporting Services Point – Criação e visualização de relatórios contendo informaões de updates instalados, updates necessários, erros de instalação, entre outros.

Client Settings – São politicas que direcionam o cliente para o WSUS, fazem o agendamento do Scan de update,

FAQ

"Quero usar o SCCM para gestão de update, tenho que usar o WSUS mesmo assim?"
Como dito anteriormente, o WSUS é uma role do Windows Server que se conecta no Catalogo de Updates da Microsoft para geração de seu metadados. Atualmente o SCCM não conta com essa função, por isso a necessidade do WSUS.
Mesmo que seja um cliente do SCCM, a máquina vai realizar seu processo de Scan de Updates no WSUS correspondente ao seu site do SCCM, a única função do SCCM nesse passo é informar ao cliente qual o WSUS a se conectar para o Scan. Já a distribuição, instalação e relatórios são de responsabilidade do SCCM.
 
"Já tenho um WSUS, posso utilizá-lo para o SCCM?"
Não, não pode.  Crie um novo! Base zerada, vida nova.
 
"Durante o Setup do SCCM recebi um Warning de que poderia instalar o WSUS, devo fazer isso no momento da instalação do SCCM?"
Não, a mensagem é somente informativa de que se quiser utilizar a role de SUP, você vai precisar instalar o WSUS. Não faz diferença alguma instalar o WSUS antes ou depois do SCCM, já que o Setup do SCCM não vai instalar a role de SUP, você vai ter que fazer isso manualmente.
 

Instalação do WSUS

Em Server Manager, vá em Manage -> Add Roles and Features

 
Na tela de Before you Begin, clique em Next.

 
Em Installation Type, escolha a opção “Role-based or fetaure-based installation”, clique em Next.

 
Em Server Selection, selecione o servidor que será instalado o WSUS, no caso desse exemplo existe somente um servidor no Server Pool.

 
Em Server Roles, marque a opção “Windows Server Update Service”. Next.

 
Após a seleção, a seguinte janela será aberta. Isso porque o WSUS tem como requisito o IIS, além de outras features do Windows. Clique no botão “Add Features”.

 
Em Features, clique em Next.

 
Em WSUS, Clique em Next.

 
Em Role Services, a opção WSUS Services é obrigatória. O que é preciso definir é se irá utilizar o WID Database ou Database(SQL). O WID é um database do próprio Windows, que funciona muito bem com o WSUS, porém tenha em mente que o WID vai fazer grande uso dos recursos de Hardware desse servidor, por esse motivo a maioria escolhe pela opção de SQL, tendo somente que informar o servidor e instância na próxima tela.

 
Em content-location selection, coloque o caminho na qual os updates serão baixados. É importante que a unidade tenha espaço disponivel para a tarefa.

 
Caso tenha selecionado Database SQL, nesse momento você vai precisar informar o servidor e a instância SQL.

 
Web Server Role (IIS), clique em Next.

 
Em Role Services, mantenha o padrão e clique em Next.

 
Na tela de confirmação, valide se está tudo conforme selecionado e clique em Install.

 
Após a instalação, clique em Close.

 
Voltando a Server Manager, vai existir uma notificação de pós-instalação do WSUS, clique em “Launch Post-Installation tasks”. Aguarde o processo. Após isso, nenhuma outra configuração necessita ser feita no WSUS, caso você abra a console, a mesma vai apresentar um Wizard de configuração, clique em Cancelar. Todas as configurações do WSUS devem ser feitas no SCCM, o SCCM vai se encarregar de replica-las ao WSUS.

 
Pronto, agora temos um WSUS pronto para ser integrado ao SCCM!
 

Por hoje é só, na próxima parte vamos configurar a role de SUP no SCCM e configurar a política para seus clientes.
Abraços.

Conteúdo editado e publicado por:
Richard Juhasz
Microsoft PFE
Configuration Manager

In my last blog post: (https://blogs.technet.microsoft.com/gladiatormsft/2018/02/20/determining-an-applications-impact-when-assessing-risk/) I discussed my first recommended vector for assessing an application’s risk: impact to business or organization. In this post, I will discuss the second recommended vector: probability of regression. Internally at Microsoft, we refer to these as technical blockers. Throughout the first 5 iterations of Windows 10, we’ve been able to get a good grasp on the overall potential for application compatibility regressions in terms of predicting potential blockers. Over the next 2-3 months, you will likely see more specific guidance in those areas coming from myself and other experts in the compatibility space. These technical factors should be incorporated into an overall organizational strategy for assessing regression probability specifically tailored to your organization.

In general, we’ve learned that Major-Version-to-Major-Version compatibility has drastically improved over the last few releases of Windows. Significant decisions were made and for the purposes of making the Windows operating system more stable and secure, the Windows XP to Windows 7 upgrade (well, technically Vista too) broke a lot of applications. You will hear ranges from 25% to 50% depending on the application portfolio’s age and technologies leveraged. For Windows 7 to Windows 8.1 as well as Windows 7 to Windows 10, the percentage was less than 10% even as a worst-case scenario (assuming applications were properly remediated & no technical debt was retained.)

For those customers who have been canaries in the coal mine and have traveled with us for these first iterations of Windows 10, the percentage of technical compatibility regressions between feature releases have been extremely low in comparison (around 1-2%.) It *IS* important to point out, however, that even if the percentage is low, if an application critical to the business falls in the bucket, it is still a blocker – which is why we preceded this post with the previous with the one on business impact. J

Factors Determining Regression Probability

Organizations often promote applications to the top of the list with histories of regressions:

Internal Test History Data: Pre-Windows 10, test history does not span more than 3 or 4 operating system major upgrades although many organizations treated Service Pack Upgrades in the same manner. For example, an internal LOB (Line of Business) application developed in 2000 [NOTE: These are not nearly the oldest apps out there] might have been thoroughly regression tested for at least these operating systems with these example initial testing results:

• Windows 98 - PASS
• Windows 2000 Terminal Services SP1 – FAIL [Remediated]
• Windows 2000 Terminal Services SP2 - PASS
• Windows 2000 Terminal Services SP3 - PASS
• Windows 2000 Terminal Services SP4 - PASS
• Windows XP - PASS
• Windows XP SP1 - PASS
• Windows XP SP2 – FAIL [Remediated]
• Windows XP SP3 – FAIL [Remediated]
• Windows 7 – FAIL [Remediated]
• Windows 7 SP1 - PASS
• Windows 2003 Terminal Services - PASS
• Windows 2003 Terminal Services SP1 - PASS
• Windows 2003 Terminal Services SP2 – FAIL [Remediated]
• Windows 2008 R2 RDS – FAIL [Remediated]
• Windows 2008 R2 RDS SP1 - PASS

In the above scenario, three out of eight or 37.5% of the time, it fails warranting it to likely be elevated to a higher risk category.

Dependent Middleware Regression History: In some cases, groups of application sharing common middleware might get hit with periodic regressions simply when these middleware or component dependencies are patched. For example, I recently visited a customer who had a few examples of and Office-integrated LOB application that was broken after the following MDAC (legacy ODBC data access) patches:

• Q823718 Update
• Q832483
• KB92779
• KB954326 Update
• KB952287
• MDAC 2.8 SP1 Update

In this customer’s case, as in most, it’s difficult and too much overhead to track percentages so only patches where regressions occurred were noted. However, 6 patch regressions across the lifetime of the application in question (in this example 17 years) was enough to warrant elevation of risk priority when coupled with the impact ranking.

Known Technical Factors

When the Windows operating system evolves, efforts are made on multiple fronts to ensure compatibility. One of the most prominent is providing methods within the operating system to maintain compatibility through technical means that is seamless to the user. In most cases this is automatic (as in recent releases of Windows) although in some cases it requires tweaking and configuration on the application managers part. Another front is through developer evangelism where encouragement to use modern development technologies and platforms ensures better odds at ongoing compatibility. This is part of an ongoing pledge to make Windows 10 the most compatible Windows operating system to date. So far, the numbers are proving that out with greater and greater improvement as subsequent releases of Windows 10 evolve (going into our sixth 1803 as of this writing.)

There will be exceptions alongside of those that fall into a single-digit percentage of overall applications. Those exceptions and elements that fall into that small percentage of issues include:

• Application which rely on kernel mode drivers (filters, devices, etc.)
• Security Software: Often because of drivers.
• 3^rd-party firewalls/Win32 VPN Clients: Also often because of drivers
• Use of Undocumented APIs

These technical risk factors will likely elevate the application to a higher prioritization for testing.

Retention of Technical Debt

One of the most important (and only major) exception to the Windows 10 ongoing compatibility vector revolves around retention of technical debt. We refer to the term “technical debt” to describe those applications which leveraged some type of last-mile technology that allowed you to “punt” [to use an American football reference] and borrow more time. Doing this creates technical debt that will need to be paid at some point and their will be a cost to servicing that debt. In many cases extending the life of that mortgage could create costs that could exceed retiring that technical debt earlier. For example, we’ve seen cases where the cost of limping along an application for extra years exceeding the cost of redeveloping the application – hence the analogy.

• Remaining on legacy operating systems through Custom Support Agreements
• Moving to Session Hosts (large example of this was extended XP-compatible application into 2015/2016 using Server 2003 Terminal Services.)
• Leveraging virtualization or containerization technologies to provide compatibility through emulation or OS virtualization (i.e. in-line virtual machines.) to preserve older applications.
• Turning off UAC: This was a large one leveraged for Windows 7. Turning off UAC in Windows 10 is unsupported and untested [and will likely break a lot of other things in Windows 10.] If your organization resolved a lot of Windows XP/Windows application compatibility issues by turning off UAC, you now will have to deal with truly remediating these application issues.

In the scope of application compatibility testing, these applications will need to be tested early and here’s the bad news: many will likely need remediation. The good news is that if the remediation is solid, it will likely not run into further compatibility issues during iterative feature updates if the technical debt is truly retired. This will allow many to possibly be placed in lower risk groupings.

One common question that I receive from customers is: how do I fit Azure Security Center in my overall Security Operations and Incident Response plan? The answer may vary according to your SOC model, the size of the organization, cloud workload, and maturity level. For this reason, is important to take in consideration some key aspects of Azure Security Center adoption before you enable it and start using it. For this post, I'm going to cover the following aspects: Roles and Permissions, Operations and Incident Response. Keep in mind that each one of those areas could be deeply explored, but the purpose here is just to give you an overview to assist you during the planning phase.

Roles and Permission

Depending on the size and structure of your organization, multiple individuals and teams may use Security Center to perform different security-related tasks. Security Center uses Role-Based Access Control (RBAC), which provides built-in roles that can be assigned to users, groups, and services in Azure. When a user opens Security Center, they only see information related to resources they have access to. Which means the user is assigned the role of Owner, Contributor, or Reader to the subscription or resource group that a resource belongs to. In addition to these roles, there are two specific Security Center roles:

• Security reader: a user that belongs to this role can view only Security Center configurations, which include recommendations, alerts, policy, and health, but it won't be able to make changes.
• Security administrator: same as security reader but it can also update the security policy, dismiss recommendations and alerts.

We recommend that you assign the least permissive role needed for users to complete their tasks. For example, users who only need to view information about the security state of resources but not take action, such as applying recommendations or editing policies, should be assigned the Reader role. Permissions should be adjusted according to your SOC model, using a three-tier example you could have:

Operations

After initial configuration and application of Security Center recommendations, the next step is considering Security Center operational processes. When you first opt in to use Security Center for your current Azure environment, make sure that you review all recommendations, which can be done in the Recommendations tile or per resource (Compute, Networking, Storage & data, Application). Once you address all recommendations, the Prevention section should be green for all resources that were addressed. Ongoing monitoring at this point becomes easier since you will only take actions based on changes in the resource security health and recommendations tiles. Most Azure environments are dynamic, with new resources being spun up and down on a regular basis, configurations or changes, etc. Security Center helps ensure that you have visibility into the security state of these new resources. You will also want to regularly monitor the state of existing resources to identify configuration changes that have created security risks, drift from recommended baselines, and security alerts.

In the latest Microsoft Security Intelligence Report (SIR), Azure Security Center service witnessed several outbound attack attempts, and most were efforts to establish communications with malicious IP addresses (51 percent) and RDP (Remote Desktop Protocol) brute force attempts (23%) as shown below.

Most of the successful RDP brute force attack could be reduced by applying preventative measures. As part of your security operations, you should also adopt preventative measures to restrict access to VMs and control the applications that are running on VMs. By locking down inbound traffic to your Azure VMs, you are reducing the exposure to attacks, and at the same time providing easy access to connect to VMs when needed. Use Just in Time VM access feature to hardening access to your VMs. You can use Adaptive Application Controls to help control which applications can run on your VMs located in Azure, which among other benefits helps harden your VMs against malware. Security Center uses machine learning to analyze the processes running in the VM and helps you apply whitelisting rules using this intelligence.

Incident Response

Using the Microsoft Azure Security Response in the Cloud lifecycle, you can use Security Center Alerts during the following stages:

• Detect: identify a suspicious activity in one or more resources.
• Assess: perform the initial assessment to obtain more information about the suspicious activity.
• Diagnose: use the remediation steps to conduct the technical procedure to address the issue.

Each Security Alert provides information that can be used to better understand the nature of the attack and suggest possible mitigations. Some alerts also provide links to either more information or to other sources of information within Azure. You can use the information provided for further research and to begin mitigation, and you can also search security-related data that is stored in your workspace. Once you identify the compromised system, you can run security playbooks that were previously created. Security playbook is a collection of procedures that can be executed from Security Center once a certain playbook is triggered from selected alert. You can find a sample of how to use Security Center in an incident response scenario here, or watch my interview below where I go over some of the key aspects of using Security Center for IR:

If your SecOps uses a SIEM solution, you can integrate it with Azure Security Center. This way the Security Center alerts will be send to the SIEM solution. Read Azure Security data export to SIEM- Pipeline Configuration, and also check the current SIEM solutions that are supported.

References and More Information

Azure Security Center Planning and Operations Guide

Using Azure Security Center for an incident response

Hybrid Cloud Workload Protection with Azure Security Center

Available at Microsoft Press Store and Amazon.