I would like to introduce you this new video that the Enterprise Mobility Team put together to explain how EMS can help you to manage your mobile devices. This is a great video that capture some key capabilities of EMS. Watch it, share it and use during your presentations….

If you want to go to the MVA and watch the Online training for “Microsoft Public Cloud Services – Setting up your business in the cloud” go to http://aka.ms/public-cloud-mva

Thank you for reading my blog.

Outlook に Exchange Server のアカウントを設定して利用する場合、既定では [Exchange キャッシュモードを使う] がオンに設定され、キャッシュモードに設定されています。この記事ではキャッシュモードとオンラインモードの設定や動作を説明します。

Exchange Server のアカウントのプロパティの [Exchange キャッシュモードを使う] がオンの場合をキャッシュモード、[Exchange キャッシュモードを使う] がオフに設定されている場合をオンライン モードと呼びます。

Exchange Server のアカウントのプロパティは、Outlook 2013 の [ファイル] タブ-[アカウント設定]-[アカウント設定] から
[電子メール] タブで [種類] に Microsoft Exchange と表示されるアカウントをダブルクリックすると表示されます。

オンライン モードでは、直接 Exchange サーバーのメールボックスのデータをメモリに読み込んで表示します。
ステータス バーには [オンライン: MICROSOFT EXCHANGE] と表示されます。
 

キャッシュモードでは、上記のダイアログの [詳細設定] をクリックして [詳細設定] タブをクリックすると表示される以下のダイアログの [Outlook データ ファイルの設定]に設定されている OST ファイルにデータがキャッシュされます。OST ファイルにはサーバーのメールボックスの情報が同期され、ユーザーは OST ファイルのメールを表示・編集することになります。
[共有フォルダーをダウンロード]は既定でオンに設定されており、他のユーザーの予定表などのフォルダーを開いて利用している場合は他のユーザーの予定表などもキャッシュされる動作となります。[共有フォルダーをダウンロード] をオフにすると自分のメールボックスのみがキャッシュされ、他のユーザーのフォルダーはキャッシュされなくなります。

ステータス バーには [接続先: MICROSOFT EXCHANGE] と表示されます。
 

キャッシュモードの設定や [共有フォルダーをダウンロード] の設定は、以下のように
グループ ポリシーと Outlook の管理用テンプレートを使用するかレジストリを使用して展開できます。

既存プロファイルも新規プロファイルもキャッシュモード/オンラインモードを強制したい場合

ポリシー
[ユーザーの構成] 内の [Microsoft Outlook 2013]-[アカウントの設定]-[Exchange]-[Exchange キャッシュモード] にある
[新規および既存の Outlook プロファイルで Exchange キャッシュ モードを使用する] ポリシー
([有効]: キャッシュモードが強制  [無効]: オンラインモードが強制)

レジストリ
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\Outlook\Cached Mode

  値の名前: Enable
  値の種類: REG_DWORD
  値のデータ: (1: キャッシュモードが強制 0: オンラインモードが強制)

既存プロファイルも新規プロファイルも [共有フォルダーをダウンロード] オン/オフを強制したい場合

ポリシー
[ユーザーの構成] 内の [Microsoft Outlook 2013]-[アカウントの設定]-[Exchange]-[Exchange キャッシュモード] にある
[メール以外の共有フォルダーをダウンロードする]ポリシー
([有効]: オンが強制  [無効]: オフが強制)

レジストリ
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\Outlook\Cached Mode

  値の名前: DownloadSharedFolders
  値の種類: REG_DWORD
  値のデータ: (1: オンが強制 0: オフが強制)

参考資料
キャッシュモードを利用するかオンラインモードを利用するかを検討する場合は、以下の資料を参考にしてください。

Exchange キャッシュモードとオンラインモードのメリット・デメリット/[共有フォルダーをダウンロード] のメリット・デメリット
Outlook 2013 の Exchange キャッシュ モードまたはオンライン モードを選択する

キャッシュモードは既定では有効であり弊社では基本的にはキャッシュモードを推奨していますが、お客様の希望や利用状況によってはオンライン モードで利用した方がよい場合もあります。この記事ではキャッシュモードとオンラインモードでの動作の違いやメリット・デメリットを紹介します。また、キャッシュモードにある [共有フォルダーをダウンロード] の設定がオンの場合とオフの場合のメリット・デメリットも紹介いたします。どの設定で利用した方がよいかを検討する際に参考にしていただければ幸いです。
なお、Exchange キャッシュモードとオンライン モードがどういう設定であるかや参考資料についてはこちらの記事をご覧ください。

キャッシュモード

メリット
・メール一覧を表示・メールを開く・メールを作成して送信するなどの作業を行う際に、
  まずローカルのコピーに対して操作が行われるため処理がはやい。
・一定の間隔でまとめてデータの同期が行われており、ネットワーク効率がよい。
  そのため、サーバーやネットワークへの負荷を低く抑えることができる。
・ネットワークの遅延や切断などの問題が発生した際は自動的にオフラインに切り替わり、
   ローカルのキャッシュを使用して操作し続けることができる。

デメリット
・ローカルにキャッシュするためのディスク領域が必要。
・ローカルにデータがダウンロードされる。
  (セキュリティ上の理由によりローカルにメールなどのデータを残したくない場合はキャッシュモードでは利用できない)
・Outlook で変更を行うと、まずローカルのデータに対して処理が行われた後に、
   一定の同期タイミングによりまとめて変更が反映されるのでそれまでは更新されない (最大 60 秒)。
・Exchange サーバーのメールボックス上で変更が行われると、
   一定の同期タイミングによりまとめて変更が反映されるのでそれまでは更新されない (最大 60 秒)。
  (同期タイミングについてはこちらの記事をご覧ください)

オンラインモード

メリット
・ローカルにデータがダウンロードされない。
  (セキュリティ上の理由によりローカルにメールなどのデータを残したくない場合はオンライン モードで利用する必要がある)。
・ローカルにキャッシュするためのディスク領域が不要。
・常に最新のデータを表示したり更新したりすることができる。
・負荷分散が構成されている仮想環境を利用する場合のように OST ファイルの再作成が頻繁に発生するような状況では
  キャッシュ モードでは利用できないため、オンラインモードで利用する必要がある。
  (OST ファイルを作成してキャッシュし直すことが繰り返されることは効率が悪く、 キャッシュモードで利用し続けると
  将来 KB949486の問題 (OST ファイルの再作成が多数行われるとキャッシュモードでログオンできなくなる) が発生するため)

デメリット
・一般的にはキャッシュモードに比べて操作が遅くなる。
  (毎回 Exchange サーバーのメールボックスにアクセスしてデータを取得するため。
  2 回目以降はメモリ上に読み込まれているデータが残っている場合はメモリから読み込むため高速に処理されるが、
  メモリ解放後は再度 Exchange サーバーにアクセスしてデータを取得する動作となる)
・頻繁に Exchange サーバーからデータを取得する必要があるため、ネットワークや Exchange サーバーに負荷がかかる。
・検索を行うと Exchange サーバー側で検索を行うため、Exchange サーバーに負荷がかかる。

キャッシュモードの [共有フォルダーをダウンロード] をオン

メリット
他のユーザーの予定表などの共有フォルダーのデータをローカルにキャッシュし、
ローカルにキャッシュされたデータの表示や更新を行うため、一般的にはユーザーの操作が速くなる。

デメリット
・他のユーザーの予定表などのデータをキャッシュするためのディスク容量が必要。
・予定表に他のユーザーの予定表が多数登録されていると、以下のような問題が発生する場合がある。
  * Outlook は起動時に予定表に登録されている全ユーザー (チェックがオンオフどちらでも) の予定表を同期し、
    ユーザーごとのセッションを維持し続けて変更があると同期が行われる。
    その影響によって Outlook の起動に時間がかかったり Outlook の全体的なパフォーマンスが悪くなったりする場合がある。
  * 他のユーザーの共有フォルダーをキャッシュするため OST ファイルのサイズが大きくなり、
    OST ファイルのサイズに比例してパフォーマンスが悪化する。

キャッシュモードの [共有フォルダーをダウンロード] をオフ

メリット
・他のユーザーの共有フォルダーに対して操作を行う際、最新のデータの表示と更新ができる。
  (直接ネットワーク上の他のユーザーのメールボックスからクライアントのメモリにデータを読み込む動作となるため、
  同期タイミングの影響を受けない)
・自分のメールボックスはキャッシュし他のユーザーの予定表などのフォルダーはキャッシュしないことになるため、
  OST ファイルのサイズを抑えることができる (他のユーザーの共有フォルダーをキャッシュするためのディスク容量が不要)。
・予定表に他のユーザーの予定表が多数登録されていて以下のような問題が発生している場合は、パフォーマンスが改善する。
  * Outlook は起動時に予定表に登録されている全ユーザー (チェックがオンオフどちらでも) の予定表を同期し、
    ユーザーごとのセッションを維持し続けて変更があると同期が行われる。
    その影響によって Outlook の起動に時間がかかったり Outlook の全体的なパフォーマンスが悪くなったりする場合がある。
  * 他のユーザーの共有フォルダーをキャッシュするため OST ファイルのサイズが大きくなり、
    OST ファイルのサイズに比例してパフォーマンスが悪化する。

デメリット
予定表に多数のユーザーが登録されていない場合は、
[共有フォルダーをダウンロード] がオンの場合に比べてユーザーの操作が遅くなる。

キャッシュモードの Outlook 2013 では、キャッシュされているアイテムに対して変更が行われると 15 秒後に同期を開始します。ただしその 15 秒間に次の変更が発生した場合は延期され、最大 60 秒間待機してからまとめて同期を開始します。また、Exchange サーバー上のメールボックス内のアイテムに対して変更が行われた場合は 5 秒後に同期が開始され、その間に複数の変更が発生した場合は同様に最大 60 秒間待機してからまとめて同期を開始します。この記事では、この同期の動作について説明します。

キャッシュモードの Outlook では、アップロード タイマーとダウンロード タイマーという機能を使用して複数の変更が行われた場合にまとめて同期が行われるようにすることで、ネットワークを効率よく利用できるよう制御されています。

ローカルにキャッシュされているアイテムに対して変更が行われた時 (アップロード タイマー)

キャッシュされているアイテムに対して変更が行われると、Outlook 2013 はアップロード タイマーを開始します。
Outlook 2013 は既定ではアップロード タイマー 15 秒で同期を開始します。

アップロード タイマーで 15 秒カウントされるまでの間に次の変更が行われなかった場合は同期を開始します。
15 秒カウントされる前に次の変更が行われた場合はアップロード タイマーが再開されます。

次の変更が行われなかった場合は、アップロード タイマーが 15 秒カウントされたタイミングで同期を開始しますが、
その後も変更が繰り返された場合はその都度アップロード タイマーが再開され、
最大待機時間 60 秒が経過するとすべての変更の同期を開始します。

例:

Exchange サーバー上のメールボックス内のアイテムに対して変更が行われた時 (ダウンロード タイマー)

別のユーザーや PC などから Exchange サーバー上のメールボックス内のアイテムに対して変更が行われると、
Exchange サーバーはただちに Outlook 2013 に通知します。
Outlook 2013 は通知を受信するとダウンロード タイマーを開始します。

Outlook 2013 は既定ではダウンロード タイマー 5 秒で同期を開始します。
ダウンロード タイマーで 5 秒カウントされるまでの間に次の変更が行われなかった場合は同期が行われ、
5 秒カウントされる前に次の変更が行われた場合はダウンロード タイマーが再開されます。

次の変更が行われなかった場合は、ダウンロード タイマーが 5 秒カウントされたタイミングで同期を開始します。
その後も変更が繰り返された場合はその都度ダウンロード タイマーが再開され、
最大待機時間 60 秒が経過するとすべての変更の同期を開始します。

例:

アップロード タイマー・ダウンロード タイマーを制御する方法

アップロード タイマー・ダウンロード タイマーに指定されている秒数は、
以下のポリシーまたはレジストリを使用して変更することができます。

ポリシー
[ユーザーの構成] 内の [Microsoft Outlook 2013]-[アカウントの設定]-[Exchange]-[Exchange キャッシュモード] にある以下のポリシー

[変更の同期を開始するまでの最長待機秒数を入力する][サーバーからの変更のダウンロードを開始するまでの待機秒数を入力する]
[サーバーへの変更のアップロードを開始するまでの待機秒数を入力する]

レジストリ
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\Outlook\Cached Mode
  Maximum (REG_DWORD)
  Download (REG_DWORD)
  Upload (REG_DWORD)

Outlook のバージョンごとのタイマーの既定値

 参考資料

以下の弊社 Web ページでも同期の動作について説明しています。以前のバージョンの Outlook の資料のみで申し訳ありませんが、基本的な同期の仕組みは Outlook 2013/2010 でも同じです。 

870926 Exchange Server 2003 環境における Outlook 2003 の Exchange キャッシュ モードについて

   (抜粋。Outlook 2003 についての記述であるため Download の既定値が異なります)
   この同期タイマの値は、HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\11.0\Outlook\Cached Mode レジストリ キーの下に次のレジストリ キーを作成して値を設定することにより変更できます。
   [Upload=dword:0000000f] (デフォルト値は 15 秒)
   [Download=dword:0000001e] (デフォルト値は 30 秒)
   [Maximum=dword:0000003c] (デフォルト値は 60 秒)

Outlook 2007 で Exchange キャッシュ モードを構成する

  (抜粋)
  Exchange サーバーにすべての変更をアップロードするまでの最長待機秒数を指定します。
  Outlook での既定の最長待機秒数は 60 秒です。
  次の手順は、既定のアップロード タイマと最長待機秒数タイマの関係を示しています。
  ・アップロード タイマで 15 秒経過する間にローカルの変更が発生した場合、アップロード タイマが再起動します。
  ・15 秒経過する前に他のローカルな変更が発生しない場合、そのデータは Exchange サーバーと同期されます。 
  ・15 秒経過する前に変更が継続して発生した場合、アップロード待機タイマの現在の秒数にかかわらず、すべての変更は 60 秒後に Exchange サーバー コンピュータに同期されます。 

昨年の WPC で発表されたクラウド ソリューション プロバイダー (CSP) プログラムでは、パートナー様独自のソリューションを、サブスクリプション形式でマイクロソフトのクラウド サービスと組み合わせて再販できます。

また、パートナー様は、請求、プロビジョニング、管理、サポートを直接実施して、カスタマー ライフサイクル全体に常にかかわることも可能です。

マイクロソフト クラウド ソリューション プロバイダー リソース センターには、マイクロソフト クラウド ソリューション パートナー様にご利用いただけるすべての特典、リソース、ツールが集約されていますので、以下に挙げているリンクからご利用ください。

▼ CSP プログラムはこちら

CSP プログラムについての概要ビデオもご用意しておりますので、初めてプログラムをご利用いただく場合はもちろん、販売活動の準備が整っているパートナー様も、ぜひご覧ください。

▼ 概要ビデオ (英語) はこちら

来週から米国フロリダのオーランドで開催される WPC2015 でも CSP に関するニュースがたくさん出てくる予定です。その前にぜひ CSP の概要についてご確認してみてください。

こんにちは。Windows プラットフォーム サポート の今入です。
日頃より本ブログをご愛読いただき、ありがとうございます。

本日は、Windows Server 2003 および Windows Server 2003 R2の 延長サポート終了についてのお知らせとなります。

Windows Server 2003 / 2003 R2 は、2010年7月13日 (米国時間) にメインストリームのサポートを終了しており、現在 Service Pack 2 がインストールされている Windows Server 2003 / 2003 R2 に対してのみ、延長サポートを提供しています。

しかし、その延長サポートも 2015年7月14日 (米国時間) をもって、終了となります。*1

延長サポートの終了に伴い、ターミナル サーバー ライセンスのアクティブ化 および 新規CALのアクティブ化を行うことができなくなりますので、ご了承願います。

なお、Windows Server 2003 ライセンス サーバーのアクティブ化については、下記のサイトに記載されておりますので、ご確認ください。

[HOWTO] Windows Server 2003 のターミナル サーバー ライセンスを使用してライセンス サーバーをアクティブ化する方法
https://support.microsoft.com/ja-jp/kb/325869/ja

*1: Windows Server 2003 のサポート終了 | マイクロソフト
http://www.microsoft.com/ja-jp/server-cloud/products/windows-server-2003/default.aspx

Support for provisioning and managing Azure IaaS virtual machine environments via Azure Resource Manager (ARM) was recently launched as a Generally Available (GA) feature! There’s several HUGE advantages that ARM provides over the existing Azure Service Management (ASM) API, including simplifying complex configurations, repeatable deployments via declarative templates, resource tagging, role-based access control (RBAC) and more!  You can learn more about the advantages of this new API at:

• Learn more!Azure Compute, Network & Storage Providers under Azure Resource Manager

With the GA launch of ARM for Virtual Machine services, lots of us are exploring how to leverage this new API as part of an automated provisioning process.  So, I thought I’d update my previous guidance on automated provisioning of IaaS environments for using the new Azure Resource Manager.

In this article, we’ll step through using the latest Azure PowerShell module, which is version 0.9.4 as of this article’s publication date, to perform end-to-end provisioning of a common IaaS VM scenario: load-balanced web applications.  My goal in this article is to provide you with code snippets that can serve as “building blocks” for learning and creating your own automated provisioning process using Azure Resource Manager, PowerShell and Desired State Configuration.

In future articles, we’ll look at provisioning this same scenario using other tools and approaches, such as Azure Resource Manager Templates and also the Azure Cross-Platform CLI for Linux and Mac OSX ...

A little over two years ago we wrote about removing PSTs from your organization and gave you a tool to assist you with that endeavor. .PST, Time to Walk the Plank. Since then, we’ve updated the tool with some new features and functionality. In this blog, we are going to give you:

1. More reasons to get rid of PST files.
2. What to do with the data in the PST files.
3. How to move the PST data to its new location.

More Reasons to get rid of PST files.

Without further ado, let’s talk a bit about why you want to get rid of PST files.

Corporate Security and Compliance.

1. PST files are created by users and are unmanaged data. Most organizations have very little insight into where PSTs are created, how the users retain the files, where the files are kept, and exactly how much data is in those files.
2. PST files usurp your well defined data retention policies. Exchange Data Retention Policies do not apply to data residing within PST files, and you cannot set retention tags in PST files.
3. Outside of the maximum file size for a PST, currently 50 Gigabytes, they are not limited in size.
4. A PST from one machine or user can easily be opened by another user off the network. They can be stored on portable media that can be lost or stolen. Thumb Drives, USB storage media, DVD, personal cloud storage. This is a data leakage risk, even if they are password protected.
5. Depending on your corporate backup strategy, they may not be backed up anywhere. This can result in data loss if the user’s computer has a disk issue.
6. Data within PST files is not discoverable with built in Exchange Discovery tools. This creates a complex discovery issue for legal departments which can lead to a very expensive discovery process.
7. More about the importance of Records Management can be found in a very old Exchange Team Blog here.

User Experience

1. Users with multiple PST files have a disjointed experience when switching machines or using OWA. Because a PST only resides on a single computer, users are limited on how they can interact with that data. It today’s mobile workforce, with smartphones, tablets, laptops and workstations, this can result in data being strewn across devices and the user not having the data they need when they need it.
2. Outlook Rules that work with a PST file will only work on the computer where that PST resides and Outlook must be running for the rule to fire properly.
3. Disk Space. PSTs can be up to 50 GBs and users can create multiple different PSTs which can impact disk space on the workstation or device.

Great, you’ve talked me into it, HOW do I get rid of PST files?

Glad you asked, but before we get started you have to make some decisions.

Where do you want to put the data?

Once you decide where you want to put the data, we can work on methods to get it there?

What to do with the data in your PST files.

Now that you have decided it is time for PSTs to Walk the Plank; let’s decide where to put all that data. In general, you have 4 options.

First, you have to decide WHERE you want to store this data?

1. User Mailbox
2. Archive Mailbox Locally
3. Archive Mailbox in the Cloud
4. Delete, Delete, Delete

Option 1: Keep it simple. Given the mailbox size capabilities of Exchange 2013, you could pull all that mail back into the users’ mailboxes.

Advantages:

• Easy. Pulling all that PST data back into the mailbox is very easy using the PST capture tool—as long as you have the space. Also keeping it in a single mailbox reduces the management complexity as each user only has a single mailbox associated with their account.
• Discoverability of data. Mailboxes are searchable via native Exchange Discovery Tools.
• Manageability of data. Mailbox data is subject to data retention policies.
• No separation of data. Exchange 2013 and later is designed to handle large mailboxes (100+ GB in size). From a client perspective, all clients can access the data and you can control the OST size with the Outlook 2013 Sync Slider.

Disadvantages:

• Cost. Increasing the mailbox sizes for all users and keeping multiple copies of that data on server storage can get quite costly if you are not deploying commodity hardware as recommended in the Preferred Architecture.
• Overhead: Database and log file disk space management. During the ingestion phase, the database and log files will grow quickly if the process is not managed.
• Large OST footprint with legacy clients. If you are deploying legacy Outlook versions (2010 or prior) or using the Outlook:Mac client, you cannot control the size of the cached mailbox.

Option 2: Keep it Separate. With Exchange 2013 you can create an archive mailbox and import all the PST data into it.

Advantages:

• Discoverability of data. Archive Mailboxes are searchable via the native Exchange Discovery tools.
• Archive Mailbox Data is Manageable. Aging and retention policies apply to both the Mailbox and Archive Mailbox and not to PSTs.
• Security. The data is secure on your Exchange servers, not on users’ local drives.
• Safety. The data’s resiliency is handled by continuous replication.
• Access. The Archive Mailbox is accessible by the user on most machines where they have mailbox access, this includes OWA (access varies by client. Outlook 2007 SP2 with February 2011 cumulative update and above for Outlook for PC).

Disadvantages:

• Storage costs. You are still importing all of that data into your Enterprise Mail environment. This storage includes, disk space for the data, copies of the data, and backups of the data.

Option 3: Keep it in Office 365. With Exchange 2013 and Office 365, you can put the archive in the cloud—even if the primary mailbox is still On-Premises.

Advantages:

• Discoverability of data. Archive Mailboxes are searchable via the native Exchange Discovery tools.
• Reduce Storage costs. With an Enterprise CAL Suite, Archive Mailboxes are included at no extra cost. Enterprise CAL Suite Details. Think about it, Unlimited Archive storage space for your users.
• Archive Mailbox Data is Manageable. You can apply aging and retention policies.
• Security. The data is secure on Office 365 servers, not on users’ local drives.
• Safety. The data is redundant and safe in the Office 365 cloud.
• Access. The Archive Mailbox is accessible by the user on most machines where they have mailbox access, this includes OWA (access varies by client. Outlook 2007 SP2 with February 2011 cumulative update and above for Outlook for PC).
• Reduced Storage Hardware. Exchange Online Archive uses Office Online storage and negates the need to build additional storage for the ingested PSTs.
• Reduced Management costs. Once the Online Archives are set up, the back end management of the cloud storage is done by Microsoft.

Disadvantages:

• Initial Setup. Yes, there is a bit more setup involved in going to the cloud, but that effort is going to be considerably less than architecting and adding the storage for all of your PST files.

Option 4: Delete them all. Yes, this is actually an option.

Advantages:

• Really easy to find and delete PST files.

Disadvantages:

• Lost data. All those PST files were kept for a reason. Some of that data could be business critical.
• Angry users. Do I need to explain this point? Torches and Pitchforks anyone?

Those are your main options for addressing PST data. In Part 3, we’ll discuss some methods to get the data to the desired location.

How to move the PST data to its new location

This time, I’ll talk about a strategy.

1. Announce the Policy.
2. Lock the PSTs
3. Move the data and remove PSTs from workstations.

Step 1: Announce the Policy

This is the MOST IMPORTANT STEP.

Once you have determined your data retention and PST storage plan, you need to announce it. This message should come from the policy makers, Legal, Business, etc, NOT the IT department. Pointing to the User Experience issues from Part 1 of this series will go a long way toward easy user acceptance and adoption.

Step 2: Lock the PST files

No sense in getting rid of them if the users can keep putting them back. You can use the following registry keys \ Outlook Policies to control the behavior before, during, and after you move everything to its final location.

1. DisablePST – Prevents users from adding PSTs to Outlook profiles.
2. PSTDisableGrow –Prevents user from adding content to PST files.
3. DisableCrossAccountCopy – Prevents users from copying data into or out of PST files.
4. DisableCopyToFileSystem – Prevents users from copying mail to a File System.

Further details on the options to keep users from adding data to PST files -  http://technet.microsoft.com/en-us/library/ff800883.aspx.

Step 3: Moving the current PST file data. Three options.

1. Automate the Move with PST Capture.
2. Allow your users to move their data.
3. Upload or ship your PST files to Microsoft and have us import it for you.

Option 1: Automate the Move with the PST Capture Tool.

The PST Capture tool will discover all PST files in your organization. It will gather them into a consolidated location. It will import them to the location you desire, Mailbox, Archive Mailbox, Cloud Archive Mailbox.

Option 2: Allow your users to move their data into their Mailbox or Archive Mailbox.

Wait? What? You just told me about that amazing automated tool, why would I make my users manually import their data?

The tool is great, but it does have some limitations that may not work for all customers.

1. All or nothing. The tool imports all mail from a PST with no filters for content or age.
2. Agent on every desktop. The tool requires an agent install on every desktop.
3. Outlook must be shut down for the PST Capture to finalize the PST move.

While this option works, it creates a significant amount of administrative overhead. You have to manage the process:

1. The messaging to the users about how and where to move the data.
2. The issues around database and log management if they are uploading On-Premises
3. The timelines for each of the settings for locking the PST.
4. Following up with the users.
5. Following up with the users.
6. Following up with the users.

In short, yes, this can work, but will drag out the process significantly.

Option 3: Have Microsoft put your PSTs in your Office 365 Mailbox or Archive Mailboxes for you.

Yes, you heard that right, Microsoft will put them in the cloud for you. This is a great option if you have a large amount of data to upload. You can directly upload the PST files via Azure AZCopy Tool OR ship the disks to us. Typically, we recommend the disk shipping service for data over 10TB.

REQUIREMENTS

1. The PST files. For either drive shipping or network upload, you need to collect them so that they can be copied into the hard drives or uploaded to the cloud storage destination.
2. Office 365 tenant with active users and mailboxes for all of the users who will have data imported. This option is currently only available if the mailbox is already in Office 365.
3. PST Mapping File.
4. A User Account with Mailbox Import Export admin role.

ADDITIONAL REQUIREMENTS FOR THE SHIPPING OPTION ONLY

1. Hard Drive: Only 3.5 inch SATA II/III hard drives are supported for use with the PST Import service. Hard drives larger than 4TB are not supported. For import jobs, only the first data volume on the drive will be processed. The data volume must be formatted with NTFS. You can attach a SATA II/III disk externally to most computers using a SATA II/III USB Adapter.
2. BitLocker encryption: All data stored on hard drives must be encrypted using BitLocker with encryption keys protected with numerical passwords. The Office 365 drive preparation tool will help with the encryption. This can be found in the Office 365 Admin Center under the Import tab.
3. A carrier account for shipping if drive shipping is your preferred method.

Details of the Office 365 Import service are here:

• Blog
• TechNet documentation
• TechNet FAQ

Other relevant articles:

• In-Place Archiving - http://technet.microsoft.com/en-us/library/dd979800(v=exchg.150).aspx
• Plan for compliance and archiving in Outlook 2010 - http://technet.microsoft.com/en-us/library/ff800883.aspx
• Understanding Personal Archives - http://technet.microsoft.com/en-us/library/dd979795(v=exchg.141).aspx
• Office 365 Import Service - https://technet.microsoft.com/library/ms.o365.cc.IngestionHelp.aspx?v=15.1.166.0&l=1
• Office 365 Import Service for SPO Migration - https://technet.microsoft.com/en-us/library/mt210445.aspx

Mike Ferencak
Senior Premier Field Engineer

En informatique, un Plan de Reprise d'Activité (en anglais DRP: Disaster Recovery Plan) permet d'assurer, en cas de crise majeure ou importante d'un centre informatique (incendie, inondation, perte d'alimentation électrique...), la reconstruction de son infrastructure et la remise en route des applications supportant l'activité et la survie d'une organisation.

Un plan de reprise d’activité c’est 3 composants:
- Une ou des solutions techniques
- Des processus qui sont documentés, régulièrement testés et maintenus à jour
- Des personnées formées aux solutions techniques, entrainées à l’exécution du PRA, capables de suivre et maintenir les procédures définies (et écrites)

Dans un Plan de Reprise d'Activité, certaines métriques sont absolument à définir dans la définition du Plan.

Le RTO (Recovery Time Objective): C'est la durée maximale d’interruption acceptable pendant lequel une ressource informatique (serveur, réseau, application) peut ne pas être opérationnelle suite à une interruption majeure de service. Cet objectif est défini à l’avance en fonction des besoins de l’entreprise et des métiers utilisant le SI. Plus la ressource est critique plus le RTO est faible. Un RTO très très faible peut être assuré par un (Géo)Cluster qui a un donc un coût non négligeable (d'ailleurs dans le cas d'un cluster, on parlera plutôt de PCA : Plan de Continuité d'Activité).

Le RPO (Recovery Point Objective): c'est la durée maximale d'enregistrement des données qu'il est acceptable de perdre (= perte de données maximum admissible) lors d'une interruption majeure de service. Quantifier le RPO revient à définir les objectifs de sauvegarde (implique de connaître la volumétrie et les fenêtres de sauvegarde) et/ou de réplication asynchrone de données.

Dessin très inspiré du schéma de Wikipedia : http://fr.wikipedia.org/wiki/Fichier:RTO_RPO.gif

Aujourd'hui la majorité des SI bien gérés dispose d'un plan de reprise d'activité. Reste à vérifier son efficacité !

Un frein à un PRA efficace est clairement son coût (et surtout les CAPEX associés).

Celui se décompose de la manière suivante :
- le choix du site (datacenter)de secours avec son emplacement, sa taille, son type (froid, tiède ou chaud)
- Le coût des équipements sur le site de secours : réseau, stockage, serveurs
- Le coût d'opération des équipements sur le datacenter de secours : électricité, climatisation, protection physique
- Le RPO défini
- le RTO défini : plus le RTO est faible plus le coût est élevé
- Le périmètre couvert par le PRA (plus il y a d'éléments à protéger, plus le coût sera élevé)
- La fréquence des tests de ce PRA (impliquant des ressources humaines et techniques dédiées au test)

Du coup, il est compréhensible que parfois le PRA de certaines organisations soit inexistant (faute de moyen financiers) ou simplifié au point d'être inutile (ex: une seconde salle serveurs collée à la première).

L'avènement des solutions de Cloud Public permet désormais d'envisager des Plans de Reprise d'Activité de nouvelle génération :
- Moins chers
- Ne nécessitant pas la gestion de datacenter / salle serveurs de secours
- Où les CAPEX sont remplacés par des OPEX
- Assurant une capacité de reprise rapide d'activité pour des organisations de toutes tailles (de la TPE à la multi-nationale). 

Parmi les solutions Cloud disponibles sur le marché pour les PRA, Microsoft propose Azure Site Recovery qui permet la réplication de machines physiques ou virtuelles à destination des datacenters Microsoft Azure. Ainsi, les ressources protégées dans le cadre d'un PRA utilisant ASR peuvent être instanciées à la demande sous la forme de machines virtuelles dans les datacenters de Microsoft en cas de désastre majeur sur site.

Vous l’aurez compris : ici le Cloud n’est que la composante technique du PRA, la définition, le suivi, la maintenance des procédures et leur application dans l’action ne pourra être faite que par des équipes entrainées et formées. C’est aussi pour cela qu’Azure Site Recovery offre toutes les fonctionnalités pour documenter & orchestrer ces opérations. ASR permet aussi de tester son PRA dans des environnements isolés de la production et ça c’est un vrai plus pour valider son PRA sans risques.

Dans les prochains articles de cette série, je vous expliquerai en mode pas à pas comment protéger vos machines virtuelles Hyper-V dans Azure Site Recovery.

Vous êtes professionnel et légitimement vous vous posez des questions sur le Cloud, Microsoft Azure, Hyper-V, Windows Server, l’évolution du datacenter vers un cloud privé ou hybride, la gestion des périphériques mobiles en entreprise alors pour en savoir plus, n’hésitez pas à suivre les sessions gratuites de formation de la Microsoft Virtual Academy : http://aka.ms/mvafr

Pour évaluer gratuitement Microsoft Azure : http://aka.ms/jeTesteAzure

- Stanislas Quastana -

Issue:

When opening multiple objects in design view and then trying to switch to other views, Access may become unresponsive. This delay can last a few seconds up to a couple of minutes.

Cause:

This is a product issue.

Work Arounds:

You may try either of the following options to work around the issue:

1. Close the property sheet before switching between views.

2. Disable the “Themes” service on your machine:

            a. From the Run command, type in services.msc

            b. Scroll down in the list of services until you find “Themes”

            c. Double click “Themes” and under the Service Status, click the Stop button.

            d. From the Startup type dropdown, select “Disabled”.

            e. Click ok and exit the services console.

Note: You must have local administrator rights to disable the Themes service.

Status:

The developers are currently working on a fix for this issue.

Kære alle faste læsere

Det er blevet tid til at lave ændringer til hvordan vi har struktureret vores danske TechNet blogs.

Denne side har i de sidste par år været stedet hvor du kunne holde dig opdateret på hvad der sker omkring Microsoft infrastruktur, i Danmark og de fleste indlæg har været omkring events, både online og med personligt fremmødeog netop dette fortsætter på Dansk TechNet Blog– Jeg håber du vil følge med der.

Denne blog fortsætter under navnet Cloud Admins og vil fremover beskæftige sig med Cloud Computing og DevOps (der også er mine nye fokusområder) Sproget bliver byttet ud med engelsk, så flere kan få glæde af det og du vil fortsat kunne læse om relevante internationale events og aktiviteter herunder et nyt spændende koncept vi lancere snart

Jeg håber meget at du fortsat vil følge med

De bedste hilsner

@RasmusHaldDK

Beschreibung

Der „Windows 10 Client: Neue Funktionen und Upgrade“-Workshop vermittelt den Kursteilnehmern eine umfassende Einführung in die breite Palette von neuen und verbesserten Features in Windows 10.

Nach diesem dreitägigen Workshop, der abwechslungsreich mit Präsentationen, White-Board Diskussionen und zielbasierten Übungen gestaltet ist,  haben die Teilnehmer ein Verständnis für:

• strukturellen Veränderungen in Windows 10 integriert

• Verwenden der neuen Tools und Technologien zur Bereitstellung von Windows

• Anforderungen und Funktionen

• Wie Windows Ihr Unternehmen sicherer und agiler machen kann

Agenda

Module 1: Platform Promise
This module provides insights on the cross platform capabilities of Windows 10, how Windows 10 is the OS for the Cloud and Enterprise ready.

Module 2: UI/UX, Modern Apps and Windows Store
In this module you will learn about the UI/UX improvements done in Windows 10, what are Windows Modern Apps, the Microsoft Edge and how to deploy and manage Apps via the Windows Store and Business Portal.

Module 3: Enterprise Mobility
This module presents the new manageability and BYOD set of options, like the built-in MDM client, and how EMS and System Center Configuration Manager provides Enterprises the required control and security, and still provide to users more flexible ways of being productive. 

Module 4: Security

This module covers the major security changes in Windows 10, like Secure Credentials and Pass-The-Hash mitigations, Windows Biometrics new features, and many more improvements in the Enterprise Security space.

Module 5: Licensing and Servicing

In this module covers the changes on the new Windows Servicing model, the Windows Update for Business, and also licensing changes and enhancements.

Module 6: Deployment

In this module you will review the new servicing that are available for Windows 10, like the Image Configuration and Designer, the in-place upgrade improvements and the how to use MDT or Configuration Manager to accomplish a successful deployment of Windows 10.

 Zielgruppe

Der Workshop ist besonders relevant für den Windows Client-Support und das Image Team, die erwägen Windows 10 bereit zu stellen.

Level

Level 200-300

(Level Skala: 100= Strategisch/ 200= technischer Überblick/ 300=tiefe Fachkenntnisse/  400= technisches Expertenwissen)

Sprache

Dieser Workshop wird in deutscher Sprache gehalten. Es werden hauptsächlich Englisch sprachige Kursunterlagen verwendet.

Anmeldung

Zur Anmeldung wenden Sie sich bitte direkt an Ihren Microsoft Technical Account Manager oder besuchen Sie unserenMicrosoft Services Blog.Dort finden Sie eine Gesamtübersicht aller offenen Workshops, für die Sie sich dort auch gleich anmelden können. Sollte der Workshop ausgebucht sein, können Sie sich auf die Warteliste setzen lassen. Sobald ein Platz frei werden sollte, werden wir Sie informieren. Gerne organisieren wir weitere Workshops zu diesem Thema sollten ausreichend Anmeldungen auf der Wartelist stehen.

ご賛同の一つのカテゴリ、テレワークを「応援・協力する」皆様にご提供いただくメニューの内容も今後どんどんご紹介して参ります。

賛同法人の皆様には、以下のテンプレートを間もなく事務局より送らせていただく予定です。「応援・協力」メニューでご賛同いただく法人の皆様はテンプレートに紹介内容、プロモーションサイトURL、受付窓口など必要事項をご記載いただき、事務局へご返送ください。確認が完了次第、本ブログその他で積極的にご紹介致します。

本日は、第一弾サンプルとして、日本マイクロソフトから Universal Mobile Keyboard モニター提供のご案内です。「テレワーク実施」カテゴリのご賛同法人の皆様でご興味のある方は本キャンペーンにご参加いただければと思います。

今後もご案内する応援メニューに注目いただくと共に、是非「テレワーク週間」の活動にご賛同いただければ幸いです。

テレワーク週間2015　プロジェクトチーム

This just came today from Gabe Aul so I will share essential extracts:

You can read about these and other updates here

Here in the Azure Machine Learning team we live and breathe two scripting languages: R and Python. We’re working on exciting products that will advance the state of the art in how data scientists employ these languages and their stacks. 

Both these ecosystems are fueled by the open source community, of course, and we are looking for ways to give back. For instance, we were recently the Keystone sponsor at PyCon 2015 and have contributed to the Jupyter/IPython project prior to that. Today, I’m very happy to announce that we will be sponsoring and hosting the first PyData conference here on the Microsoft campus – and you are invited!

PyData will bring top speakers and practitioners from the industry and academia together for three days of exciting tutorials, talks and sprints. The tutorials cover Python, numpy/scipy, Pandas, matplotlib, scikit-learn, etc. The talks span the full spectrum of big data, advanced analytics, visualization and more. After the talks we’ll be hosting a number of sprints where folks can contribute to their favorite open source projects.

While PyData usually attracts around 200 attendees, I’m pleased to see that this particular conference, the very first PyData in the Pacific Northwest, has already crossed 1,200 registrants! So register yourself asap if you haven’t done so already, and forward a link to your colleagues too, so they can join in. 

Here are some important facts and resources:

Conference date:               July 24-26
Conference location:         Microsoft Conference Center in Redmond
Conference site:                http://seattle.PyData.org
List of talks:                       http://seattle.PyData.org/schedule/

See you at PyData!  

Shahrokh Mortazavi
Azure Machine Learning

Overview: 

By default Microsoft Word opens hyperlinks to documents as read only when the hyperlink is part of an emails contents.  Many issues can arise when the document is opened read only. 

One issue that we have noticed in testing is that anytime files are opened in Read only the Document Information Panel will not automatically open even if the SharePoint site is set to open it automatically.

Environment:

SharePoint Online

Office 2013

Here are the steps we used in our testing to reproduce the behavior:

Repro Steps:

1. While in a SPO library, in Site Settings > Site Content Types > Document > Document Information Panel Settings
   •  Select "Always show Document Information Panel on document open and initial save for this content type".
2. Create an OOB approval workflow on the SPO library.  To do this:
   •  From the library Ribbon > Workflow Settings > Add a Workflow
   •  Be sure that “*Approval – SharePoint 2010” is selected
   •  Enter anything you’d like for the Name
   •  Uncheck “Allow this workflow to be manually started by an authenticated user with Edit Item permissions” and check “Creating a new item will start this workflow”
   • Click “Next”
   • Choose an approver to receive the workflow notification emails
   • Click “Save” – This should create the workflow
3. Create a new Word document in the SPO library where you created the workflow.  Once you save the document this should kick off the workflow and generate an email to the approvers titled something like “Tasks – Please approve…”
4. Within the email, you will see “To complete this task:” along with a link to the Word document.
5. Click on that link and the document opens in your local Word client, but does not display the document information panel.  However, when you open the document directly from the SPO library and it opens in my local Word client, the Document Information Panel does display properly.

Currently there are no workarounds for modifying this behavior when using out of the box SharePoint Workflows.   If you are using customized workflows you may be able to use the workaround noted in the following blog:

http://blogs.technet.com/b/office_integration__sharepoint/archive/2014/12/04/force-microsoft-word-to-open-in-edit-mode-from-hyperlink-in-an-email.aspx

In System Center 2012 Operations Manager (OpsMgr 2012 or OpsMgr 2012 R2), one of the more common performance concerns surrounds Operations Manager Database and Data Warehouse insertion times. Here are some tips to help identify and troubleshoot problems concerning Database and Data Warehouse data insertion.

A typical sign of Operations Manager DB performance problems is the presence of Event ID 2115 events in the Operations Manager Event log. These events typically indicate that performance issues exist on the Management Server or the Microsoft SQL Server that is hosting the OperationsManager or OperationsManager Data Warehouse databases.

First a little background

Database and Data Warehouse write action workflows run on the Management Servers and these workflows first retain the data received from the Agents and Gateway Servers in an internal buffer. They then gather this data from the internal buffer and insert it into the Database and Data Warehouse. When the first data insertion has completed, the workflows will then create another batch.

The size of each batch of data depends on how much data is available in the buffer when the batch is created, however there is a maximum limit on the size of the data batch of up to 5000 data items. If the data item incoming rate increases, or the data item insertion throughput to the Operation Manager and Data Warehouse databases throughput is reduced, the buffer will then accumulate more data and the batch size will grow larger.

There are several write action workflows that run on a Management Server. These workflows handle data insertion to the Operations Manager and Data Warehouse databases for different data types. For example:

• Microsoft.SystemCenter.DataWarehouse.CollectEntityHealthStateChange
• Microsoft.SystemCenter.DataWarehouse.CollectPerformanceData
• Microsoft.SystemCenter.DataWarehouse.CollectEventData
• Microsoft.SystemCenter.CollectAlerts
• Microsoft.SystemCenter.CollectEntityState
• Microsoft.SystemCenter.CollectPublishedEntityState
• Microsoft.SystemCenter.CollectDiscoveryData
• Microsoft.SystemCenter.CollectSignatureData
• Microsoft.SystemCenter.CollectEventData

When a Database or Data Warehouse write action workflow on a Management Server experiences slow data batch insertion (e.g. times in excess of 60 seconds), it will begin logging Event ID 2115 to the Operations Manager Event log. This event is logged every one minute until the data batch is inserted into the Database or Data Warehouse, or the data is dropped by the write action workflow module. As a result, Event ID 2115 will be logged due to the latency inserting data into the Database or Data Warehouse. Below is an example Event logged due to data dropped by the write action workflow module:

Event Type: Error
Event Source: HealthService
Event Category: None
Event ID: 4506
Computer: <RMS NAME>
Description:
Data was dropped due to too much outstanding data in rule "Microsoft.SystemCenter.OperationalDataReporting.SubmitOperationalDataFailed.Alert" running for instance <RMS NAME> with id:"{F56EB161-4ABE-5BC7-610F-4365524F294E}" in management group <MANAGEMENT GROUP NAME>.

Taking a deeper look

Event ID 2115 contains 2 significant pieces of information. First, the name of the workflow that is experiencing the problem, and second, the elapsed time since the workflow began inserting the last batch of data. For example:

Log Name: Operations Manager
Source: HealthService
Event ID: 2115
Level: Warning
Computer: <RMS NAME>
Description:
A Bind Data Source in Management Group <MANGEMENT GROUP NAME> has posted items to the workflow, but has not received a response in 300 seconds. This indicates a performance or functional problem with the workflow.
Workflow Id : Microsoft.SystemCenter.CollectPublishedEntityState
Instance : <RMS NAME>
Instance Id : {88676CDF-E284-7838-AC70-E898DA1720CB}

This particular Event ID 2115 message indicates that the workflow Microsoft.SystemCenter.CollectPublishedEntityState, which writes Entity State data to the Operations Manager database, is trying to insert a batch of Entity State data and it started 300 seconds ago. In this example, the insertion of the Entity State data has not yet finished. Normally inserting a batch of data should complete within 60 seconds.

If the Workflow ID contains Data Warehouse then the problem concerns the Operations Manager Data Warehouse. Otherwise, the problem concerns inserting data into the Operations Manager database!

Common causes

Insertion Problems

As the description of Event ID 2115 states, this may indicate a database performance problem or too much data incoming from the agents. Event ID 2115 simply indicates there is a backlog inserting data into the Database (either Operations Manager or Operations Manager Data Warehouse). These events can originate from a number of possible causes. For example, there could be a sudden, large amount of Discovery data, there could be a database connectivity issue, the database may be full, or possibly there is a disk or network related constraint.

In Operations Manager, discovery data insertion is a relatively labor intensive process. It can also come in bursts, where there is a significant amount of data being received by the Management Server. These bursts can cause temporary instances of Event IDs 2115, but if Event ID 2115 consistently appears for discovery data collection this can indicate either a Database or Data Warehouse insertion problem or Discovery rules in a Management Pack collecting too much discovery data.

Operations Manager configuration updates caused by Instance Space changes or Management Pack imports have a direct effect on CPU utilization on the Database Server and this can impact Database insertion times. Following a Management Pack import or a large instance space change, it is expected to see Event ID 2115 messages. For more information on this topic please see the following:

2603913 - How to detect and troubleshoot frequent configuration changes in Operations Manager (http://support.microsoft.com/kb/2603913)

In Operations Manager, expensive user interface queries can also impact resource utilization on the database which can lead to latency in Database insertion times. When a user is performing an expensive User Interface operation it is possible to see Event ID 2115 messages logged.

Databases full or offline

If the Operations Manager or Operations Manager Data Warehouse databases are out of space or offline, it is expected that the Management Server will continue to log Event ID 2115 messages to the Operations Manager Event log and the pending time will grow higher. 

If the write action workflows cannot connect to the Operations Manager or Operations Manager Data Warehouse databases, or they are using invalid credentials to establish their connection, the data insertion will be blocked and Event ID 2115 messages will be logged accordingly until this situation is resolved.  

Configuration and environmental issues

Event ID 2115 messages can also indicate a performance problem if the Operations Manager Database and Data Warehouse databases as well as the supporting environment are not properly configured. Some possible causes include the following:

• The SQL Log or TempDB database is too small or out of space.
• The Network link from the Operations Manager and Data Warehouse database to the Management Server is bandwidth constrained or the latency is large. In this scenario we recommend to Management Server to be on the same LAN as the Operations Manager and Data Warehouse server.
• The data disk hosting the Database, logs or TempDB used by the Operations Manager and Data Warehouse databases is slow or experiencing a function problem. In this scenario we recommend leveraging RAID 10 and we also recommend enabling battery backed Write Cache on the Array Controller.
• The Operations Manager Database or Data Warehouse server does not have sufficient memory or CPU resources.
• The SQL Server instance hosting the Operations Manager Database or Data Warehouse is offline.

It is also recommend that the Management Server reside on the same LAN as the Operations Manager and Data Warehouse database server.

Event ID 2115 messages can also occur if the disk subsystem hosting the Database, logs or TempDB used by the Operations Manager and Data Warehouse databases is slow or experiencing a functional problem. We recommend leveraging RAID 10 and we also recommend enabling battery backed Write Cache on the Array Controller.

Troubleshooting

The first step in troubleshooting the performance related Event ID 2115 messages is to identify what data items are being returned within the event. For example, the Workflow ID indicates what type of data items (e.g. discovery, alerts, event, perf) as well as what database is involved. If the Workflow ID contains the term DataWarehouse, then the focus should be towards the Operations Manager Data Warehouse. In other instances the focus would be towards the Operations Manager Database.

Scenario 1

In the example below, the problem concerns the workflow Microsoft.SystemCenter.CollectSignatureData.

Event Type: Warning
Event Source: HealthService
Event Category: None
Event ID: 2115
Computer: <RMS NAME>
Description:
A Bind Data Source in Management Group <MANGEMENT GROUP NAME> has posted items to the workflow, but has not received a response in 300 seconds. This indicates a performance or functional problem with the workflow.
Workflow Id : Microsoft.SystemCenter.CollectSignatureData
Instance : <RMS NAME>
Instance Id : {F56EB161-4ABE-5BC7-610F-4365524F294E}

Resolution

We can identify the Performance Signature Data Collection Rules in this example by executing the following SQL query. This query should be executed in SQL Management Studio against the Operations Manager database.

-- Return all Performance Signature Collection Rules
Use OperationsManager
select
managementpack.mpname,
rules.rulename
from performancesignature with (nolock)
inner join rules with (nolock)
on rules.ruleid = performancesignature.learningruleid
inner join managementpack with(nolock)
on rules.managementpackid = managementpack.managementpackid
group by managementpack.mpname, rules.rulename
order by managementpack.mpname, rules.rulename

This query will return all Performance Signature Collection Rules and their respective Management Pack name. A column is returned for Management Pack name and Rule name.

The following Performance Monitor Counters on a Management Server will provide information concerning Database and Data Warehouse write action insertion batch size and time. If the batch size is growing larger, for example the default batch size is 5000 items, this indicates either the Management Server is slow inserting the data to the Database or Data Warehouse, or is receiving a burst of Data Items from the Agents or Gateway Servers.

· OpsMgr DB Write Action Modules(*)\Avg. Batch Size
· OpsMgr DB Write Action Modules(*)\Avg. Processing Time
· OpsMgr DW Writer Module(*)\Avg. Batch Processing Time, ms
· OpsMgr DW Writer Module(*)\Avg. Batch Size

From the Database and Data Warehouse write action account Average Processing Time counter, we can understand how long it takes on average to write a batch of data to the Database and Data Warehouse. Depending upon the amount of time it takes to write a batch of data to the Database, this may present an opportunity for tuning.

Scenario 2

If the SQL Server instance hosting the Operations Manager Database or Data Warehouse is offline, Event ID 2115 as well as Event ID 29200 will appear within the Operations Manager Event log. For example:

Log Name: Operations Manager
Source: HealthService
Date:
Event ID: 2115
Level: Warning
Description:
A Bind Data Source in Management Group MSFT has posted items to the workflow, but has not received a response in 60 seconds. This indicates a performance or functional problem with the workflow.
Workflow Id : Microsoft.SystemCenter.CollectEventData
Instance : name.contoso.local
Instance Id : {88676CDF-E284-7838-AC70-E898DA1720CB}

=====

Log Name: Operations Manager
Source: OpsMgr Config Service
Event ID: 29200
Level: Error
Description:
OpsMgr Config Service has lost connectivity to the OpsMgr database, therefore it can not get any updates from the database. This may be a temporary issue that may be recovered from automatically. If the problem persists, it usually indicates a problem with the database. Reason:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

Resolution

To resolve the issue in this scenario, complete the following:

1. Connect to the server hosting the Operations Manager database.
2. Open the Services applet.
3. Verify that the SQL Server (MSSQLSERVER) service is started and running.
4. If the SQL Server (MSSQLSERVER) service is not started and running, start the service.

Once database connectivity is restored workflows should resume successfully storing data within the respective database. Event ID 31554 validates that the information has been written successfully:

Log Name: Operations Manager
Source: Health Service Modules
Event ID: 31554
Task Category: Data Warehouse
Level: Information
Description:
Workflow succeeded storing data in the Data Warehouse
One or more workflows were affected by this.
Workflow name: Microsoft.SystemCenter.DataWarehouse.CollectEventData
Instance name: name.contoso.local
Instance ID: {88676CDF-E284-7838-AC70-E898DA1720CB}

Scenario 3

Event ID 2115 caused by invalid RunAs credentials.

Resolution

Examine the Operations Manager Event log for the following events. These events typically indicate that the Data Warehouse SQL Server Authentication Account may have incorrect credentials.

Log Name: Operations Manager
Source: HealthService
Event ID: 7000
Task Category: Health Service
Level: Error
Description:
The Health Service could not log on the RunAs account <ACCOUNT NAME> for management group <MANGEMENT GROUP NAME>. The error is Logon failure: unknown user name or bad password.(1326L). This will prevent the health service from monitoring or performing actions using this RunAs account

=====

Log Name: Operations Manager
Source: HealthService
Event ID: 7015
Task Category: Health Service
Level: Error
Description:
The Health Service cannot verify the future validity of the RunAs account <ACCOUNT NAME> for management group <MANGEMENT GROUP NAME>. The error is Logon failure: unknown user name or bad password.(1326L).

To resolve the issue in this scenario, complete the following:

1. Open the Operations Manager console.
2. Select Administration.
3. Select Run As Configuration\Accounts.
4. Configure the appropriate credentials for the Data Warehouse SQL Server Authentication Account.

Scenario 4

Event ID 2115 caused by disk performance issues. This can occur when the data disk hosting the database, logs or TempDB used by the Operations Manager and Data Warehouse databases is slow or experiencing a problem. In this scenario we recommend leveraging RAID 10 and we also recommend enabling battery backed Write Cache on the Array Controller.

Resolution

First, capture these Physical Disk counters for all drives that contain SQL data or log files:

• % Idle Time: How much disk idle time is being reported. Anything below 50 percent could indicate a disk bottleneck.
• Avg. Disk Queue Length: This value should not exceed 2 times the number of spindles on a LUN. For example, if a LUN has 25 spindles, a value of 50 is acceptable. However, if a LUN has 10 spindles, a value of 25 is too high. You could use the following formulas based on the RAID level and number of disks in the RAID configuration:

• RAID 0: All of the disks are doing work in a RAID 0 set
• Average Disk Queue Length <= # (Disks in the array) *2
• RAID 1: half the disks are “doing work”; therefore, only half of them can be counted toward Disks Queue
• Average Disk Queue Length <= # (Disks in the array/2) *2
• RAID 10: half the disks are “doing work”; therefore, only half of them can be counted toward Disks Queue
• Average Disk Queue Length <= # (Disks in the array/2) *2
• RAID 5: All of the disks are doing work in a RAID 5 set
• Average Disk Queue Length <= # (Disks in the array/2) *2
• Avg. Disk sec/Transfer: The number of seconds it takes to complete one disk I/O
• Avg. Disk sec/Read: The average time, in seconds, of a read of data from the disk
• Avg. Disk sec/Write: The average time, in seconds, of a write of data to the disk
• Disk Bytes/sec: The number of bytes being transferred to or from the disk per second
• Disk Transfers/sec: The number of input and output operations per second (IOPS)

NOTE The last three counters in this list should consistently have values of approximately .020 (20 ms) or lower and should never exceed.050 (50 ms). The following are the thresholds that are documented in the SQL Server performance troubleshooting guide:

• Less than 10 ms: Very good
• Between 10 - 20 ms: Good
• Between 20 - 50 ms: Slow, needs attention
• Greater than 50 ms: Serious I/O bottleneck
• Disk Bytes/sec: The number of bytes being transferred to or from the disk per second
• Disk Transfers/sec: The number of input and output operations per second (IOPS)

When % Idle Time is low (10 percent or less), this means that the disk is fully utilized. In this case, the last two counters in this list (Disk Bytes/sec and Disk Transfers/sec) provide a good indication of the maximum throughput of the drive in bytes and in IOPS, respectively. The throughput of a SAN drive is highly variable, depending on the number of spindles, the speed of the drives and the speed of the channel. The best bet is to check with the SAN vendor to find out how many bytes and IOPS the drive should support. If % Idle Time is low, and the values for these two counters do not meet the expected throughput of the drive, engage the SAN vendor for further troubleshooting assistance.

The following links provide deeper insight into troubleshooting SQL Server performance issues:

• Troubleshooting Performance Problems in SQL Server 2008
• Troubleshooting Performance Problems in SQL Server 2005
• SQL Server Performance Survival Guide
• The Microsoft SQL Server 2012 Performance Dashboard Reports
•  How To: Troubleshooting SQL Server I/O bottlenecks

Scenario 5

Event ID 2115 is logged and a Management Server generates an "unable to write data to the Data Warehouse" alert in System Center Operations Manager. You also experience the following symptoms on the Management Server computer:

• The Management Server generates one or more alerts that resemble the following:

Performance data collection process unable to write data to the Data Warehouse

Performance data collection process unable to write data to the Data Warehouse. Failed to store data in the Data Warehouse. Exception 'SqlException': Management Group with id '9069F7BD-55B8-C8E8-1CF9-4395F45527E2' is not allowed to access Data Warehouse under login 'DOMAIN\Action_Account' One or more workflows were affected by this. Workflow name: Microsoft.SystemCenter.DataWarehouse.CollectPerformanceData Instance name: dataWarehouseServer.domain.com Instance ID: {48936EE3-4E3E-BEE1-8C09-AFDAB8ECF236} Management group: Management Group Name.

• The following event is logged in the Operations Manager event log on the Management Server:

Event Type: Warning
Event Source: HealthService
Event Category: None
Event ID: 2115
Date: date
Time: time
User: N/A
Computer: ManagementServerName
Description: A Bind Data Source in Management Group Management Group Name has posted items to the workflow, but has not received a response in 1712 seconds. This indicates a performance or functional problem with the workflow. Workflow Id : Microsoft.SystemCenter.DataWarehouse.CollectPerformanceData Instance : ManagementServerName.domain.com Instance Id : {C7FDDE2A-E0AA-4B80-70DE-1D50D9965221}

Resolution

This issue can occur if the Management Server does not have accounts that are specified for its data warehouse "Run As" profiles. This issue is more likely to affect a secondary Management Server. To resolve this problem complete the following:

1. On the computer that is running System Center Operations Manager, open the Operations Console.
2. In the navigation pane, click Administration.
3. Expand Security, and then click Run As Profiles.
4. In the Run As Profiles view, double-click Data Warehouse Account.
5. In the Run As Profile Properties - Data Warehouse Account properties dialog box, click the Run As Accounts tab, and then click New.
6. In the Run As Account list, click Data Warehouse Action Account.
7. In the Name list, click the Management Server that generated the alert.
8. Click OK two times.
9. Follow steps 4 through 8 to assign the appropriate Run As account to the following profiles:
   - Data Warehouse Configuration Synchronization Reader Account
   - Data Warehouse Report Deployment Account
   - Data Warehouse SQL Server Authentication Account
10. For each profile, select the Run As account that matches the name of the Run As profile. For example, make the following assignments:
    - Assign the Data Warehouse Configuration Synchronization Reader Account to the Data Warehouse Configuration Synchronization Reader Account profile.
    - Assign the Data Warehouse Report Deployment Account to the Data Warehouse Report Deployment Account profile.
    - Assign the Data Warehouse SQL Server Authentication Account to the Data Warehouse SQL Server Authentication Account profile.
11. On the Management Server that generated the alert, restart the OpsMgr Health Service.
12. In the Operations Manager event log on the Management Server, verify that event ID 31554 events are logged. Event ID 31554 indicates that the monitor state has changed to Healthy. This change resolves the alert.

Scenario 6

Event ID 2115 occurs on a server running HP MPIO FF DSM XP v3.01 to which there are no LUNs presented. When the user opens Performance Monitor and attempts to add a counter, Performance Monitor will hang and the handle count for this application increases rapidly.

Resolution

There are two workarounds for this issue:

1. Rename the HPPerfProv.dll file and reboot Windows. Performance Monitor will work without issue when the file is renamed and not loaded.
2. Have at least 1 LUN present on the system.

For more information on this issue please see the following HP support document:

Windows MPIO DSM for XP v3.01.00 - Will Have Windows Perfmon Hung In "No LUN Presented" Environment

 J.C. Hornbeck| Solution Asset PM | Microsoft GBS Management and Security Division

Get the latest System Center news onFacebookandTwitter:

System Center All Up: http://blogs.technet.com/b/systemcenter/

Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/ 
Data Protection Manager Team blog: http://blogs.technet.com/dpm/ 
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/ 
Operations Manager Team blog: http://blogs.technet.com/momteam/ 
Service Manager Team blog: http://blogs.technet.com/b/servicemanager 
Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm

The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

System Center 2012 Operations Manager System Center 2012 R2 Operations Manager SCOM 2012 R2 SCOM2012R2

Today’s (SQL) Tip…

You may have heard about codename Sterling. This is the update for SQL Azure that completely re-architects the backend of SQL Azure to make it run much more like on premise SQL Server. You can now use CLR, columnstore indexing, and run parallel queries.

For more information check out this link http://azure.microsoft.com/en-us/updates/public-preview-azure-sql-database-update/

As a note, I would suggest heavily testing this out before moving production database to it unless you absolutely need one of the features listed!