51.     Jaké jsou možnosti formátování písma?

52.     Jaké jsou možnosti formátování odstavce?

 

53. Jaká je minimální a maximální velikost písma?

54.     Jak napsat ve Wordu chemický vzorec?

55.     Jaké jsou možnosti označování textu?

Приложения Project Portfolio Dashboard, анонсированные прошлой осеньюстали доступны Магазинах приложений Apple и Office! Эти приложения содержат преднастроенные панели управления, которые позволят руководителям, менеджерам портфелей проектов и менеджерам проектов извлекать ценные сведения в таких областях, как использование ресурсов, производительность портфеля проектов, затраты, активные риски/проблемы и ключевые этапы проектов.

※本ブログは Microsoft Surface BlogSからの転載です。

外部ディスプレイ出力などの問題を改善する最新ファームウェア・ドライバーを公開しました

 マイクロソフトは、米国時間 4 月 19 日付で Surface Pro 4 および Surface Book の最新版ファームウェア・ドライバーを公開しました。

今回の更新は、2 月の更新に続く大規模なアップデートとなっており、主に以下の点を修正する内容になります。

(なお、ドック関連の修正のみ、 Surface Pro 3 向けにも公開されております)

• 外部ディスプレイを使用する際の Surface ドック の動作改善
• Windows Hello で生じている問題を改善するためのカメラ ドライバーの更新
• ドック経由で外部ディスプレイを接続した際の問題、画面のちらつき、セカンド モニターが検出されない問題などに関するビデオ ドライバーの改善
• 5 GHz 帯で Wi-Fi 接続する際のパフォーマンスの改善 (Surface Pro 4 のみ)

このほか、 Surface Pro 4 のファンノイズの低減、 Surface Book の外部 GPU でのゲームのサポート改善などが図られています。

詳細な更新内容は、以下の更新履歴ページにて公開しております。

（現時点では英語版のみとなり、日本語版の更新履歴ページは準備中です。）

Surface Pro 4 update history

https://www.microsoft.com/surface/en-us/support/install-update-activate/surface-pro-4-update-history?os=windows-10

Surface Book update history

https://www.microsoft.com/surface/en-us/support/install-update-activate/surface-book-update-history

外部ディスプレイ接続など、 Surface の動作に問題が発生している場合は、まず、今回の更新を実施いただき、改善するかをご確認ください。

最新版ファームウェア・ドライバーの適用方法

更新プログラムを適用する方法は、 “Windows Update” による方法と、当社ダウンロード センターからファームウェア・ドライバー パッケージをダウンロードしてインストールする方法があります。

通常は Windows Update を、ファームウェア更新のみを手動で適用したい場合や社内で WSUS をご利用の場合はダウンロード センターをご利用ください。

（なお、適用の際は、電源に接続し、バッテリ残量が 40% 以上あることをご確認ください）

Windows Update での適用方法

Windows Update については、既定では自動で更新が行われますが、手動での適用方法は以下の通りです。

[スタート] ボタン – [設定] – [更新とセキュリティ] – [Windows Update] を表示します。

当画面から、[更新プログラムのチェック] を選択することでインストールが開始されます。

Windows Update で配信されている更新プログラムは、以下の構成になります。

インストール・再起動後、更新履歴にてインストールが成功したことをご確認ください。

（更新履歴は、[Windows Update] から [詳細オプション] – [更新履歴を表示する] で表示できます）

<Surface Pro 4 の場合>

•     Microsoft driver update for Surface Embedded Controller Firmware
•     Microsoft driver update for Surface System Aggregator Firmware
•     Microsoft driver update for Surface UEFI
•     Intel Corporation driver update for Intel(R) HD Graphics 520
•     Intel(R) Corporation driver update for Intel(R) Display Audio
•     Intel Corporation driver update for Intel(R) AVStream Camera 2500
•     Intel Corporation driver update for Intel(R) Control Logic
•     Intel Corporation driver update for Intel(R) CSI2 Host Controller
•     Intel driver update for Intel(R) Imaging Signal Processor 2500
•     Intel Corporation driver update for Microsoft Camera Front
•     Intel Corporation driver update for Microsoft Camera Rear
•     Intel Corporation driver update for Microsoft IR Camera Front
•     Microsoft driver update for Surface Camera Windows Hello
•     Microsoft driver update for Surface CoSar
•     Microsoft driver update for Surface Dock Integration
•     Microsoft driver update for Surface Dock Firmware Update

<Surface Book の場合>

•     Microsoft driver update for Surface System Aggregator Firmware
•     Microsoft driver update for Surface UEFI
•     Intel Corporation driver update for Intel(R) HD Graphics 520
•     Intel(R) Corporation driver update for Intel(R) Display Audio
•     NVIDIA driver update for NVIDIA GeForce GPU
•     Intel Corporation driver update for Intel(R) AVStream Camera 2500
•     Intel Corporation driver update for Intel(R) Control Logic
•     Intel Corporation driver update for Intel(R) CSI2 Host Controller
•     Intel driver update for Intel(R) Imaging Signal Processor 2500
•     Intel Corporation driver update for Microsoft Camera Front
•     Intel Corporation driver update for Microsoft Camera Rear
•     Intel Corporation driver update for Microsoft IR Camera Front
•     Microsoft driver update for Surface Camera Windows Hello
•     Microsoft driver update for Surface Dock Integration
•     Microsoft driver update for Surface Dock Firmware Update

※ 以前は「システム ファームウェアの更新 – xx/xx/xx」という更新プログラム 1 つのみで構成されておりましたが、現在は複数の更新プログラムで構成されますのでご注意ください。

※ Surface ドック をご利用でない場合、ドック関連の更新プログラムはインストールされません。

ダウンロード センターからパッケージをダウンロードして適用する方法  (4 月 20 日現在、公開準備中)

当社ダウンロード センターの以下のページからダウンロードできます。現在、最新版の公開準備中のため、公開され次第ご案内させていただきます。

Surface Pro 4 Drivers and Firmware

Surface Book Drivers and Firmware

Surface ドック のファームウェアの更新方法

今回の更新には、 Surface ドック のファームウェアの更新が含まれております。

Surface ドック のファームウェアは、ドック内のチップに書き込まれているため、本体側のファームウェア・ドライバーの更新の後、ドックを本体に接続すると、本体側から更新版のファームウェアがドック側にコピーされ、本体の取り外し後にチップに適用されます。

上記の仕組みについては、以下のページにて詳しくご案内しておりますので、ご参照ください。

Manage Surface Dock firmware updates

また、複数台のドックに対して一度に更新を適用する IT 管理者様向けに、 ドックのファームウェア更新専用のツール “Microsoft Surface Dock Updater” も別途ご提供します。（現在、準備中のため、提供を開始次第お知らせします）

以下のページでご利用方法をまとめておりますので、こちらも必要に応じご利用ください。

Microsoft Surface Dock Updater

Auf dem “Firetage Festival”, das am 23. und 24. April auf der Theresienwiese in München stattfindet, wird Microsoft zusammen mit den CityNext Partnern CANCOM (Einsatz-Tablet), CODE3 (fireplan) und icomedias mit hybrid.forms und dem Hydranten-Manager innovative Lösungen im Kontext der  Feuerwehren und First Responder präsentieren.

Angesprochen werden ehrenamtliche und hauptberufliche Mitarbeiter/innen und Führungskräfte von:

• Feuerwehren (FF, BF, WF)

• Einsatz- und Hilfsorganisationen

• Behörden

aus Bayern sowie Baden-Württemberg und Österreich

Vorab schon mal ein kurzer Überblick:

Von der Alarmierung über die Dokumentation bis hin zur Abrechnung sorgt die Lösung fireplan unseres CityNext Partners CODE3 auf Basis von Azure SQL und Azure Storage als benutzerfreundliche Verwaltungslösung für mehr Effizienz und einen reduzierten Zeitaufwand bei den anfallenden Verwaltungsaufgaben. Lesen Sie dazu gerne die Kundenreferenz der Freiwilligen Feuerwehr Beuren.

Erfahren Sie mehr zum Einsatz-Tablet. Diese Microsoft CityNext Lösung unterstützt Feuerwehren im Einsatzfall, sei es Brandbekämpfung oder technische Hilfsleistungen, wie bei einem Verkehrsunfall mit dem Ziel, schnell die notwendigen Informationen vorliegen zu haben – hier können Sie sich ein Video zum Einsatz-Tablet anschauen.

HYBRID.FORMS in der Notfallmedizin – „Bei Notarzteinsätzen geht es um die extrem zeitkritische Rettung von Menschenleben – wenn jede Sekunde zählt. Mit der mobilen Lösung HYBRID.FORMSvon icomedias werden alle Maßnahmen zuverlässig rechtsverbindlich und schnell dokumentiert. Durch die Ablöse von Papier durch digitale Formulare können wichtige Daten schon während des Einsatzes an das Ziel-Krankenhaus gesendet werden. Formular-Automation reduziert Risiken, spart Geld und wir gewinnen mehr Zeit für unsere Kernaufgaben," so Chefarzt Prim. Dr. med. Klaus Pessenbacher, Leiter Notfallmedizin Katastrophenschutz, Landesregierung Steiermark | Österreich. Des Weiteren gibt es Szenarien und Formulare, bei denen HYBRID.FORMS auch für Feuerwehren, Polizei und anderen Organisationen eingesetzt wird, um Daten schnell, effizient und fehlerfrei zu erfassen.

I've been branching out a lot recently to look at some of the Data Visualization tools in Microsoft products, but haven't had a chance to post much on them yet.

My SQL Colleague, Sam Lester has been partnering with me on this, and recently published a nice post on the "current" options for Power BI desktop and Sql Server Reporting Services 2016. I say "current' since SQL 2016 hasn't yet been released, but it should be in the next few weeks.

More to follow on this story, but wanted to link to this now:

https://blogs.msdn.microsoft.com/samlester/2016/04/18/power-bi-ssrs-2016-in-an-on-premises-environment/

Today’s Tip…

It is rare, but sometimes when you are trying to scale a SQL Azure database to a lower tier you can get an error stating your database or files are too large. A quick fix is:

The first query checks the sizes of the database and physical files, the last two shrink the files of your database and it’s transaction log respectively.

Cloud-Computing wird von immer mehr Unternehmen eingesetzt, um die eigene IT ausfallsicherer und effizienter zu machen. Doch häufig wird dabei übersehen, dass es auch hier Risiken für die Datensicherheit gibt. So stellte die Cloud Security Alliance (CSA) The Treacherous 12 zusammen, eine Beschreibung der zwölf größten Sicherheitsrisiken für Daten in der Cloud. Das Dokument richtet sich in erster Linie an die Betreiber von Cloud-Services, hält aber auch etliche Tipps für Kunden bereit.

1. Datenverluste
   Cloud-Provider sind zum Einhalten bestimmter Sicherheitsstandards verpflichtet. Werden sie nicht eingehalten und es kommt zu Datenverlusten, drohen hohe Strafen und empfindliche Reputationsverluste. Allerdings sind nicht nur die Provider für den Schutz der Daten verantwortlich, sondern auch die Anwender. Empfohlen werden eine Multifaktor-Authentifizierung und Verschlüsselung.
   
   
2. Unzureichendes Identitäts-, Zugangs- und Zugriffsmanagement
   Datenverluste und Hackerangriffe werden begünstigt durch ein fehlendes oder mangelhaftes skalierbares Identitätsmanagement-System, das Fehlen einer Multifaktor-Authentifizierung, die Verwendung schwacher Passwörter und den Verzicht auf den automatischen Austausch von Schlüsseln, Kennwörtern und Zertifikaten.
   
   
3. Unsichere Bedienoberflächen und APIs
   Schnittstellen sind besonders gefährdet, da sie zum einen die Verbindung zur Software von Drittanbietern herstellen und zum anderen meist übers Internet erreichbar sind. Die erste Verteidigungslinie muss daher die Kontrolle des Codes und eine kontinuierliche Überwachung umfassen.
   
   
4. Systemschwachstellen
   Sicherheitslücken sind ein bekanntes Phänomen, in der Cloud werden ihre Auswirkungen potenziert. Die CSA empfiehlt regelmäßige Scans auf Schwachstellen, eine schnelle Reaktion auf bekanntgewordene Bugs und die sofortige Installation von Security-Patches und Updates.
   
   
5. Account Hijacking
   Der Diebstahl von Account-Daten birgt bei Cloud-Diensten zusätzliche Gefahren in sich, da die Angreifer die Aktivitäten und Transaktionen des rechtmäßigen Besitzers überwachen, Daten verändern, falsche Informationen verbreiten und ihn auf manipulierte Seiten führen können. Notwendig ist ein kontinuierliches Monitoring der Benutzeraktivitäten, das gilt auch für die Service-Accounts.
   
   
6. Kriminelle Insider
   Sie können in einer Cloud-Umgebung besonders viel Schaden anrichten. Die CSA empfiehlt, dass Cloud-Kunden die Datenverschlüsselung unter eigener Kontrolle behalten und Zuständigkeiten auf mehrere Personen aufteilen.
   
   
7. Advanced Persistent Threads
   Angriffe, bei denen Unternehmen über längere Zeit hinweg ausgespäht werden, haben in den vergangenen Jahren zugenommen. Cloud-Kunden sollten sich kontinuierlich über aktuelle Bedrohungen informieren und ihre Mitarbeiter entsprechend schulen.
   
   
8. Datenverluste
   Daten können nicht nur durch Hackerattacken verlorengehen, sondern auch durch versehentliche Löschungen, Naturkatastrophen und ähnliches. Anwender sollten sich über die Sicherheitsmaßnahmen ihres Providers informieren und bei besonders kritischen Daten eventuell das Vorhalten einer lokalen Kopie erwägen.
   
   
9. Nicht erfüllte Sorgfaltspflicht
   Unter diesem Punkt fasst die CSA die mangelhafte Recherche der Kunden über die Rahmenbedingungen des Cloud-Computing zusammen.
   
   
10. Missbrauch von Cloud-Services
    Aufgrund der hohen Rechenleistung und des nahezu unbegrenzten Speicherplatzes werden Cloud-Services gerne auch für kriminelle Aktivitäten verwendet, wie etwa das Knacken von Passwörtern oder DDoS-Attacken. Cloud-Provider benötigen daher Mechanismen, um solchen Missbrauch zu entdecken, sowie eine Möglichkeit, damit Kunden und andere Anwender entsprechendes Feedback liefern können.
    
    
11. DoS-Attacken
    Denial-of-Service-Angriffe können ganze Cloud-Systeme abbremsen oder sogar komplett in die Knie zwingen. Umso wichtiger sind ein Monitoring der Systeme sowie bereits vorbereitete und ständig erreichbare Abwehrmaßnahmen.
    
    
12. Schwachstellen in geteilten Systemen
    In der Cloud teilen sich mehrere Anwender die gleiche Infrastruktur, Plattform oder Applikation. Eine Schwachstelle kann daher das gesamte Cloud-Angebot eines Providers betreffen. Notwendig sind daher eine umfassende Sicherheitsstrategie sowie Maßnahmen wie eine Multifaktor-Authentifizierung sowie host- und netzwerkbasierte Intrusion-Detection-Systeme.

Microsoft selbst ist auch Mitglieder Cloud Security Alliance, hat die gelisteten Aspekte im Blick und verwendet die von der CSA definierte Control Matrix. Weitere Informationen finden sich in unserem TrustCenter.

Gastbeitrag von Michael Kranawetter, National Security Officer (NSO) bei Microsoft in Deutschland. In seinem eigenen Blog veröffentlicht Michael alles Wissenswerte rund um Schwachstellen in Microsoft-Produkten und die veröffentlichten Softwareupdates.

Microsoft lance une programme pour vous permettre des tester et de valider vos solutions dans le cloud.

Les détails complets du programme son disponible sur le blogue du groupe de produit

Bon test.

Already sick of your holidays and want to go back to school? Or you just like to further your knowledge of technology in the classroom? The Teacher Ambassadors are planning a catch up in Auckland during the school holidays!

We will use this time to connect with other teachers using Office 365, share ideas and learn new tips and tricks. The Teacher Ambassadors and Microsoft Innovative Educator Expert teachers will run short workshops on Sway, Office Mix, OneNote and be available to talk about any other areas you wish to discuss or learn more about.
 

The content covered in the sessions will be similar, therefore choose the session that is located nearest to you. 

Auckland Sessions:

Auckland Microsoft Holiday Session, Opaheke School, 28th April 2016 - 10am

Auckland Microsoft Holiday Session, Baradene College, 29th April 2016 - 10am 

For the purposes of catering please register your interest by sending an RSVP t-jegilb@microsoft.com including which session you would like to attend. Please feel free to share these events with any teachers that may be interested in attending. 

Here is an overview of both of the Auckland sessions in case you were on the fence about which one to attend:

Don't miss out on this amazing opportunity, make sure you email t-jegilb@microsoft.com to register for the session you wish to attend or if you have any questions about these sessions. If you would like to learn more about the Teacher Ambassadors and what they do feel free to check out their website.

Alerting in OMS was recently updated with the GA release. One of the great features this offers is the ability to automatically trigger an Azure Automation Runbook.

There are already some great blogs out there, but in this series I wanted to take a simple look how this works, now it's generally available.

This is part 1.

link to part 2

link to part 3

Triggering a simple Runbook

In this first blog we'll look at how to create a basic Runbook which is triggered by an OMS Alert.

The Runbook will simply write out the details of the alert.

Step 1: Create a Runbook

To start, let's create the Runbook which we want to be trigged by an alert.

Go to your Automation account & create a new Runbook. Here, I've created a PowerShell Workflow Runbook called OMSAlertTrigger:

This Runbook will take the alert information as the input. To do that, we need to create an input parameter called $WebhookData.

OMS will automatically handle passing the alert detail into the $WebhookData parameter.

This $WebhookData is documented at https://azure.microsoft.com/en-us/documentation/articles/automation-webhooks/ if you want to know more.

Essentially, it has 3 bits of information in its payload:

• WebhookName
• RequestHeader
• RequestBody

So we can understand what these 3 things are, this first Runbook is just going to write each of them as output.

In my Runbook, I entered the following PowerShell to write out the WebhookData info. Next, I clicked Save and then Publish.

NOTE: I have not manually created a Webhook on this Runbook. OMS will do this for me automatically.

Step 2: Create an on demand Alert

OK, now it's time to trigger the Runbook from an alert!

I've already configured OMS to collect the Application event logs from my Windows agents. Therefore, I know I can create an alert, based on anything in this event log.

In case you're not collecting Event Log data, it's configured from Settings > Data:

For this example, I want to be able to manually create an event, so I can test my Runbook on demand.

To do this, I'm using the Write-EventLog cmdlet in PowerShell.

Simply, go to any machine which is reporting to your OMS workspace, and run the following PowerShell:

Write-EventLog -LogName Application -Source MsiInstaller -EventId 123 -Message "hello"

Shortly after, I can see this in the OMS Log Search, by running the following query:

Type=Event EventID=123

And I can see the entries where I've created this event manually:

I want to setup an alert for this Event 123. So I click the Alert button:

Here's how I've configured my alert:

• You can see I'm checking every 5 minutes
• The Threshold is > 0, so this will fire if there are any 123 events
• I've configured this to send me an email
• Finally, you can see I've picked out to run my OMSAlertTrigger runbook

Click Save to activate this alert

Step 3: Trigger the Alert

OK! Now we're ready to see this in action.

I'll go to one of my OMS Agents and run the following PS to raise event 123 in the event log:

Write-EventLog -LogName Application -Source MsiInstaller -EventId 123 -Message "hello"

Shortly after, I got the email from my alert!

OK so hopefully this will have trigged our Runbook! To see this:

• Go to your Automation Account in the portal
• Click on the Jobs tile:

• You should be able to see the OMSAlertTrigger has run:

   

• Click this job to see the details

In the details of this Job, we can see it completed successfully.

Click Output to see what our Runbook Wrote out:

Remember, the Runbook wrote out the following:

    Write-Output $WebhookData.WebhookName

    Write-Output $WebhookData.RequestHeader

    Write-Output $WebhookData.RequestBody

That's what we can see in the screenshot above.

• WebhookName: Not that useful for us
• RequestHeader: Can see some information in there from the header. Again, not that useful
• RequestBody (in the red square): This is useful! This is all of the detail from the alert!

So you may be thinking that all that info looks a little cryptic! Don't worry, that's what we'll look at in Part 2…

Alerting in OMS was recently updated with the GA release. One of the great features this offers is the ability to automatically trigger an Azure Automation Runbook.

There are already some great blogs out there, but in this series I wanted to take a simple look how this works, now it's generally available.

Link to Part 1

Link to Part 3

Working with alert data

In the first blog, we saw how to trigger a Runbook from an OMS Alert.

In this blog, we'll look at the output data & how to extract useful information.

Step 1: Reading $WebhookData.RequestBody

In the last blog, we saw that all the useful info was in $WebhokData.Requestbody.

This looked a little cryptic, something like the below. Probably not what you want to read when sipping your morning coffee J

This is JSON data & we can easily parse this out in our Runbook. However, before we do that, let's just take a look at this info.

To read it manually, I did the following to make it easier:

• Copied the $WebhokData.Requestbody info from the Output screen
• Pasted it into a Visual Studio Code
• Saved as output.json
• Formatted the code (Alt Shift F) so it's easier to read!

Now that's easier to look at! I've highlighted some of the useful bits below:

• All of the content is inside SearchResults
• In Green, you can see there are 2 main sections:
  • __metadata shows us some metadata about the OMS search
  • value: This contains the actual event
• In Red you can see I've pulled out specifics, such as the Computer the event was on, the event log, the event ID & we can see the contents in the ParameterXml.

Step 2: Parsing the RequestBody

How do we read this JSON data & make use of it in our Runbook? Luckily PowerShell is to the rescue here!

This output is JSON formatted data, so all we need to do, is use the ConvertFrom-Json cmdlet.

Next up, I'm going to go back to my OMSAlertTrigger Runbook & click Edit.

First up, I will get delete $WebhookData.WebhookName and $WebhookData.RequestHeader, as I don't care about those right now.

Next, I'll use ConvertFrom-Json to load the RequestBody into a PowerShell object. This makes it much easier to navigate through the JSON.

For example, below we get the converted JSON and put it in $alertData

$alertData = ConvertFrom-Json $WebhookData.RequestBody

I can now navigate to the EventID using $alertData.SearchResults.value.EventID

Before I complete this, I've got two scenarios I want to cope with:

• What if the WebhookData is empty
• What if there are more than 1 alerts passed in the results (multiple value tags in the JSON)

Taking this into consideration, here's my new OMSAlertTrigger Runbook. A few notes:

• Line 5: We check the WebhookData isn't null. If it is, we write an error
• Line 6: Converts the JSON data into a PowerShell object
• Line 8: In case there are multiple alerts, we loop through each value in the SearchResults
• Line 9: I've selected a few elements from the JSON and written them out in a friendly way

Save & Publish the new Runbook!

Step 3: Trigger the updated Runbook

As before, I'll trigger the Runbook by manually raising event 123 on one of my OMS managed machines. I ran this several times, to rest out multiple alerts:

Write-EventLog -LogName Application -Source MsiInstaller -EventId 123 -Message "hello"

I'll wait for a moment to get the Alert notification, then check the Runbook Job in the portal.

Now if we look at the Job Output, we can see I raised the event 123 four times on the computer SQL.contoso.work.

The OMS Alert picked this up had occurred 4 times, so triggered the Runbook with al 4 alerts in the Web hook Data.

In the output, we can see that we parsed out each alert & wrote the output in a friendly way:

Great! So, now we know how to trigger the Runbook and read out the alert details in a straightforward way.

What other cool stuff can we do with this capability? That's what we'll look at in part 3

Alerting in OMS was recently updated with the GA release. One of the great features this offers is the ability to automatically trigger an Azure Automation Runbook.

There are already some great blogs out there, but in this series I wanted to take a simple look how this works, now it's generally available.

Part 1 link

Part 2 link

Triggering child Runbooks

In the previous blogs, we saw how to trigger a Runbook from an OMS Alert & read out the alert details.

Over the years, working with Automation tools, like System Center Orchestrator, I've become a fan of keeping my Runbooks simple!

Having big, monolithic Runbooks might look cool, but they can be a pain to troubleshoot & maintain. Splitting bigger tasks into small Runbooks also brings benefits, such as the ability to reuse!

In the spirit of this, the model I suggest is:

• Create a Trigger Runbook, which is triggered from the OMS Alert
• The trigger Runbook can parse the Alert RequestBody & then go and start another Runbook to complete a task

Why?

• If you've already got a Runbook which does something, you don't have to modify it to handle WebhookData input
• If you've got an existing PowerShell script, you can put it into Azure Automation, without having to alter the parameters

I also think it's cleaner to separate out the parsing of the alert data & the actual Remediation Runbook.

Step 1: Create a child Runbook

This is the Runbook which I want to be triggered by my existing OMSAlertTrigger Runbook.

I created a new Runbook called OMSAlertTriggerChild

I've just created a very basic Runbook, which takes 3 parameters.

Each parameter is simply written out. I saved & Published this Runbook.

Step 2: Call the child Runbook

Next, I've gone back to OMSAlertTrigger. I want to modify this, so it triggers the child Runbook instead of writing out data.

You can see below, I simply needed to call the Runbook OMSAlertTriggerChild by name & pass in the 3 parameters it accepts.

You can add it easy from selecting 'Runbooks' > Right click > Add to canvas:

You may have noticed I also added in -parallel so it can parse the alerts in parallel!

I then saved & published this Runbook

Step 3: Trigger the updated Runbook

As before, I'll trigger the Runbook by manually raising event 123 on one of my OMS managed machines. I ran this several times, to rest out multiple alerts:

Write-EventLog -LogName Application -Source MsiInstaller -EventId 123 -Message "hello"

I'll wait for a moment to get the Alert notification, then check the Runbook Job in the portal.

First thing you'll notice – you only see the Job for the OMSAlertTrigger, we don't see a separate job for the child Runbook:

However, if I look in the output for OMSAlertTrigger, I can see it shows me the output from the OMSAlertTriggerChild Runbook.

This is a lot simpler – I don't have to worry about linking job outputs together. I can simply see the output, although it called my child Runbook:

What about Hybrid Runbooks?!

In case you've not seen it, we can use the Hybrid Worker to run the Runbook in your datacenter. This is easy to setup, more info is at https://azure.microsoft.com/en-us/documentation/articles/automation-hybrid-runbook-worker/.

This is also exposed when we setup an Alert in OMS. In the screenshot you can see this time, I've selected to run on Hybrid Worker and selected my hybrid workers.

That's OK, but what about the Child Runbook? Although I've clearly indicated I wanted OMSAlertTrigger to run on my hybrid worker, where will OMSAlertTriggerChild be run? Obviously, I want this to be run on the hybrid worker also.

To test this out, I added a line to my OMSAlertTriggerChild Runbook, to write out the name of the machine it's running on:

Great News! It triggered my child Runbook on my Hybrid Worker too! J

As we can see in the screen below, the Parent Runbook Ran on prem. (see 'Ran on').

The Child runbook, which wrote the output said it's running on DC01, which is my on-prem hybrid worker.

To conclude

It sometimes makes sense to split up your Runbooks into bitesize pieces. It's often easier to manage, you may end up re-using parts!

If you trigger a Runbook on a Hybrid Worker & it calls another Runbook – that child Runbook is Run on the Hybrid worker also.

One final note – You can run an Azure Automation Runbook from PowerShell, using Start-AzureRmAutomationRunbook. This accepts the RunOn argument, which allows you to select it to Run on a Hybrid Worker. Let's say you wanted to trigger one Runbook from another, but have that run on a different Hybrid Worker, then that's how it could be done.

We have released the 1.1 update for Skype for Business Server Statistics Manager Server.  If you have previously deployed Statistics Manager, refer to the upgrade section below.

What’s new  in Release 1.1

The following describes what's new in Release 1.1. If you have an existing deployment of Statistics Manager and you've not yet upgraded, see Upgrade Statistics Manager for Skype for Business Server 2015.

• Scenario views have been added for Edge Media, Fabric Health, Pool Failover and Registration scenarios.

• Command line PerfAgentStorageManager.exe (installed with the Listener) can now export counter data as a CSV.

• Many new counters have been added for SQL servers, more Windows Fabric counters, more Skype for Business usage counters, and so on.

• Watcher node integration for the Statistics Manager Agent – if the Agent is installed on a watcher node, it will report synthetic transaction statistics as counters back to Statistics Manager.

• Numerous reliability and performance improvements.

To verify the version of the Statistics Manager Website you are running:

• In File Explorer, open (default directory) C:\Program Files\Skype for Business Server StatsMan WebSite\bin

• Right click on StatsManHubWebSite.dll and view its properties

• The product version will be shown in the Description details.

Plan for Statistics Manager for Skype for Business Server 2015

https://technet.microsoft.com/en-us/library/mt604835.aspx

Deploy Statistics Manager for Skype for Business Server 2015

https://technet.microsoft.com/en-us/library/mt604837.aspx

Upgrade Statistics Manager for Skype for Business Server 2015

https://technet.microsoft.com/en-us/library/mt703766.aspx

Download

https://www.microsoft.com/en-us/download/details.aspx?id=49491

2016/4/6 (米国日付 2016/4/5) にリリースされた Office 2013 の更新プログラム KB3114928 (英語日本語機械翻訳) を適用すると Outlook 2013 と Lync 2013 (Skype for Business) 利用時にランダムにクラッシュが発生する場合がある不具合を確認しており、以下のサポート技術情報 3158521 を公開しておりますのでご確認ください。
この問題について進捗がありましたら本ブログの情報を更新いたします。

KB3158521 Lync 2013 (Skype for Business) or Outlook 2013 Crash

クイック実行版の Office (Office 365 ProPlusや 店頭で購入したダウンロード版など) :
・現時点では、配信停止や再リリースはされていない。
・適用されている場合は Outlook 2013 の [ファイル] タブ-[Office アカウント] に
  「バージョン: 15.0.4815.1001」と表示される。

MSI 版の Office (ボリュームライセンスなど) :
・現時点では、配信停止や再リリースはされていない。
・適用されている場合は Outlook 2013 の [ファイル] タブ-[Office アカウント]-
   [Outlook のバージョン情報] をクリックした画面の MSO の右側に「15.0.4815.1000」と表示される。

回避方法
以下のいずれかの方法での対応をお願いいたします。

方法 1. KB3114928 をアンインストールし、以前のバージョンに戻す

クイック実行版の Office (Office 365 ProPlus や 店頭で購入したダウンロード版など)  :
・こちらのブログ  の手順に従って以前のバージョンに戻す  (参考: KB2770432 (英語日本語機械翻訳))
   (コントロール パネルの [プログラムの機能] からアンインストールすることはできない)

MSI 版の Office (ボリュームライセンスなど) :
・コントロール パネルの [プログラムと機能] から KB3114928 をアンインストールする
・WSUS で KB3114928 に対して [削除の承認] を設定してアンインストールを配信する (こちらのブログの「WSUS での配布の停止手順」を参考に設定してください)

方法 2. レジストリ MSOAuthDisabled を作成する

HKEY_CURRENT_USER\Software\Microsoft\Exchange
値の名前: MsoAuthDisabled
値の種類: 1

参考:
Outlook 2013 では、2014/9 以降の更新プログラムが適用されている場合は
従来の Windows の機能を利用した認証ではなく、Office 固有の認証システムで認証が行われます。
上記のレジストリを設定すると、Office 固有の認証システムではなく、
従来の Windows の認証システムを用いて認証を行うように動作が変更されます。

Office 固有の認証システムは以下の認証を利用するために必要であり、
これらの認証を利用している場合はレジストリで回避することができませんが、
これらの認証を利用する必要がない場合は特に影響はありません。

・多要素認証
・Azure Active Directory 認証ライブラリによる認証
・スマートカード認証

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

こんにちは。日本マイクロソフト Outlook サポート チームです。

Outlook 2013 以降では、Windows 8 以降の OS 上において、Outlook 独自のデスクトップ通知ではなく、Windows のデスクトップ通知を使用するようになりました。

本記事ではその詳細を説明します。

デスクトップ通知について

デスクトップ通知は、新規メールや会議出席依頼などを受信したときにデスクトップに表示される通知です。

Outlook 独自のデスクトップ通知

Windows のデスクトップ通知 (Windows 8 以降)

どちらのデスクトップ通知が使用されるか

使用するバージョンによって、Outlook 独自のデスクトップ通知を使用するか、Windows のデスクトップ通知を使用するか、異なります。(表 1 参照)

これは、Windows 8 以降でストア アプリを全画面で使用している状態でも、Windows のデスクトップ通知により新着メールの通知ができるための機能変更となります。

(表 1) バージョンごとのデスクトップ通知の表示

O: Outlook 独自のデスクトップ通知
W: Windows のデスクトップ通知

[デスクトップ通知の設定] ボタンについて

Outlook 独自のデスクトップ通知の場合、[ファイル] タブ –[オプション]-[メール]-[メッセージ受信] の [デスクトップ通知の設定] ボタンより表示時間や透明度の設定変更がすることができました。(図2, 図3 参照)

一方、Windows のデスクトップ通知では Outlook 独自の通知のような細かい制御はできないため、[デスクトップ通知の設定] ボタンは表示されません。(図 4 参照)

(図 2) Windows 7 + Outlook 2016 の画面

(図 3) デスクトップ通知の設定画面

(図 4) Windows 10 + Outlook 2016 の画面

デスクトップ通知の ON/OFF 切り替えについて

通知の ON/OFF の切り替えは Windows の通知設定画面でも Outlook のオプション設定からでも可能となり、どちらかが OFF に設定されていたらデスクトップ通知は表示されません。

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

 TechNet 論壇 是一個可以讓 IT 專業人員們自由提出問題、尋找資訊的好地方，歡迎大家多多利用，與社群中的同好們一同分享 Microsoft 技術資訊。

而我們會不定期整理論壇精選給大家，希望對您的學習有所幫助！以下為 2016 02/16 - 2016 04/07 的論壇精選，感謝 TechNet 小幫手的協助。

現在只要到微軟社群之星學院提出您的疑問，就有機會每個月抽好禮還有專人為您解答，參加請點這裡，我們更提供不收費線上課程 Channel 9 讓您尋求更多知識。