Quantcast
Channel: TechNet Blogs
Viewing all 34890 articles
Browse latest View live

Die Executive Order zum Einreiseverbot ist ein fundamentaler Rückschritt

$
0
0

Auf Grundlage einer am 27.01.2017 erlassenen Executive Order wird Menschen aus sieben Ländern für die kommenden 90 Tage die Einreise in die USA verwehrt.

Wir als Unternehmen glauben, dass die Politik dieser Executive Order fehlgeleitet ist und einen fundamentalen Rückschritt darstellt. Es gibt effektivere Wege, die öffentliche Sicherheit zu wahren, die gleichzeitig dem Ansehen und den Werten der Vereinigten Staaten keinen derartig großen Kollateralschaden zufügen.

Bereits am Samstag wandte sich Brad Smith, Präsident und Chief Legal Officer der Microsoft Corporation, an alle Mitarbeiter:

 “As a company, Microsoft believes in a strong and balanced high-skilled immigration system.  (…) And we believe in the importance of protecting legitimate and law-abiding refugees whose very lives may be at stake in immigration proceedings.”

Auch wenn das erlassene Einreiseverbot nach aktuellen offiziellen Angaben des US-Heimatschutzminister Kelly nun doch nicht für Doppelstaatler gilt, möchte ich hier auf unserem Blog den offenen und wichtigen Worten von zwei Kolleginnen mit doppelter Staatsbürgerschaft Raum geben. Mich als Personalchef von Microsoft Deutschland und viele weitere Mitarbeiterinnen und Mitarbeiter hat es sehr bewegt, dass Sepideh Schönfeld und Mohanna Azarmandi sich in diesen Tagen in sehr persönlicher Art und Weise zu dem Dekret geäußert haben. Die neue Sachlage hat zwar ihre geschilderte unmittelbare, individuelle Betroffenheit in der Zwischenzeit aufgehoben, nicht aber die Relevanz ihrer Worte und den darin liegenden Appell. Denn die Förderung eines vielfältigen und integrativen Miteinanders unabhängig von Herkunft, Hautfarbe, Religion, Geschlecht oder sexueller Orientierung sind uns ein besonderes Anliegen sowie zentraler Bestandteil unserer Unternehmenskultur und unseres Wertesystems – gerade und erst recht in Zeiten wie diesen.

Sepideh Schönfeld arbeitet als Business Developerin in unserer Hamburger Niederlassung. In ihrer Rolle fliegt sie häufig in die USA. Als erste Reaktion auf die Executive Order wandte sich Sepideh kurz danach mit einer E-Mail an unsere Belegschaft:

“Liebe Kolleginnen und Kollegen, (sorry for spamming your inbox, aber das Thema ist mir wichtig),

vielleicht haben einige von euch die Schlagzeilen am Wochenende verfolgt und das Schreiben von Brad Smith (s. weiter unten) hinsichtlich der neuen Executive Order von Donald Trump aufmerksam gelesen. Ich möchte euch heute darauf aufmerksam machen, dass diese Anordnung nicht nur drastische Auswirkungen hat auf Flüchtlinge oder Reisenden aus den 7 besagten “suspekten” Ländern, sondern auch auf Kollegen und Kolleginnen von euch aus Deutschland, die ebenso unter “Generalverdacht” gestellt werden.

Ich bin eine der vielen deutschen Staatsbürger, die durch diese Anordnung unter Generalverdacht gestellt wird und nicht mehr in die USA einreisen können, sofern die Executive Order bestehen bleibt. Ich lebe seit meinem 2. Lebensjahr in Deutschland und trage seit meinem 16. Lebensjahr die deutsche Staatsbürgerschaft, ebenso jedoch auch die iranische Staatsbürgerschaft (die man nicht abgeben kann, selbst wenn man wollte). Dies wird mit Sicherheit noch auf weitere zahlreiche Microsoft Kollegen sowie auf etliche andere deutsche Mitbürger mit Migrationshintergrund (vielleicht auch auf Freunde und Bekannte von euch) zutreffen, die aufgrund beruflicher oder persönlicher Situation eine regelmäßige Reise in die USA durchführen müssen und denen dies nun verweigert wird.

Diese Diskriminierung ist nicht nur ein persönlicher Schlag für die Betroffenen, sondern wirft für uns als globales Unternehmen, das Diversity und Inclusion fördern möchte, viele Hindernisse und Fragen auf.

Ich wünsche mir von Microsoft und meinen Kollegen, dass wir uns alle dieser Probleme bewusst werden, Familie und Freunde darauf aufmerksam machen und gemeinsam aus Deutschland heraus gegen solch eine Bewegung ankämpfen. Insbesondere wünsche ich mir, dass wir alle dafür kämpfen, dass ähnliche Bewegungen in Deutschland KEINE Unterstützung erfahren.

Danke euch!

Sepideh

Diversity + Inclusion = Success”

Sepideh hat darüber hinaus im ZDF Stellung bezogen:

 

 

Unsere Münchner Mitarbeiterin Mohanna Azarmandi lebt seit ihrem 7. Lebensjahr in Deutschland und besitzt sowohl die deutsche, als auch die iranische Staatsbürgerschaft. Auch wenn das Einreiseverbot als Doppelstaatlerin nun doch nicht für sie gilt, teilte sie uns ihre Betroffenheit offen mit.

img_3887

„Ich bin im Iran geboren und lebe seit meinem 7. Lebensjahr in Deutschland und habe (genauso wie meine Eltern und meine beiden Schwestern) die deutsche Staatsbürgerschaft (die iranische Staatsbürgerschaft habe ich seit meiner Geburt und kann sie nicht ablegen, ob ich das will oder nicht). Ich bin Business Program Managerin bei Microsoft und arbeite von Deutschland aus für unsere Corporation in den USA. Ich war bisher immer in internationalen Rollen tätig, so dass ich zwei bis drei Mal im Jahr beruflich in den USA bin. Meine nächste Reise ist für März/April geplant. Die Executive Order von Präsident Trump erlaubt es mir nun vorerst nicht mehr, als so genannte Doppelstaatlerin, in die USA einzureisen. Es wird sich zeigen, was das für meine Rolle in einem international agierenden Team bedeutet.

Wie fühle ich mich damit? Die erste Antwort ist tatsächlich: Diskriminiert, wegen etwas, dass ich nicht beeinflussen kann. Mein Geburtsort scheint demnach auszureichen, um mich unter Generalverdacht zu stellen. Ich bin aber auch unendlich traurig, dass wir im Jahr 2017 weiterhin Menschen wegen ihrer Herkunft oder Religion beurteilen und ausschließen. Meine persönliche Betroffenheit ist ärgerlich, aber weit mehr berührt mich, was die Order für Menschen bedeutet, die ihre Familien nicht sehen können, diejenigen, die aus ihrer Heimat fliehen mussten und Hilfe brauchen.

Ich bin stolz auf meinen Arbeitgeber Microsoft und auf meine Arbeitskollegen, die klar Stellung beziehen und sich für eine Minderheit der Mitarbeiter einsetzen Diversity & Inclusion ist nicht nur ein Leitfaden für uns, es wird gelebt. Wir, nicht nur Microsoft und seine Mitarbeiter, wir alle haben die Verantwortung, ein Zeichen gegen Diskriminierung zu setzen. Sowohl in den USA als auch in Deutschland.”

Nicht zuletzt möchte ich noch auf das Statement unseres CEO Satya Nadella hinweisen, der in einem LinkedIn Post mit Bezug auf seinen persönlichen Lebensweg betonte:

“As an immigrant and as a CEO, I’ve both experienced and seen the positive impact that immigration has on our company, for the country, and for the world. We will continue to advocate on this important topic.”

Mehr zu unserer Unternehmenskultur und zu Diversity @ Microsoft kann hier nachgelesen werden.

Ein Beitrag von Markus Köhler
Senior Director Human Resources und Mitglied der Geschäftsleitung von Microsoft Deutschland

Markus_Koehler


Email destined for recently migrated Modern Public Folder are going to the Poison queue.

$
0
0

Scenario

I recently worked a case where the customer had moved all of the public folders from one Modern Public Folder mailbox to another and deleted the old Public Folder mailbox. This was on Exchange 2013 CU9. After he did that, email destined for what were previously mail-enabled Public Folders started to show up in the Poison queue. When we did a get-mailpublicfolder against one of the Public Folders (lets call it pf using SMTP address pf@instant-grits.com) we found the following:

ContentMailbox      : instant-grits.com/Deleted Objects/PFMbx01

The correct email address is specified under the EmailAddresses property.

So here’s the problem; Exchange still sees the mailbox content as being on the Deleted Object, aka the old Public Folder Mailbox server.

We also noted that the new public folder was not automatically being mail-enabled after being migrated from one Public Folder Mailbox to the other. So we tried to mail-enable it using the enable-mailPublicFolder. It mail-enabled, but the email addresses it assigned were enumerated, so not the original email address. This will cause mail stuck in the poison queue to never be able to successfully deliver to the new folder.

Why is this happening to me?

In a nutshell, the Microsoft Exchange System Object (MESO) that exists for that public folder is still attached to the deleted public folder. Since the MESO holds the mail properties for a mail-enabled object, mail-enabling the new folder will not be able to use the old address. Since pf@instant-grits.com is not available, the new object gets an enumerated version of it, so pf1@instant-grits.com. Since that does not match the address, and there is no X500 pointed to the deleted folder, Exchange does not know how to deliver it. Since the old address does exist, Exchange will try, but it will then go to the Poison queue as the Folder it is trying to go to is a deleted object.

So what do I do about it?

As always, you ask the best questions. Let’s assume the public folder is in the following location in the public folder tree: thingsthatgowithgritsshrimppf.

There are 5 steps to cleaning this up and getting your messages in the Poison queue and new messages to deliver successfully to the Public Folders in the new Public Folder Mailbox:

  1. Mail-disable all of the public folders in the new Public Folder Mailbox. You can do this from the Exchange Admin Center (EAC), or by using the disable-mailpublicfolder cmdlet using the full public folder path of the public folder, like such:disable-mailpublicfolder “thingsthatgowithgritsshrimppf”
  2. Once all of the public folders in the new Public Folder Mailbox have been mail-disabled, you need to find and delete all of the MESO objects that have the same name as the public folders you are cleaning up. Make sure you capture the SMTP address of those MESO objects. They should be in the EmailAddresses property of the get-mailpublicfolder cmdlet you ran earlier. A quick script that Bill Long wrote and I modified very slightly can dump all of the MESO objects to a Text file. From there you can sort it and go to Active Directory Users and Computer. Make sure you have it in Advanced view. Then browse to the Microsoft Exchange System Objects container, which is at the root of the domain, and delete all of the appropriate MESO objects. The script looks as follows:$mesoDN = “CN=Microsoft Exchange System Objects,DC=instant-grits,DC=com”
    $mesoContainer = [ADSI](“LDAP://” + $mesoDN)
    $sysMbxFinder = new-object System.DirectoryServices.DirectorySearcher
    $sysMbxFinder.SearchRoot = $mesoContainer
    $sysMbxFinder.PageSize = 1000
    $sysMbxFinder.Filter = “(cn=*)”
    $sysMbxFinder.SearchScope = “OneLevel”
    $sysMbxResults = $sysMbxFinder.FindAll()
    $sysMbxResults.Path > c:MESOObjects.txt
  3. Once all of the appropriate MESO objects have been deleted, wait until Active Directory has finished replicating the change. For single site environments, this is pretty instant. For multi-site environments, it will depend on your AD topology. It will take as long as your longest and slowest route. Ask your network guy how long that should be.
  4. Now that we are fully replicated, we can mail-enable the public folders. You can do this from the Exchange Admin Center (EAC), or by using the enable-mailpublicfolder cmdlet using the full public folder path of the public folder, like such:enable-mailpublicfolder “thingsthatgowithgritsshrimppf”Using the enable-mailpublicfolder cmdlet in my lab has produced mixed results, sometimes it works, sometimes it doesn’t, likely due to AD replication or my Exchange environment being on too old of a Cumulative Update (CU). So be prepared to do it manually from the EAC.
  5. Once all of the public folders that are going to be mail-enabled have been, you can then go into the queue viewer and browse the poison queue. From there you should be able to select all messages and then click on Resume. If the resume fails for any reason, you either missed cleaning up one or more of the public folders, or there are messages that are in the poison queue for some other reason. At that time you are ready to bounce the transport service. You can do that from the Exchange Management Shell with the following command:
    stop-service MSExchangeTransport
    then
    start-service MSExchangeTransport
    After restarting the queue, you can wait for the Poison Queue to reattempt deliver on its messages. All that have properly cleaned up public folders should then deliver.

Note

I do strongly urge you to get and keep your Exchange servers at a fully supported cumulative update level. That level is N-1. So the latest version minus 1. If we are currently at CU16, then you need to be at least on CU15.

Special Thanks:

Thanks to Bill Long for his impressive blogs on the topics of MESO objects. The one in particular that I referenced in this blog is as follows:

http://bill-long.com/2014/01/11/cleaning-up-microsoft-exchange-system-objects/

Also thanks Matthew Huynh for offering up his lab to me so I can test the scenario.

Switching from FIM to AD Import on SharePoint 2013 farms

$
0
0

SharePoint 2013 offers multiple ways to import user accounts to the User Profile Service Application (UPSA). Our formerly best friend, the Forefront Identity Manager (FIM), which was introduced in SharePoint 2010, is still the default option to get this job done in SharePoint 2013. Good news for all of you folks who never liked this one: the simple LDAP querying AD import option (that was used in SharePoint 2007) is available again. Spencer wrote a really good article about AD Import for all of those who are not familiar with it.

Most customers are typically still setting up and operate their SharePoint farms using FIM. Eventually some are switching to the AD Import mode later. Those customers did not find any guidance on this task, that is the reason why I am writing this article.

There might be multiple reasons for customers to make the decision to move away from FIM. Performance and reliability are probably the most important ones, but there could be other reasons as well. Switching to AD Import might also be a good idea as a preparation for SharePoint 2016, that no longer contains FIM.

This article is supposed to give you a further insight and configuration guidance as well as the possibility to understand the differences between FIM and AD Import.

General Understanding and Comparison

The most important message right upfront: The light-weight Active Directory Import option is having limitations. Make sure you are aware of the differences before changing a productive FIM operated synced User Profile Service Application.
The most important facts (there are much more in total) at a glance:

  • AD Import is one way only (Import)
  • Replicating Directory Changes permissions are still necessary for to the account used within the sync connection
  • User Profile Sync DB is no longer used. Existing FIM Sync Connection information are stored in the Sync DB. This needs your urgent attention in the need of manually recreating sync connections and configuration (sync filters, profile property mappings, etc). I’ll explain this later in detail
  • Any additional data coming from line of business systems (via BDC) cannot be imported using AD Import. FIM is required for such Scenarios

 

Comparison matrix

FIM - AD Import Comparison Matrix

 

How to switch to AD Import – Step by Step

1. Preparation: Do some important reading upfront

Before you switch from an existing SharePoint Profile Synchronization (FIM) to the lightweight AD Import mode, you should understand that these two models are not doing the same things. AD Import is having limitations. Carefully read this article and carefully read TechNet documentation. I did see customers skipping this step and they caused themselves extra work and trouble.
Read and understand:

 

2. Preparation: Create a documentation of current settings

This step is crucial.
Skipping this one might get you in big trouble. Make sure you create a current documentation of all existing:

  • Sync Import Connections
    • Fully Qualified Domain Name
    • Sync Service Account
    • OUs to Sync
    • Sync Port
    • SSL yes/no
  • Sync Import Filters
  • Profile Property Mappings
  • User Profile Import Service Account credentials

 

3. Modify SharePoint Service Monitoring

If any monitoring software is surveilling the Forefront Identity Manager Synchronization Service (FIMSynchronizationService), which is running in FIM / SharePoint Profile Synchronization mode, you should disable this monitoring rule before touching anything. Changing the sync to AD Import is going to stop this service. This would cause monitoring software to create alerts about stopped services.

 

4. Change/Configure Synchronization Settings

This is where we are finally changing the import behavior. In Central Administration (User Profile Service Application) you pick the Configure Synchronization Settings and change the Synchronization Options to Use SharePoint Active Directory Import.
After applying this setting, following things are happening within seconds:

  • The Windows Forefront Identity Manager Synchronization Service (FIMSynchronizationService) is changing its state from started to stopped and is disabled
  • Sync Connection list in the UPSA is now empty, due to the fact, that the existing FIM sync connections are stored within the UPSA sync database, which is no longer in use
  • Any Profile Property Mappings that have been in place must be reconfigured. Again, this is because the UPSA Sync DB is no longer in use.
  • The timer job that is triggering the sync jobs is enabled: ([Name-of-UPSA] – User Profile ActiveDirectory Import Job)

 

5. Create Sync Connection

With switching from FIM to Active Directory Import Sync Connection information must be created again. So go ahead, grab your documentation and set up all of your required sync connections.

 

6. Create Import Filters

Apply all import filters that you need for each sync connection. This must be done using LDAP queries. This is something, that is different than it used to be using FIM. You are not using the GUI based filter builder, you need to specify what you want to import using a LDAP query. Benefit from that is that you have more control and possibilities, because any valid LDAP query could be used.

Be aware LDAP filters in AD Import mode are “include” filters, so you must define which accounts should be imported.

Example LDAP User Filters

  • Default user filter:
    (&(objectCategory=Person)(objectClass=User))
  • Exclude accounts with no email address and disabled accounts:
    (&(objectCategory=Person)(objectClass=User)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(mail=*))
  • Exclude disabled accounts:
    (&(objectCategory=Person)(objectClass=user)(!userAccountControl:1.2.840.113556.1.4.803:=2))
  • Exclude accounts with passwords set to expire:
    (&(objectCategory=Person)(objectClass=user)(!userAccountControl=65536))
  • Include only the accounts with valid email addresses
    (&(objectCategory=Person)(objectClass=User)(mail=*com)
  • Include only the accounts that are part of the LocationXY organizational unit
    (&(objectCategory=Person)(objectClass=User)(memberof:1.2.840.113556.1.4.1941:=(CN=AuthenticatedUsers,OU=LocationXY,DC=domain,DC=local)))
  • Exclude accounts that don’t have a first name
    (&(objectCategory=Person)(objectClass=User)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(!(!givenName=*)))
  • Exclude all service accounts (Accounts must have a valid title naming convention)
    (&(objectCategory=Person)(objectClass=User)(!(title=*Service Account*)))

Further Reading: MSDN: LDAP Search Filter Syntax

 

7. Create Profile Property Mappings

After sync connections are created and possible filtering is in place you should reconfigure any previous existing AD profile property mappings.

Example on how mappings look in FIM, before switching to AD Import mode:

FIM User Profile Property Mappings

All previously existing property mappings will be missing after switching to AD Import:

AD Import User Profile Property Mappings

To create profile property mappings navigate to the UPSA and to Manage User Properties. Select the property to modify and click on Edit in the context menu.

Be aware, that the GUI components are looking slightly different than they do using FIM. You have to explicitly enter the AD attribute name, you cannot choose existing attributes from the formerly existing drop down menu. Do not wonder about this. It’s not a bug it’s a feature 

How property mapping is looking while using FIM:

FIM Import Mapping

How to create a property mapping for AD Import

Create Import Mapping in AD Import

Also be aware of following limitations:

“We cannot map AD attributes to ‘system’ SharePoint Profile properties. These are the guys whose name begins with the SPS- prefix. We also cannot map two different attributes to the same profile property. We cannot do cross string type mappings (a value string attribute to a multi value string property or vice versa). “

(Spencer Harbar, First look on: SharePoint Server 2013 Active Directory Import)

 

“You cannot add multiple mappings or edit a mapping. To change mapping settings for a property, you must first remove the existing mapping, and then create a new mapping.”

(TechNet, Configure profile synchronization by using SharePoint Active Directory Import in SharePoint Server 2013)

 

8. Disable the daily FIM Synchronization Timer Job

After switching to AD Import a new sync schedule / timer job is in place. Unfortunately, the timer job that took care about the daily FIM synchronization is still enabled ([Name-of-UPSA] – User Profile Incremental Synchronization). This job obviously causes errors, because there is no more FIM sync service running, that could be triggered. This is the reason why you must disable the timer job manually to prevent this timer job to fail daily what would result in Windows Event log errors:

Log Name: Application
Source: Microsoft-SharePoint Products-SharePoint Foundation
Event ID: 6398
Task Category: Timer
Level: Critical
User: DOMAINFarmaccount
Computer: SERVER.DOMAIN.COM

Description:
The Execute method of job definition Microsoft.Office.Server.UserProfiles.UserProfileImportJob (ID 12413dce-9263-48bb-8fc2-ed6d71a920cb) threw an exception. More information is included below.

Operation is not valid due to the current state of the object.

Disable the timer job to prevent running into this trap:

Disable FIM Import Timer Job

 

9. Take care about AD accounts missing from import

This is a known issue using AD Import. To make a long story short: Any accounts that are disabled or deleted in AD and therefor are not imported, are not properly handled by AD Import. FIM could pick up these missing accounts and flag them properly, later timer jobs would delete the accounts from SharePoint. This process is not working using AD Import.

You should know this limitation before changing the sync mode and discuss if the known workarounds can be applied on your system.
Please refer to the blog article that is describing the behavior in detail: SharePoint 2013 : ADImport is not cleaning up User Profiles in SharePoint whose AD Accounts are disabled

 

Final Note

I hope this article helps you achieving the shift from FIM to AD Import.
Please share your experiences in the comments. Any feedback or additions for this post is highly welcome.

Thank you for rating this article if you liked it or it was helpful for you.

 

Application Development Partners: Introduction to Visual Studio Mobile Center

$
0
0

Jonathan Gardner, Technology Solutions Professional, Application Development

Recent conversations in the Cloud Application Development Partners community have been around DevOps and how its adoption can add value for companies that implement it and around the efficiency that Xamarin brings to the development process through the ability to reuse code. This month, we’ll talk about mobile development, a topic that I am frequently asked about when working with partners, with questions along the lines of, “If I am using Parse today, how does Azure compare?”

In this post, I’ll introduce you to Visual Studio Mobile Center, and explain how partners can take advantage of what it offers.

Visual Studio Mobile Center: Mission control for your mobile apps

Two things to know about Visual Studio Mobile Center:

  • Visual Studio Mobile Center is still in Preview, and there will be more services added as it matures.
  • Visual Studio Mobile Center carries the Microsoft commitment to open source forward, supporting applications written in Objective-C, Swift, Java, Xamarin, and React Native, with plans to support Cordova, UWP apps, and more services in the near future.

Visual Studio Mobile Center page

Sign up for Visual Studio Mobile Center

Visual Studio Mobile Center roadmap

Lifecycle services

Visual Studio Mobile Center is build with the tools and principles of the DevOps workflow in mind. Currently, there are three lifecycle services in Mobile Center: build, test, and distribute. They work together to automate the application lifecycle.

Build

The Mobile Center build service connects to a Git repository to create an installable package when code is committed or pushed to the repo. There is no requirement to provision machines running macOS to build iOS applications. Mobile Center handles the tasks of building and compiling iOS and Android applications from your code without any need for manual setup.

Test

Testing  plays a large role in any automated environment. Before the application can be distributed, Mobile Center offers a test cloud of more than 2,000 real devices in 400 unique configurations to test the application. Mobile Center supports multiple languages, and it’s no different with testing. Testing in C#(UITest), Ruby (Calabash), or Java (Appium) are all supported.

Distribute

After passing automated testing the application distribution function of Mobile Center alerts users that the application can be installed directly from their phones. This distribution method utilizes HockeyApp, now part of Visual Studio.

Monitoring services

Application analytics and telemetry are important for all applications but when testing mobile applications, there are additional metrics that are important for developers to review. Applications deployed through Mobile Center will collect crash information that provides a full stack trace about the crash, then prioritizes in the Mobile Center dashboard based on number of users seeing the issue. If you’re familiar with HockeyApp, the crash reporting service is based on the HockeyApp crash reporting features. Along with crash information, analytics on application use is also collected and to provide rich behavioral data on how people are using the app. These data are invaluable in streamlining future releases of the application.

Mobile backend services

Visual Studio Mobile Center functions as a front end for the power of Microsoft Azure. Mobile Center developers can take advantage of the robust identity capabilities offered by Azure Active Directory and scalable Azure Table storage services. Selective push notifications will soon be added to Mobile Center. Keep in mind, though, that you’re not limited to the services in Mobile Center. Developers that want to add advanced intelligence into their applications should take advantage of tools like Cortana Intelligence Suite and can add deep media integration through Azure Media Services.

Resources

Community call about Visual Studio Mobile Center on February 7

Join me on the next Application Developer Partner call for an in-depth discussion about Visual Studio Mobile Center.

Application Development Partner Community

Exchange Online でのアイテム検索の方法について

$
0
0

こんにちは、Exchange サポート チームの小林です。

今回は Exchange Online にてアイテムを検索する方法についてです。
まず、メールボックスのコンテンツを検索し、エクスポートを行う方法として現時点では下記 3 通りの方法がございます。

(1) Exchange Online (ExO) の機能である Search-Mailbox コマンド
(2) ExO の機能であるインプレース電子情報開示 (eDiscovery)
(3) Office 365 のコンプライアンス センターの機能であるインプレース電子情報開示

それぞれの違いと、新機能である (3) での検索、エクスポートの具体的な手順をご紹介します。
 
(1) Exchange Online (ExO) の機能である Search-Mailbox コマンド
———————————————————————————–
Search-Mailbox コマンドによってメールボックス内のアイテムの検索、エクスポート、さらに削除を行うことが可能です。
メールボックス容量を削除し、他のメールボックスにエクスポートいただく場合などにご利用いただくコマンドとなりますが、検索対象のメールボックス数、および、一度にエクスポート可能なアイテム数に制限がございます。
そのため、検索対象や検索の結果出力されるアイテムの数が多い場合 (10,000 を超えるような場合) には、後述の (3) 機能のご利用をご検討ください。

Title: Search-Mailbox
URL: https://technet.microsoft.com/ja-jp/library/dd298173(v=exchg.160).aspx
 
(2) ExO の機能であるインプレース電子情報開示 (eDiscovery)
———————————————————————————–
複数のメールボックスを対象にアイテムの検索、エクスポート、および、検索条件に合致するアイテムを保持することが可能です。
ただし、当該機能は 2017 年 7 月 1 日以降、新機能であるコンプライアンス センターの検索機能 (後述の (3) 機能に相当する機能となります) への移行に伴い、廃止を予定しております。
そのため、今からご利用をご検討いただく場合には、(3) 機能のご利用をご検討ください。

Title: インプレース電子情報開示 (eDiscovery)
URL: https://technet.microsoft.com/ja-jp/library/dd298021(v=exchg.150).aspx
 
(3) Office 365 のコンプライアンス センターの機能であるインプレース電子情報開示 (eDiscovery)
———————————————————————————–
前述 (2) の新機能となります。従来の eDiscovery では検索対象となるメールボックス数の制限や、検索自体に長時間を要する問題がございました。
新機能ではこれらの問題を改善しており、また、Exchange 内のリソースだけではなく、Sharepoint Online 上のリソースを検索いただく事も可能となっております。

なお、当該機能をご利用いただくためには、前提条件として Office 365 の全体管理者である必要がございます。さらに、Office 365 の全体管理者に対して以下のアクセス許可を追加いただく必要がある点ご留意ください。

 - Sharepoint Online 側にて eDiscovery 用のサイト (https://contoso.sharepoint.com/Sites/eDiscoveryCenter) に対する所有者権限
 - Office 365 コンプライアンス センター (https://protection.office.com) の “eDiscoveryManager グループ” のアクセス権限

手順の詳細は以下の公開情報にてご案内しておりますが、手順が少々複雑なため、Exchange メールボックス内のアイテムを検索し、エクスポートするまでの操作の流れを後述の通りご案内します。

Title: Office 365 セキュリティ/コンプライアンス センターで電子情報開示ケースを管理する
URL: https://support.office.com/ja-jp/article/Manage-eDiscovery-cases-in-the-Office-365-Security-Compliance-Cjater-edea80d6-20a7-40fb-b8c4-5e8c8395f6da?ui=ja-jp&rs=ja-jp&ad=jp

-手順
========
1. Office 365 コンプライアンス センター (https://protection.office.com) に Office 365 管理者のアカウントにてログインします。
2. [アクセス許可] から eDiscoveryManager グループのメンバーとして、電子情報開示機能をご利用いただくユーザーを追加します
*該当ユーザーの検索画面では、表示名にて検索いただく必要がある点にご注意ください。
3. Office 365 コンプライアンス センターの [電子情報開示] を開き [SharePoint の電子情報開示センターに移動] をクリックします。
*アクセス権限を要求される場合には、Sharepoint Online の管理センターを開き、eDiscovery 用のサイトの所有者として実行ユーザーを追加ください。
4. 表示されたページにて、右上の歯車マークの設定より、[サイトの設定] を開きます。
5. [サイト コレクションの管理] 配下の [検索先] をクリックし、[新しい検索先] を押下します。
6. 検索先の追加画面にて、名前として “Exchange Online” と入力し、プロトコルとして [Exchange] を選択します。
7. [Exchange のソース URL] にて “自動検出を使用する” にチェックを入れ、[保存] ボタンを押下します。
*自動検出を使用するの項目が表示されない場合には、画面が更新されていない可能性がございますので、しばらくお待ちください。
8. 設定が反映されるまで数分程度お待ちいただいた後に、Office 365 コンプライアンス センターの [電子情報開示] 機能よりケースを開いてください。(ケースが無い場合は新規作成ください。)
9. 作成したケースをダブルクリックし、[検索] メニューにて、+ [新しいアイテム] を押下します。
10. 入力画面に従って、任意の検索名、検索対象とするリソースを選択します。
*すべてのメールボックスを検索する場合には、”すべてのメールボックスを検索する” を選択の上、SPO のサイトやパブリック フォルダーについては既定 (検索対象として指定しない) のまま、”次へ” を押下します。
11. キーワードを入力する画面にて、SearchQuery にて指定いただいたクエリを入力し、”クエリに入力ミスがあるかどうかを調べる” ボタンを押下します。
12. クエリに問題がない場合には、”検索” ボタンを押下し、検索を開始します。
13. 検索が終了後、結果をエクスポートする場合には、該当の検索をクリックの上、エクスポート ボタン (下矢印の付いたボタンとなります) をクリックし、”結果をエスくポート” を選択します。
14. 出力対象のアイテム、および、エクスポートの形式を指定し、”エクスポートを開始” をクリックします。
15. エクスポートの結果に関しましては、ケースの詳細画面上の “エクスポート” メニューよりご確認いただく事が可能です。
16. エクスポートのが完了次第、該当のエクスポートをクリックし、右側の画面より “エクスポートした結果をダウンロード” をクリックし、画面上の指示に従って結果 (PST ファイルまたはメッセージ ファイル) をダウンロードください。

– 参考情報
Title: Office 365 セキュリティ/コンプライアンス センター
URL: https://support.office.com/ja-JP/article/Office-365-Security-Compliance-Cjater-7e696a40-b86b-4a20-afcc-559218b7b1b8?ui=ja-JP&rs=ja-JP&ad=JP

Title: Office 365 セキュリティ/コンプライアンス センターでの検索と調査
URL: https://support.office.com/en-JP/article/Search-and-investigation-in-the-Office-365-Security-Compliance-Center-c4915c5f-82a7-4871-ba20-ef47c7588043?ui=en-JP&rs=en-JP&ad=JP

以上です。今後も当ブログおよびサポート チームをよろしくお願いいたします。

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

マイクロソフト パートナーにインスピレーションをもたらす Microsoft Inspire【2/2 更新】

$
0
0

(この記事は 2017 年 1 月 13  日にMicrosoft Partner Network blog に掲載された記事 What Inspires Microsoft Partners? の翻訳です。最新情報についてはリンク元のページをご参照ください。)

dean-martin-author-block_1

 

年間最大のパートナー様向けイベント「Microsoft Inspire (英語)」の開催に向け、このカンファレンスに参加する意義についてトップ パートナーの皆様に伺いました。Microsoft Inspire は、パートナーの皆様にとって 1 年で最も重要な交流の場となっているため、マイクロソフトにとっても大きな意味を持っています。パートナーの皆様が Microsoft Inspire をいかに大切なイベントとして受け止めているか、お寄せいただいたコメントをいくつかご紹介したいと思います。

 

Microsoft Inspire でインスピレーションをもたらすものとは

「Inspire」という名前自体が、このイベントの本質を表しています。マイクロソフトの主要なパートナー イベントでパートナー様にインスピレーションを与えるものとは何かを考えてみると、真っ先に思い浮かぶのは、満場の聴衆を集めた著名人による基調講演やセッションではないでしょうか。しかしそのほかにも、パートナー様の興味を掻き立て、新しいアイデアを自社ビジネスに積極的に取り入れたいと思わせるような、さまざまな体験が待っています。

Microsoft Inspire では、パートナー様を大々的にお招きして、面識を深めたり意見交換したりするなど、今後 1 年のビジネス形成に寄与する貴重な関係構築の場を提供しています。さらに、ビジネス チャンスやイノベーションを促進するための場として、また、私たちの世界を変える最新テクノロジを発信するための場としても機能しています。

 

「ビジネスにおけるクラウドの重要性が大きく変化する中で、マイクロソフトが、現在そして将来にわたってどのようなストーリーを描いているのか見定めることができます。さらに、さまざまな発想を持つ人たちや一流の人たちとお会いして、ベスト プラクティスを共有したり、新たな知識を学んだりすることができます」

– New Signature、創業者、Dan Scarfe

過去のイベントがビジネスにもたらした影響とは

AvePoint の CTO である Dux Raymond Sy 氏は、Microsoft Inspire で経験した他のパートナーとの交流がビジネスの形成を後押ししてくれたと言います。「当社は 3、4 年前にクラウドの導入に着手しましたが、当時新しいサブスクリプション モデルをいち早く採用したという、とあるパートナー企業からお話を伺う機会があったのです。彼らのすばやい決断に感銘を受けると共に、クラウドを効果的に活用していると聞いてすぐに社に持ち帰り、今では私たちもクラウドを大いに活用しています。こうした参考になるお話が聞けるのは、とても助かります。確かなロール モデルがあれば、今後数年間で自社のビジネスをどう成長させていけばいいかを思い描くことができるからです。」

 

「過去のイベントでは、他社がどんなふうに拡張して、どんなふうに成長したのか、実際の事例を知ることができて大いに役立ちました。そこで得た知見を取り入れて、当社も成長できるのです」

– AvePointCTODux Raymond Sy

 

過去のイベントで特に有意義だったフォーラムやセッションとは

基調講演は通常、参加者の発想や意欲を掻き立てることを意識して組み立てられます。過去の Microsoft Inspire を振り返ると、特筆すべきセッション (英語) がいくつか思い浮かびます。Sy 氏にとって強く印象に残っているのが、2011 年に Sir Richard Branson 氏が行った基調講演です。世の中に還元するという Branson 氏のメッセージがきっかけとなり、Avepoint はここ数年にわたって慈善活動に取り組んでいます。Mercer-MacKay Solutions の Gail Mercer-MacKay 氏は、初めて参加した Women in Technology (WIT) セッションのパネリストたちに触発されて起業するに至ったと話します。

 

「Microsoft Inspire は、真のビジネス ナレッジ イベントです。リーダーとしてのスキルやコミュニケーション戦略など、さまざまなことを学べる絶好の機会と言えるでしょう。世界各国からトップ リーダーや専門家やトレーナーが集結するので、3 日間でちょっとした MBD が学べるのです」

– Mercer MacKay Solutions Inc.、社長、Gail Mercer-MacKay

 

Microsoft Inspire では、基調講演やパートナー セッションのほかにも、パートナー様が交流を深めることのできるさまざまな機会が設けられています。各フォーラムでは、参加者の興味を引くユニークな内容を取り上げて、参加者同士が意見を交わし、関係を深められるようにしています。Sy 氏は以下の 3 つがこれまでにとても役に立ったと言います。

  • パートナー様またはお客様主導の実用的なセッション
  • Community Hub をはじめとする公式ではない集まり
  • 参加者どうしのくだけた交流会やアフター パーティ

 

Sy 氏にとって、Microsoft Inspire の面白さは、将来につながる結び付きが生まれることにあるのだそうです。事実、過去のイベントでたまたま知り合った相手が、今では主要な提携先の 1 つとなっており、さらには友達付き合いにまで発展したと言います。

 

パートナー様が Microsoft Inspire 2017 に期待することとは

 

「Microsoft Inspire では、貴重な情報が共有されます。カンファレンスで発信される明確なビジョンを通じて、パートナーの皆様はインスピレーションやモチベーションが得られるだろうと確信しています。ただし、それよりもさらに重要なのが、ここで培われるつながりです。知り合いになれたら、既に勝負はあったも同然ですから」

– QTSVP COOChristine Bongard

 

Microsoft Inspire に参加されたことのないパートナー様が今年のカンファレンスに参加されれば、業界に関する知見やさまざまな刺激を得られ、ビジネスへの取り組み方も変わるのではないでしょうか。Dan Scarfe 氏によれば、初回参加の企業であれ、何度も参加している企業であれ、新たなビジネス チャンスにつながる重要な手掛かりを見逃さないようにすることが肝心だと言います。「クラウド テクノロジの分野ではさまざまな新しい動きが起こっているので、新たに参入できそうな分野を重点的に検証する絶好の機会となります」 初めて参加される企業の皆様には、パートナーの皆様からのアドバイスを、以下にいくつかご紹介します。

  • 時間単位で当日の予定を立てる:「会場では時間に限りがありますし、話せる人数も限られます。数週間前から予定を立て始めて、話したい相手には招待の通知を送ります。時間単位で計画するほうがよいでしょう。いざ会場に着いたら、その場の雰囲気に舞い上がってしまうということもありますから」(Scarfe 氏)
  • 目的を明確にする:「Microsoft Inspire に参加する目的について、販売チャネルの拡大かマイクロソフトとの関係強化か、あるいは単なる情報収集なのか、リーダーを交えて話し合っておきましょう。そして、その目的を達成するにはどうするべきかを考えてください」(Sy 氏)
  • 新しいパートナーシップの構築を図る: Bongard 氏によれば「理想的なパートナーを見つけて接触するには、Connect ミーティングの活用」が不可欠だと言います。「所在地域が異なるパートナーに接触して、システム センターのスキル向上に自社がどのように役立つかを説明したり、逆に、差別化を図るには何が必要かをたずねることもできます。」Connect ツールは、2017 年夏から利用可能となりますが、 なら、今すぐパートナーとつながることができます。
  • 新しいアイデアを柔軟に受け入れる:「かたくなな思い込みは禁物です。目標を達成するに越したことはありませんが、これまで思いもよらなかったアイデアに耳を傾けてみることも大切です。私自身、WIT セッションに参加したときは、新しいアイデアや考え方を積極的に取り入れたいと考えていました。その経験があったからこそ、今の自分があるのだと思っています」(Mercer-MacKay 氏)

 

 

日本のパートナー様へは、以下のサイトにてMicrosoft Inspire の情報共有を行っております。

ご興味のある方はぜひ、チェックしてみてください。

 

shosai

 

 

The Iceberg Effect

$
0
0

In cybersecurity, especially in the Digital Forensics Incident Response (DFIR) space, the “Iceberg Effect” plays a detrimental role in the execution phase of response and recovery. This often leaves analysis incomplete which directly translates to insufficient response and recovery plans—and worse, a very high probably of failed attempts to evict the actor in the environment.

But what exactly is “the Iceberg Effect” and what can we do about it?

As cyber warriors with various tools deployed and implemented, there are tons of data at our fingertips. Most of the time too much data, since most of the bosses want to “log everything” and auditors often simply ask “do you log [x]”. To get the checkbox checked the response is either a “yes” or “no but we will start logging it!”. Now, whether anyone ever looks at that data, triggers on it to build or start specific workflows or automation, analyzes it or even knows it exists once the audit is passed becomes a secondary if not tertiary question. In the rare cases when we do have data that is actionable and where insights can be drawn from, well, this becomes “the tip of the iceberg“. This is typically where analysis stops! For example, for those who are highly trained and developed a culture of network defense, we start and stop with network defense tools—sure, they might analyze an endpoint but that typically means do some quick forensics of the box then turn it into ashes. Our network tools point to a device where known malicious or anomalous activity came from, and we conduct additional analysis only on that box.

Now back to the Iceberg and how the heck that relates…

As many of us know an Iceberg is roughly 10% above the water and 90% under the water. As cyber defenders, when we do see an iceberg (our trigger and when we spring into action), we see the 10% but fail to see exactly what is under the water; we are unable to see the other 90% which could provide additional context, sometimes very important context such as root-cause or other indicators that we could pivot on to see potentially what other assets of ours are compromised.

This isn’t our fault. Our tools are disparate from each other, they aren’t integrated. SIEMS try to fill this void by allowing workflows through the collection and analysis of small sets of data in which they collect but they don’t make up for the absence of the right sensors of data. Most if not all the tools in the environment are geared towards keeping the bad guy out but not detecting the bad guy who is already in our network!

Understanding the steps that take place after an adversary establishes a foothold in the environment is important to learn how to create a strong detect strategy. At the highest level here is the problem space to include the post-exploit phase
of the actors actions:

Again, unfortunately our sensors are geared towards the protect phase which is to purely prevent the initial beachhead. The common belief is that network sensors and even host sensors provide a level of defense in depth—unfortunately these sensors detect the same things but at different places in the environment. Repetitive sensing at various stages is certainly not a bad strategy—however, it still is insufficient. A true detect strategy must give us visibility of adversarial activities across their campaign, to include when they successfully infiltrate. Tools like Advanced Threat Analytics (http://aka.ms/ata) help turn Active Directory and the Identity plane into one of the best detections of this post-exploit activity. To build the broader picture, backwards, taking this data and fusing it with tools like Operational Management Suite (http://oms.microsoft.com) and Windows Defender Advanced Threat Protection (http://aka.ms/wdatp) help tell the full story. The full story gives the computer/network defender (CND) the most information allowing them to discover the most indicators of compromise (IOC) to fully see the persistence of the actor in their environment. Depending on purely MD5 hashes and filenames should no longer be considered a strategy.

So how does this happen? Unfortunately, many environments have cultures around specific tools. They are trained to operate a very specific way looking at a very specific data set. This is the iceberg effect. It is rare to find a team which can take data from multiple sources, fuse that together at the right pivot points, and build insights from that data. Teams must discover what is under the water to build the full picture. It is important to know why the device in which the network sensor said malicious packets came from might not be the only device impacted by an actor’s campaign on the environment!

This blog will dive into specifics introduced in this blog—from methods of persistence that transcend malicious software to understanding the phases of activity of an actor, specifically after the initial foothold has been established in the environment.

ExpressRoute のデプロイ モデル変更に関するアナウンス

$
0
0

こんにちは、Azure サポートチームの飯塚です。

本日アナウンスがありました、ExpressRoute のデプロイ モデルの変更についてご案内いたします。

ExpressRoute のデプロイ モデルについて

ExpressRoute に限ったものではありませんが、現在、Azure には以下の 2 種類のデプロイ モデルがあります。
リソースの種類によって例外もありますが、ExpressRoute 回線については、2017 年 2 月 2 日時点で、どちらのモデルでも作成が可能です。

  • クラシック デプロイ モデル (旧来のモデル)
  • リソース マネージャー デプロイ モデル (新しいモデル)

それぞれのデプロイ モデルの概要は、以下の公開資料を参考にご覧いただければと思います。
https://docs.microsoft.com/ja-jp/azure/resource-manager-deployment-model

今回のアナウンスの内容

今回のデプロイ モデルの変更のアナウンスは、「2017 年 3 月 1 日以降は、クラシック デプロイ モデルでは ExpressRoute 回線の新規作成が行えなくなる」というものです。つまり、2017 年 3 月 1 日以降は、ExpressRoute 回線を作成する際は、リソース マネージャー モデルの手順をご実施いただく必要がございます。

以下の公開資料は、クラシック デプロイ モデルとリソース マネージャー デプロイ モデルそれぞれにおける、ExpressRoute 回線の作成手順をご案内しているものです。2017 年 3 月 1 日以降は、リソース マネージャー デプロイ モデルの手順しかご利用いただけなくなります。

クラシック デプロイ モデルの手順 >>> 3 月以降ご利用いただけない手順
https://docs.microsoft.com/ja-jp/azure/expressroute/expressroute-howto-circuit-classic

リソース マネージャー デプロイ モデルの手順 (PowerShell) >>> 引き続きご利用いただける手順
https://docs.microsoft.com/ja-jp/azure/expressroute/expressroute-howto-circuit-arm

リソース マネージャー デプロイ モデルの手順 (ポータル画面) >>> 引き続きご利用いただける手順
https://docs.microsoft.com/ja-jp/azure/expressroute/expressroute-howto-circuit-portal-resource-manager

今回の変更における影響

今回の変更は、あくまで、ExpressRoute 回線を作成する際の手順に関するものです。たとえば既存の ExpressRoute 回線が 3 月以降に停止するような予定はございませので、ご安心いただければと思います。

ただし将来的には、リソース マネージャー デプロイ モデルの回線でのみ利用できる新機能などが実装される可能性がございます。このため、現在クラシック デプロイ モデルで作成されている ExpressRoute 回線については、リソース マネージャー デプロイ モデルへの移行を推奨いたします。

既存のクラシック デプロイ モデルの回線をリソース マネージャー デプロイ モデルに変更する手順は、以下の資料でご説明差し上げております。回線の移行作業にあたっては特に通信断は発生せず、また既存で接続されているクラシック デプロイ モデルの仮想ネットワークも、そのまま維持されます。
https://docs.microsoft.com/ja-jp/azure/expressroute/expressroute-howto-move-arm

本件に関する FAQ

Q1. 既存の ExpressRoute 回線が突然停止しますか?
A1. 既存の ExpressRoute 回線が停止する予定はなく、サポートも継続されます。
ただし、上記のとおり、リソース マネージャー デプロイ モデルへの移行を推奨いたします。
Q2. クラシックの仮想ネットワークは、もう接続できないのでしょうか?
A2. いいえ、リソース マネージャー デプロイ モデルで作成した ExpressRoute 回線にも、クラシックの仮想ネットワークを接続することができます。この場合、以下のいずれかの手順で、リソース マネージャー デプロイ モデルで作成した ExpressRoute 回線に対して、クラシック デプロイ モデルのアクセスを許可してください。
  1. 以下の資料における「両方のデプロイ モデルに対して ExpressRoute 回線を有効にする」項における PowerShell のコマンドを実行する
    https://docs.microsoft.com/ja-jp/azure/expressroute/expressroute-howto-move-arm
  2. ポータル画面 (https://portal.azure.com/) における [ExpressRoute Circuits] で、対象の回線の [Configuration] から [Allow classic operations] を [Enabled] に変更する
    allowclassicvnet
Q3. 既存の ExpressRoute 回線がどちらのデプロイ モデルか、どこで確認すればいいですか?
A3. 確認方法の一例ですが、ポータル画面 (https://portal.azure.com/) の [ExpressRoute Circuits] に回線が表示されていれば、リソース マネージャー デプロイ モデルです。そうでない場合は、クラシック デプロイ モデルです。

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


PSScriptAnalyzer deep dive – Part 3 of 4

$
0
0

Summary: Thomas Rayner, Microsoft Cloud and Datacenter Management MVP, shows how to use Pester to get nUnit formatted results out of PSScriptAnalyzer.

Hello! I’m Thomas Rayner, a Cloud and Datacenter Management Microsoft MVP, filling in for The Scripting Guy this week. You can find me on Twitter (@MrThomasRayner), or posting on my blog, workingsysadmin.com. This week, I’m presenting a four-part series about how to use PSScriptAnalyzer.

Part 1 – Getting started with PSScriptAnalyzer

Part 2 – Suppressing, including, excluding rules

Part 3 – Wrapping PSScriptAnalyzer with Pester to get formatted results

Part 4 – Writing custom rules

This is Part 3, and I’m going to show you how to get nUnit formatted results from PSScriptAnalyzer.

nUnit is an XML based open source test result format. nUnit is a testing format that’s used in popular Continuous Integration and Continuous Deployment services like AppVeyor and Visual Studio Team Services. There are ways to get differently formatted and recorded output from PSScriptAnalyzer. By default, most people I’ve worked with have found it easiest to use Pester to format their test results.

Pester is a domain-specific language that was developed to test PowerShell code. There are a ton of great resources to learn Pester. If what you see in this post is very unfamiliar, I’d recommend finding a book, online training course, blog, or other resource to get started. The Pester GitHub page is a great place to start.

Note: Procedures in this post are for Pester version 3.4.6 and haven’t been tested on 4.x yet.

If you don’t already have Pester installed, you can get it from the PowerShell Gallery and import the module.

Install-Module -Name Pester -Scope CurrentUser

Import-Module -Name Pester

Now you’re ready to do some Pester testing.

First, let’s define the script, named MyScript.ps1, that we want to evaluate.

param (

$Path,
$DaysOld

)
$someVar = $null
Write-Host "Counting items..."
$itemCount = (gci $Path | ? { $_.LastWriteTime -gt (Get-Date).AddDays(-$DaysOld)}).Count
Write-Host "There are $itemCount items"

There are some clear problems with this already, but, if it were perfect, it wouldn’t generate interesting PSSA output.

Now, I’m going to write a Pester test. I’ll start by declaring a Describe and Context block.

Describe 'Testing against PSSA rules' {

Context 'PSSA Standard Rules' {

}

}

Now, something should probably go inside, right? I’m going to run PSSA against my script, store the variables in $analysis, and get a list of rules stored in $scriptAnalyzerRules. (I could also specify a location to custom rules here if I had any.)

$analysis = Invoke-ScriptAnalyzer -Path '.MyScript.ps1'

$scriptAnalyzerRules = Get-ScriptAnalyzerRule

Why did I do this? What I’m going to do next is use a foreach loop to build all my It statements, and test for all the rules we’re evaluating.

forEach ($rule in $scriptAnalyzerRules) {

It "Should pass $rule" {

If ($analysis.RuleName -contains $rule) {

$analysis |

Where RuleName -EQ $rule -outvariable failures |
Out-Default

$failures.Count | Should Be 0

}

}

}

Here, I’m looping through all the rules that PSSA checked and declaring that my script should pass that rule. Any PSSA rule violations are stored in $analysis. So, if $analysis.RuleName has an entry in it that matches a rule, I know that this assertion failed.

Here’s what my full test file, MyTest.tests.ps1, looks like.

Describe 'Testing against PSSA rules' {

Context 'PSSA Standard Rules' {

$analysis = Invoke-ScriptAnalyzer -Path  '.MyScript.ps1'

$scriptAnalyzerRules = Get-ScriptAnalyzerRule

forEach ($rule in $scriptAnalyzerRules) {

It "Should pass $rule" {

If ($analysis.RuleName -contains $rule) {

$analysis |

Where RuleName -EQ $rule -outvariable failures |
Out-Default

$failures.Count | Should Be 0

}

}

}

}

}

Now, I just need to run one line to get my nUnit formatted test results.

Invoke-Pester -OutputFile 'PSSAResults.xml' -OutputFormat 'LegacyNUnitXml' -Script '.MyTest.tests.ps1'

Done! Presumably, if you’re doing this, it’s to interface with some Continuous Integration/Deployment service like AppVeyor or Visual Studio Team Services. You will have a couple steps left to integrate this solution seamlessly into your Continuous Integration/Deployment suite of choice to properly collect and act on the test results. This is the funky part – getting nUnit formatted results from PSSA.

There are other ways to get the same result, but this is a pretty easy, scalable solution that I happen to like. If it doesn’t work for you for some reason, I’d love to hear about your alternative!

Now, if you’ve integrated this into Visual Studio Team Services, for example, you’ll get some cool screens like these:

Looking at the test results in Visual Studio Team Services.

Build results that include Pester results

Reviewing detailed results for the PSSA results to see which rules were violated.

Pass / fail results

I have a much longer post on my blog that explains how to set this up Visual Studio Team Services. If that interests you, feel free to check out Invoking Pester and PSScriptAnalyzer Tests in Hosted VSTS.

Come back tomorrow, and I’m going to show you how to write your own customized PSScriptAnalyzer rules.

Thomas, thanks for that update!  Using Pester as an addition tool is certainly an excellent way to QA my tools before going into production!

I invite you to follow the Scripting Guys on Twitter and Facebook. If you have any questions, send email to them at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow.

Until then, always remember that with Great PowerShell comes Great Responsibility.

Sean Kearney
Honorary Scripting Guy
Cloud and Datacenter Management MVP

Adoptez une stratégie digitale

$
0
0

Transformer votre métier, ou adopter une stratégie digitale. Ce fut le thème du workshop animé autour de Microsoft® Dynamics 365® au palais des congrès de Tunis.

La première question à laquelle il faudrait avoir une réponse est pourquoi se transformer, en effet le client d’aujourd’hui est déjà transformé, nous parlons d’un âge de client digital, ce dernier est sur Facebook sur twitter et d’autres canaux, autrement dit les organisations doivent se doter d’outils nécessaires afin d’aller vers cette cible avec les offres et les moyens adéquats.

Se transformer se décline en quartes point essentiels –

Engager le client, c’est le mettre au centre de la stratégie de la transformation, comment ? La compréhension client n’est plus un luxe, connaissance des préférences des cycles d’achats de ce dernier est un must auquel une organisation doit répondre.

Une vue 360° qui récapitule les volontés, la satisfaction et les demandes client permet un engagement ciblé avec ce dernier et crée une relation client connecté à l’opposé d’une relation client réactive.

Accélérer le marché, devenir innovateur, se doter d’une agilité avoir un schéma directeur orienté client est aujourd’hui la priorité des rôles stratégiques telle que le directeur ou responsable marketing, le directeur des ventes, l’analyste métier, etc. … Cela permet d’optimiser les opérations organisationnelles telle que le processus de ventes, l’approvisionnement, la trésorerie, le gain de temps interne impacte directement la stratégie go-to-market, la digitalisation de l’entreprise de demain en dépend intimement.

Transformer vos produits, la majeure partie des produits connus en début des années 2000 sont aujourd’hui obsolète, le spot publicitaire télé et radio est devenu obsolète, aujourd’hui la présence d’une stratégie de « Advertising » sur Facebook est un must autrement dit le produit que vous vendez change vers une marque digitale qui trouve sa présence sur le Web

Démarquez vos employés, permettre au collaborateur d’accéder à l’information et de se doter d’outils fluides quand il engage avec ses clients est obligatoire aujourd’hui, mobilité, disponibilité et adaptabilité sont les termes clés que cherchent ces derniers aujourd’hui.

blog-entry1

クラウドベースのメール ソリューションで時間を節約する 5 つの方法

$
0
0

(この記事は 2016 12 20 日に Office Blogs に投稿された記事 5 ways a cloud-based email solution saves you time の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

5-ways-a-cloud-based-email-solution-saves-you-time-1

ビジネスのコミュニケーション手段として最もよく使われているのはメールです。これは今後も変わらないでしょう。主要なコミュニケーション手段であるメールをうまく利用して、ビジネスの成功につなげていく必要があります。そこで今回は、IT 部門とユーザー向けに、クラウドベースのメールを活用して時間を節約できる方法をご紹介します。

その 1. ハードウェアの数、ソリューションのメンテナンス頻度を抑える

メールをクラウドに移行すると、オンサイト サーバーを管理する手間が省けます。さらに、クラウドではソフトウェアが自動的に更新されるため、メンテナンスによるダウンタイムが大幅に削減される、またはダウンタイムそのものがなくなります。オンプレミスでハードウェアを維持する必要がないので、IT チームはより多くの時間を他のプロジェクトに充てられるようになります。

その 2. ダウンタイムのコストを削減

メール システムがダウンすると、あらゆる面でコストがかかります。オンサイトのメール ソリューションは、更新、拡張、その他の作業によりダウンタイムの発生する可能性が高くなります。Ponemon Institute の調査によると、予期しないダウンタイムによるコストは 2016 年だけで 25 億ドルにも達しており、2010 年と比較して 2 倍以上になっています。Ponemon Institute によれば、ダウンタイム発生時の最大のコスト要因は、業務の中断、収益の低下、従業員の生産性の低下です。

メールの価値を高める

クラウドベースのメールを採用している企業は、自動化および標準化システムによって大きな利益を上げています。また、IT 部門ではダウンタイム発生の抑制と最新のセキュリティ機能の導入に力を入れています。なぜメールをクラウドに移行する必要があるのか、こちらの電子ブックでご確認ください。

その 3. シームレスな統合で効率アップ

処理速度の遅いサーバーや複雑な統合プロセスは悩みの種です。統合メール ソリューションなら、社員の時間と労力を費やす必要はありません。クラウドベースのメールは、アプリケーションの配信がスピーディで、ビジネス プロセスの効率化に大きなメリットがあります。

その 4. 拡張と更新が容易

拡張と更新が容易なクラウド メール ソリューションなら、IT チームが抱える多くの問題を解消できます。クラウドベースのメールに移行すれば、標準化と自動化機能のメリットを活用できます。

その 5. セキュリティ、コンプライアンスの強化

多くの業界や企業にとって、信頼性を確保し厳しい規制要件を満たすために欠かせないのが、セキュリティとコンプライアンスです。しかし、高いセキュリティ基準を維持し、コンプライアンス要件に準拠するには多大な時間がかかるため、自社で管理するのは生産的ではありません。効果の高いクラウドベースの安全なメール ソリューションを導入すれば、グローバルな要件や地域固有の要件だけでなく、医療保険の相互運用性と責任に関する法律 (HIPAA)、連邦情報セキュリティ マネジメント法 (FISMA)、家庭教育の権利とプライバシーに関する法律 (FERPA)、金融機関の規制などの業界に特化した要件への準拠も簡単になります。変化するプライバシーに関するコンプライアンス標準と共に、アプリケーションは常に最新の状態に保たれます。

これらすべてが生産性の向上につながり、企業の時間とコストを削減する大きなメリットとなります。

関連情報

関連コンテンツ

why-are-you-still-waiting-to-upgrade-your-email-to-the-cloud-fi
メール ソリューションをクラウドに移行した方がよい理由
help-prevent-user-error-security-breaches-fi
ユーザーの過失による
セキュリティ侵害を防止
email-hack-fi-v2
メール ハッキングの
ライフサイクル
how-to-avoid-mobile-app-security-scares-1
モバイル アプリの
セキュリティ脅威を
回避する方法
※ 本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

Exchange 2016 ユーザー向けに Microsoft Graph プレビューを発表

$
0
0

(この記事は 2016 12 20 日に Exchange Team Blog に投稿された記事 Microsoft Graph Preview for Exchange 2016 customers の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

マイクロソフトは現在、Exchange 2016 のお客様やパートナーと連携して、Microsoft Graph を使用した Exchange ハイブリッド シナリオの評価を計画しています。このプロジェクトのミッションは、スコープを定義し、プロダクト チームの技術的な支援を得ながら、Graph API の問題を解決することです。開発者は自身のペースで進めることができます。このプロジェクトに参加するには、まず Exchange TAP プログラムに参加する必要があります。以下にプログラムについてよく寄せられる質問をご紹介します。

技術的な要件を教えてください。
Exchange ハイブリッド ソリューションを開発および評価するには、Exchange 2016 CU3 以上と、Azure AD と同期したオンプレミスの Active Directory が必要です。ハイブリッド展開の詳細については、こちらを参照してください。

開発者は何名必要ですか。
スコープの定義と Microsoft Graph ソリューションの開発に 1 ~ 2 名を想定しています。

既存の Exchange Web サービス ソリューションが必要ですか。
必須ではありません。Exchange 2016 のハイブリッド開発をサポートし、Microsoft Graph の機能を評価する意欲をお持ちであることを重視しています。

プロジェクトの期間について教えてください。
2017 年 1 月に開始し、2017 年夏前に終了する予定です。

レドモンドまで行く必要がありますか。
いいえ。この技術は既にプレビュー段階に入っており、開発用ノート PC からインターネットでアクセスいただけます。

このプロジェクトの実施理由を教えてください。
お客様やパートナー様と直接かかわることで、Microsoft Graph を改善し、お客様の幅広いニーズに正確に対応できると考えています。プロジェクトを通して得られた知見は、製品ロードマップに随時反映していきます。

このプログラムへの参加を希望する場合は、exchangehybridgraph@service.microsoft.com まで以下の情報と質問の回答をお送りください。

  1. プロジェクトの代表者情報。
    • 会社
    • 氏名
    • 役職
    • 職場の電子メール
    • 職場の電話番号
  2. Exchange TAP に登録済みですか。
  3. どのようなハイブリッド シナリオを想定していますか。
  4. どのような技術で解決することを考えていますか。
  5. これまでに Exchange Web サービスを使用して上記のハイブリッド シナリオの解決を試みたことがありますか。結果はどうでしたか。
  6. プログラムを通じて Microsoft Graph を利用したことがありますか。これまでに開発したプロジェクトがあれば教えてください。
  7. このプロジェクトを担当する開発チームについて教えてください。

次回もどうぞお楽しみに。

Microsoft Outlook チーム

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

SharePoint と OneDrive for Business でネットワークの場所に基づく条件付きアクセス ポリシーを適用

$
0
0

(この記事は 2017 1 13 日に SharePoint Blog に投稿された記事 Introducing Conditional Access by Network Location for SharePoint and OneDrive for Business の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

2016 年 9 月に Ignite で告知したとおり、SharePoint および OneDrive for Business は、2017 年 1 月 20 日の初回リリースより、ネットワークの場所に基づく条件付きアクセス ポリシーを適用いたします。

CloudSecurity.png

このポリシーは、データの漏えい防止、規制要件への適合、信頼できないネットワークからのアクセス遮断などに効果的です。IT 管理者は、SharePoint 管理コンソールから、特定のネットワーク範囲のアクセスを制限することができます。構成後、定義されたネットワーク境界の外から SharePoint や OneDrive for Business への (Web ブラウザー、デスクトップ アプリ、任意のデバイス上のモバイル アプリなどを使用した) アクセスをブロックします。

このポリシーは、初回リリースの商用および GCC テナントに追加ライセンスなしで提供されます。

管理エクスペリエンス

管理者は、ネットワーク範囲に現在のマシンの IP アドレスを含める必要があります。IP アドレス範囲は厳格に遵守されるため、管理者のマシンの IP が含まれていないと管理セッションがロックアウトされます。管理セッションがロックアウトされた場合は、サポート担当に接続の再確立を依頼してください。

このポリシーは既定では無効です。ポリシーが構成されていない場合、SharePoint によるアクセス制限は一切行われません。このポリシーの構成はあくまでオプションとなります。

管理者が Azure Active Directory Premium (AADP) で IP ネットワーク範囲を指定してロケーションによるアクセス制限を実施している場合、AADP のホワイトリストが SharePoint ポリシーより先に評価されます。このため、AADP よりも限定したポリシーの適用が可能です。ただし、AADP で禁止されている IP アドレス範囲のアクセスを有効にすることはできません。
LocationPolicy.jpg

SharePoint Online 管理コンソールの管理エクスペリエンス

最終的に、SharePoint ポリシーは、OneDrive for Business を含む Office 365 テナント内のすべての SharePoint サービスに適用されます。

ユーザー エクスペリエンス

ホワイトリストのアドレス範囲に含まれるユーザーのアクセスは、すべて正常なアクセスとして処理されます。しかし、ホワイトリストの範囲に含まれないユーザーが SharePoint や OneDrive のワークロードにアクセスしようとすると、アクセスはブロックされます。
LocationBlocked.jpg

禁止されているロケーションから SharePoint にアクセスしようとした場合のユーザー エクスペリエンス

ロケーション ベースの条件付きアクセス制限を実施すると、OneDrive クライアントからのオフラインのファイル同期もブロックされます。一般に、テナントに含まれている機密情報に既知のネットワーク以外からアクセスすることを禁止したい場合、同期を完全に無効にすることをお勧めします。こうすることで、リモート デバイス上のコンテンツは、既知のネットワーク ロケーション内に保持されます。このポリシーは、SharePoint と OneDrive へのライブ アクセスをブロックすることはできますが、ホワイトリスト以外のネットワークからダウンロードされたコンテンツや同期されたオフライン コンテンツを自動で検出することはできません。

新しい条件付きアクセス ポリシーの提供を喜ばしく思います。今後、さらなるロールアウトに向けて取り組んでまいりますので、どうぞご期待ください。

よく寄せられる質問 (FAQ)
Q. このポリシーは、Exchange など他の Office 365 サービスへのアクセスに影響がありますか。
A. SharePoint 以外の Office 365 のサービスへの直接の影響はありません。ただし、SharePoint チーム サイトでファイル ストレージを提供する Microsoft Teams や Planner のような共同作業アプリでは、ホワイトリストにないロケーションからアクセスすると予期しない結果になることがあります。

Q. ロケーションによる条件付きアクセス ポリシーは政府機関のテナントで使用できますか。

A. はい、これらのポリシーは政府機関コミュニティ クラウド (GCC) でも使用できます。このポリシーは、2017 年後半には他のエリアのクラウドでもリリースされる見込みです。

Q. Azure Active Directory Premium または Office 365 E5 の使用を有効化したい場合、このポリシーに追加ライセンスは必要ですか。

A. いいえ、そのようなサービスや追加ライセンスは不要です。Azure Active Directory Premium を使用していない場合、SharePoint ポリシーはネットワーク ロケーションに応じてアクセスを許可または拒否します。

Q. このポリシーは SharePoint Server のオンプレミス インストールのアクセスに影響がありますか。

A. いいえ、SharePoint Server に影響はありません。オンプレミスの SharePoint Server をアクセス ポリシーの範囲に含める計画は、現時点でありません。

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

証明書利用者信頼のセキュア ハッシュ アルゴリズムについて

$
0
0

こんにちは、Windows プラットフォーム サポート担当の竹村です。

今回は、AD FS の証明書利用者信頼のプロパティで設定する、セキュア ハッシュ アルゴリズム についてご案内いたします。
ここで設定する セキュア ハッシュ アルゴリズム は、AD FS が、発行したトークンに署名を行う時のハッシュ アルゴリズムです。

以下、簡単に動作をご説明します。

認証要求が AD FS にリダイレクトされた後、認証に成功すると、AD FS は 証明書利用者信頼 (AD FS と連携しているサービス、アプリケーションを指します。例えば Office 365 などが該当します。) にアクセスするためのトークンを発行します。
この時、AD FS は、トークンに署名を行います。
クライアントは、証明書利用者信頼にアクセスする際にこのトークンを提示し、証明書利用者信頼は受け取ったトークンの署名を検証します。
つまり、間違いなくフェデレーション信頼を結んでいる AD FS がトークンを発行したこと、および改ざんが無いことを確認するために、デジタル署名のしくみを利用しています。
AD FS のプロパティで設定するセキュア ハッシュ アルゴリズムは、この署名を行う  (メッセージダイジェストを作成する) 時のハッシュ アルゴリズムになります。

Office 365 をご利用の環境で、このハッシュ アルゴリズムが SHA-1 の場合に、ポータルの管理センターで以下のメッセージを着信することがあります。

MC92255 Secure your federation with SHA-256
——————————————-
How does this affect me?:
You are receiving this message because our reporting indicates your organization is using the less secure SHA-1 token signing.

By utilizing the SHA-256 algorithm, your organization will be able to take advantage of a more secure Azure AD authentication.
What do I need to do to prepare for this change?: Set your token signing algorithm as SHA-256. Follow the instructions given in the Additional Information link below to move to the more secure SHA-256 algorithm for your federation trust.
We recommend that you act immediately.
——————————————-

これは、上述の署名を検証する Office 365 (Azure AD) が、ハッシュアルゴリズムが SHA-1 であることを検知して、よりセキュアな SHA-256 に変更することをアナウンスしているものです。
Office 365 は、以下のとおり SHA-256 を推奨しておりますので、変更をご検討ください。

Change signature hash algorithm for Office 365 replying party trust

※ 2017年 7月 より、Office 365 は SHA-1 に非対応となる可能性があります。
現在 SHA-1 に設定されている環境では、早めに SHA-256 への変更をお願いします。

以下に、よくお問合せをいただく内容を Q/A 形式でお纏めします。

====
Q1.
====
以下のような、一般的に推進されている SHA-1 証明書の制限措置と関係ありますか。

SHA-1 ウェブサーバー証明書は 2017 年2月から警告!ウェブサイト管理者は影響の最終確認を

====
A1.
====
直接の関連はありません。
上記は、証明書に含まれる署名ハッシュアルゴリズムに関するものです。
今回ご案内いたしました、AD FS がトークンに付与する署名のハッシュアルゴリズムとは別のものになります。
このトークンの署名ハッシュアルゴリズムが SHA-1 であることにより、ブラウザアクセス時に警告が表示されるようなこともありません。

====
Q2.
====
AD FS のプロパティで、セキュア ハッシュ アルゴリズムを変更することの影響を教えてください。

====
A2.
====
トークンの署名を検証する証明書利用者信頼が、設定したハッシュ アルゴリズムに対応している必要があります。
もし証明書利用者信頼が、設定したアルゴリズムに対応していない場合、署名の検証に失敗し、アクセスが拒否される可能性があります。

Office 365 の場合には、SHA-256 の署名の検証に対応しており、SHA-256 が推奨されておりますので、SHA-1 が設定されている場合には変更をお願いします。
(現状では SHA-1 にも対応しておりますが、2017年 7月 1日 より SHA-1 に非対応となる可能性がございます。)

====
Q3.
====
該当のハッシュアルゴリズムを変更する時に、AD FS サーバーの再起動は必要ですか?
また、ユーザーの認証が停止するなど、ダウンタイムは生じますか?

====
A3.
====
設定の際に、AD FS サーバーを変更する必要はありません。
ファーム内のプライマリサーバーで変更してください。(セカンダリ サーバーには自動的に反映されます。)
また、ユーザーの認証が停止するなどのダウンタイムは生じません。

====
Q4.
====
設定が変更されていることを確認する方法はありますか?

====
A4.
====
プライマリ AD FS サーバー上で、以下のように Get-AdfsRelyingPartyTrus コマンドレット を使用して確認することができます。

// SHA1 の状態
Get-AdfsRelyingPartyTrust -Name ‘Microsoft Office 365 Identity Platform’ | select SignatureAlgorithm

SignatureAlgorithm
——————
http://www.w3.org/2000/09/xmldsig#rsa-sha1 ★ <<<
// SHA-256 の状態
Get-AdfsRelyingPartyTrust -Name ‘Microsoft Office 365 Identity Platform’ | select SignatureAlgorithm

SignatureAlgorithm
——————
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 ★ <<<

====
Q5.
====
AD FS Proxy サーバー (WAP サーバー) で何か作業が必要ですか?

====
A5.
====
AD FS Proxy サーバー (WAP サーバー) で必要な作業はありません。

Neue Windows 10 Upgrade-Leistungen im CSP-Programm

$
0
0

windows-10-im-csp-programm-jpg

Kunden mit Windows 10 Enterprise-Abonnements im Cloud Solution Provider (CSP)-Programm können jetzt ohne Zusatzkosten ein Upgrade ihrer PCs und Geräte mit Windows 7 und Windows 8.1 auf Windows 10 machen!

Kunden, die Windows 10 Enterprise E3 und E5 sowie Secure Productive Enterprise E3 und E5 abonniert haben, haben nun die Möglichkeit, ein Upgrade ihrer PCs und Geräte mit Windows 7 und Windows 8.1 auf Windows 10 machen – und das, ohne separate Upgrade-Lizenzen kaufen zu müssen.

Es handelt sich hierbei um eine wichtige Zusatzleistung für Windows 10 Enterprise-Abonnements im Rahmen von CSP. Sie ermöglicht Kunden, die noch kein neues Windows 10 Gerät gekauft oder die Möglichkeit zum kostenfreien Upgrade im ersten Jahr von Windows 10 verpasst haben, den Zugang zu Sicherheit auf Unternehmensniveau zum kleinen Preis, verwaltet von einem erfahrenen Partner.

Um von dieser neuen Upgrade-Leistung Gebrauch zu machen, können sich Mandanten-Administratoren von Kunden mit Cloud-Abonnements mit ihrer Azure Active Directory-Administratorkennung am Office 365 Admin Center unter http://portal.office.com anmelden. Dort werden die folgenden Optionen angezeigt: Upgrade des gerade benutzten Gerätes, Download-Link mit anderen Unternehmensmitgliedern teilen, Installationsmedien erstellen oder Installationsprobleme lösen.

Die als Teil dieses Vorgangs erteilten Windows 10 Upgrade-Lizenzen sind zeitlich unbeschränkt gültig und mit dem jeweiligen Gerät verknüpft. Das bedeutet, dass die Lizenz nicht abläuft oder ungültig wird, wenn der Kunde sein Windows 10 Enterprise-Abonnement im CSP-Programm beendet.

o365-admin-center

Mandanten-Administratoren können im Office 365 Admin-Center auf die neuen Windows 10 Upgrade-Leistungen zugreifen (oben).

Die neuen Upgrade-Leistungen wurden vor einigen Tagen ausgerollt. Mandanten-Administratoren mit Windows 10 Enterprise-Abonnements im CSP sollten die Windows 10 Upgrade-Optionen und -Links mittlerweile in ihrem Office 365 Admin-Center sehen können.

Wir hoffen, dass diese neuen Windows 10 Upgrade-Leistungen Unternehmen jeder Größe – einschließlich Unternehmen mit PCs und Geräten, die noch Windows 7 und Windows 8.1 nutzen – die Zusammenarbeit mit einem Partner ihres Vertrauens ermöglichen, um ein Upgrade auf Sicherheit und Verwaltung auf Unternehmensniveau durchzuführen – und das mit flexiblen Preisen ab 5,90€ pro Benutzer und Monat für kleine Unternehmen.

Microsoft Partner können über die folgenden Ressourcen mehr über Windows 10 Enterprise-Abonnements im CSP erfahren:


Site-to-Site VPN zwischen Clouds

$
0
0

(this article is also available in english)

Nachdem Microsoft Azure Deutschland ja eine separate Instanz der Azure Cloud ist, mit unterschiedlichen Subscriptions, Rechenzentren, und auch ohne Verbindung zum Backbone, stellt sich die Frage, ob und wie man eine Azure Umgebung netztechnisch mit Azure Deutschland verknüpfen kann. Und genau das soll Thema dieses Blogposts sein.

Um Netze nach und in Azure zu koppeln gibt es grundsätzlich mal 4 Verfahren:

  • VNet Peering
  • VNet-to-VNet (V2V)
  • Site-to-Site (S2S)
  • ExpressRoute(s) (nur der Vollständigkeit halber hier, würde aber zu weit führen)

Schauen wir uns also die Möglichkeiten mal an…

VNet-Peering

Eine Voraussetzung für VNet-Peering ist, dass sich beide VNets in derselben Region befinden. Da dies bei AZure und AZure Deutschland offensichtlich nicht der Fall ist, müssen wir das hier auch nicht weiter betrachten. Wen VNet-Peering trotzdem interessiert, der findet hier einen tollen Artikel dazu.

VNet-to VNet (V2V)

VNet-toVnet (V2V) ähnelt dem im folgenden Abschnitt beschriebenen S2S, nur liegen hier beide VNets mit ihren Endpunkten in Azure. Man kann also V2V zum Beispiel verwenden, um Netze in unterschiedlichen Azure-Regionen verbinden zu können, selbst wenn diese in unterschiedlichen Subscriptions angelegt sind (dann halt nur via PowerShell, aber wen stört das schon…). Das Aufsetzen ist super einfach und hier prima beschrieben, aber leider müssen für V2V beide Subscriptions innerhalb der gleichen Azure Umgebung liegen, also beide in Azure oder beide in Azure Deutschland. Damit scheidet V2V für unsere geplanten Zwecke auch aus…

Site-to-Site (S2S)

Normalerweise verwendet man S2S, um zwischen Azure und der lokalen (on-premise) Netzwerkumgebung einen verschlüsselten Tunnel herzustellen. Man vereint beide Netzwerke also zu einem, indem man jeweils ein Gateway definiert und beide mit den Infos versorgt, wo sich der andere Endpunkt befindet und wie man miteinander redet (IPSec Parameter, Adressen etc). Auch hier gibt es eine einfach nachzuvollziehende Anleitung, von der wir hier nur in Stichworten die Reihenfolge der notwendigen Schritte betrachten:

  1. Virtuelles Netzwerk erstellen
  2. Adressraum definieren
  3. Subnetze erstellen
  4. Gateway-Subnetz erstellen
  5. Gateway für VNet erstellen
  6. Gateway für lokales Netz erstellen (quasi der Platzhalter für ihr lokales Gerät)
  7. lokales VPN-Gerät konfigurieren
  8. Verbindung herstellen

Um VNets zwischen Azure und Azure Deutschland zu koppeln, bereitet man in beiden Umgebungen alles vor (Schritt 1-5 aus obiger Liste), um das VNet mit einem normalen VPN-Gerät zu verbinden, und gibt dann einfach die beiden Gateways bei der jeweils anderen Konfiguration als Partner an (Schritt 6). Oder anders ausgedrückt: Statt Schritt 7 wird einfach nochmal Schritt 1-6 in der anderen Umgebung durchgeführt. Man tut also quasi so, als ob der andere Endpunkt ein on-premise Gateway ist. Nachdem beide angelegt sind, führt man Schritt 6 in Azure aus und gibt als Adresse die öffentliche IP des Gateways in Azure Deutschland an, und noch einmal Schritt 6 in Azure Deutschland mit Angabe der öffentlichen IP des Azure-Gateways. Und dann direkt noch Schritt 8, und das war’s. ALles klar? Nein? ok, dann hier nochmal:

  • Schritt 1-5 für Azure durchführen
  • Schritt 1-5 für Azure Deutschland durchführen
  • Schritt 6 in Azure mit Eingabe der öffentlichen IP des Gateways in Azure Deutschland (aus dem vorherigen Schritt)
  • Schritt 6 in Azure Deutschland mit Eingabe der öffentlichen IP Adresse des Gateways in Azure
  • verbinden mit Schritt 8 (und Schritt 7 entfällt)

Ab sofort können dann VMs, die man in einem der beiden VNets anlegt, über den IPSec-Tunnel mit ihren IP-Adressen miteinander kommunizieren.

Caveat

Zwischen V2V und S2S gibt es Unterschiede bei den Preisen für Netzwerkverkehr. Bitte unbedingt vorher nachlesen!

Der Tunnel selbst führt über das normale Internet, daher sind Ausfälle oder schwankende Bandbreiten nicht auszuschließen, also genau wie bei S2S-Verbindungen zwischen Azure und on-premise.

(S)Ways we work: Auf der Suche nach einem neuen Verständnis von Arbeit

$
0
0

Moderne Technologien haben unseren Alltag in den vergangenen Jahren kräftig verändert und werden es auch in Zukunft tun. Im Privatleben genauso wie im Beruf. Doch gerade die Veränderungen in der Arbeitswelt haben dazu beigetragen, ein Nachdenken über die Arbeit als solche anzustoßen.

Den Fragen, als was Arbeit heute und in Zukunft begriffen wird, geht Anna Süster Volquardsen nach, die das Onlinemagazin DEAR WORK gründete. Mehr über ihre Motivation, sich mit dem Thema Arbeit auseinanderzusetzen und wie sie selbst eigentlich am liebsten und produktivsten arbeitet, verrät sie uns im Beitrag unserer Reihe (S)Ways we work:

 

Wie wir bei Microsoft uns die neue Arbeitswelt vorstellen und sie bereits jeden Tag ein Stück weit in unserer neuen Deutschland-Zentrale in München Schwabing erleben, erfahrt ihr hier.

Ein Beitrag von Charlotte Reimann
Communications Manager Digital Workstyle bei Microsoft Deutschland

Charlotte Reimann

 

Windows (Storage) Server 2016 で、ネットワーク上のイメージからの回復時の資格情報の入力について

$
0
0

こんにちは、Windows Platform サポートです。

Windows (Storage) Server 2016 環境にて、Windows RE 環境から、ネットワーク上のイメージを指定して回復を行う場合、資格情報の入力の動作が以前のバージョンと異なるとのご申告をいただいております。

本記事では、資格情報の入力に際しての注意点についてご案内します。

 

[内容]

Windows (Storage) Server 2016 環境にて、Windows RE 環境から、ネットワーク上のイメージを指定して回復を行う場合、資格情報の入力ダイアログにおいて、ユーザー名のみを入力した場合、以下のようなエラーが表示されます。

170131winrerestore1

 

[原因]

Windows (Storage) Server 2016 では、資格情報入力ダイアログにおいて、[ドメイン名] は既定で空欄となっており、以前のバージョンと異なりコンピュター名が自動入力された状態ではないため、上記の動作となります。

 

[回避策]

Windows (Storage) Server 2016 では、資格情報入力ダイアログにユーザー名を入力する際、コンピューター名またはドメイン名を含む形で入力してください。

(例)
“コンピューター名ユーザー名”
または
“ドメイン名ユーザー名”

Exchange Server で RFC に準拠していない SMTP アドレスからのメール受信を許可する方法

$
0
0

今回は Exchange Server の各バージョンで RFC に準拠していない SMTP アドレスからのメール受信を許可する方法についてご紹介いたします。
なお、Exchange Online に関しては RFC に準拠していない SMTP アドレスからのメール受信を許可する方法は現時点で提供されていません。

機能概要
Exchange Server では「user.@contoso.com」や「user..name@contoso.com」など RFC に準拠していない SMTP アドレスからのメール受信は既定で許可されていません。
これらの SMTP アドレスからのメール受信を許可する機能は Exchange 2007 SP3 RU2 と Exchange 2010 SP1 で追加され、Exchange 2013 と Exchange 2016 に関してはリリース時点 (RTM) で提供されております。

なお、本機能は「user.@contoso.com」の SMTP アドレスを「”user.”@contoso.com」のようにローカル パートを二重引用符で括って RFC に準拠した SMTP アドレスに置換することでメールを受信出来るようにする機能であり、「user.@contoso.com」の形式のままメールを受信出来るわけではございません。
該当メールに返信する場合には「”user.”@contoso.com」の形式で送信されますので、相手側のサーバーが「”user.”@contoso.com」の SMTP アドレスを「user.@contoso.com」と認識しない場合には配信不能通知 (NDR) が返される可能性がございますのでご注意ください。

– 補足
Exchange Server を利用するユーザーが新規にメールを作成して宛先に RFC に準拠していない SMTP アドレスを指定して送信するシナリオの場合、本機能を有効化したとしても配信不能通知 (NDR) が返されます。
Exchange Server から RFC に準拠していない SMTP アドレスに対してメールを送信するには手動でローカル パートを二重引用符で括った SMTP アドレスを指定していただく必要がございます。

設定方法
本機能を有効化するには Exchange Server 上のアプリケーション構成ファイル (.config) にエントリを追加した上でサービスの再起動が必要となります。
ただし、Exchange Server のバージョンにより変更するアプリケーション構成ファイルと再起動するサービスが多少異なりますので、各バージョンでの設定方法を以下に記載いたします。

– Exchange 2007 の場合
HUB で有効化する場合でも Edge で有効化する場合でも手順は同じとなります。

———-
1. 該当サーバー上で以下のフォルダを開きます。

C:Program FilesMicrosoftExchange ServerBin

2. EdgeTransport.exe.config ファイルをメモ帳などで開きます。(問題が発生した際に元に戻せるようにファイルのバックアップ コピーも取得しておいてください)
3. <appSettings> と </appSettings> の間に以下のエントリを追加して保存します。

<add key=”AcceptAndFixSmtpAddressWithInvalidLocalPart” value=”true” />

2017020201

4. Microsoft Exchange Transport サービスを再起動します。
———-

Title: Exchange Server 2007 ユーザーが電子メール メッセージを受信者に送信すると、”550 5.1.3″ NDR メッセージを受信する
URL: https://support.microsoft.com/ja-jp/help/2282570

– Exchange 2010 の場合
HUB で有効化する場合でも Edge で有効化する場合でも手順は同じとなります。

———-
1. 該当サーバー上で以下のフォルダを開きます。

C:Program FilesMicrosoftExchange ServerV14Bin

2. EdgeTransport.exe.config ファイルをメモ帳などで開きます。(問題が発生した際に元に戻せるようにファイルのバックアップ コピーも取得しておいてください)
3. <appSettings> と </appSettings> の間に以下のエントリを追加して保存します。

<add key=”AcceptAndFixSmtpAddressWithInvalidLocalPart” value=”true” />

2017020202

4. Microsoft Exchange Transport サービスを再起動します。
———-

Title: Exchange 2010 で @ の直前にピリオドがあるなどの RFC に準拠していない SMTP アドレスを含むメッセージを受信できない
URL: https://support.microsoft.com/ja-jp/help/2439987

– Exchange 2013 の場合
Exchange 2013 では「CAS が提供する Frontend Transport サービス」で有効化する場合と「MBX もしくは Edge が提供する Transport サービス」で有効化する場合で手順が異なります。

・CAS が提供する Frontend Transport サービスで有効化する場合
———-
1. 該当サーバー上で以下のフォルダを開きます。

C:Program FilesMicrosoftExchange ServerV15Bin

2. MSExchangeFrontendTransport.exe.config ファイルをメモ帳などで開きます。(問題が発生した際に元に戻せるようにファイルのバックアップ コピーも取得しておいてください)
3. <appSettings> と </appSettings> の間に以下のエントリを追加して保存します。

<add key=”AcceptAndFixSmtpAddressWithInvalidLocalPart” value=”true” />

2017020201

4. Microsoft Exchange Frontend Transport サービスを再起動します。
———-

・MBX もしくは Edge が提供する Transport サービスで有効化する場合
———-
1. 該当サーバー上で以下のフォルダを開きます。

C:Program FilesMicrosoftExchange ServerV15Bin

2. EdgeTransport.exe.config ファイルをメモ帳などで開きます。(問題が発生した際に元に戻せるようにファイルのバックアップ コピーも取得しておいてください)
3. <appSettings> と </appSettings> の間に以下のエントリを追加して保存します。

<add key=”AcceptAndFixSmtpAddressWithInvalidLocalPart” value=”true” />

2017020202

4. Microsoft Exchange Transport サービスを再起動します。
———-

– Exchange 2016 の場合
Exchange 2016 では CAS が廃止され、Exchange 2013 の CAS が提供していた Frontend Transport サービスは MBX で提供されています。
ただし、Frontend Transport サービスで有効化する場合と Transport サービスで有効化する場合の手順はアプリケーション構成ファイルの場所も含めて Exchange 2013 と同じになります。

設定が必要なサーバー
本機能は RFC に準拠していない SMTP アドレスからのメールを外部から最初に受信する Exchange Server 上で有効化していただく必要がございます。
例えば、以下のような経路で Exchange Server にメールが配信される場合に有効化が必要なサーバーは Edge となります。(複数のバージョンが混在する環境でも同様)

・[上位の SMTP サーバー] –> [Exchange 2010 (Edge)] –> [Exchange 2010 (HUB)] –> [Exchange 2010 (MBX)]

・[上位の SMTP サーバー] –> [Exchange 2013 (Edge)] –> [Exchange 2013 (CAS)] –> [Exchange 2013 (MBX)]

・[上位の SMTP サーバー] –> [Exchange 2016 (Edge)] –> [Exchange 2016 (MBX)]

また、以下のように外部から最初にメールを受信するサーバーが「Exchange 2013 のマルチロール」の場合や「Exchange 2016 の MBX」の場合、該当サーバー上で外部からのメールを処理する受信コネクタがどのサービスに紐付いて構成されているかに依存いたします。

・[上位の SMTP サーバー] –> [Exchange 2013 (CAS/MBX)]

・[上位の SMTP サーバー] –> [Exchange 2016 (MBX)]

受信コネクタがどのサービスに紐付いているかは Exchange 管理シェルから以下のコマンドを実行することで確認することができます。

Get-ReceiveConnector -Server <サーバー名> | fl Identity,TransportRole

* TransportRole の設定が [FrontendTransport] と表示される場合は Frontend Transport サービス、[HubTransport] と表示される場合は Transport サービスに紐付いています。

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

Windows (Storage) Server 2016 で Windows Search サービスをご利用の場合の手順

$
0
0

こんにちは、Windows Platform サポートです。

Windows (Storage) Server 2016 では、 Windows Search サービスをご利用いただく際の手順が以前のバージョンから変わっています。

今回は、Windows (Storage) Server 2016 で Windows Search サービスをご利用いただく手順についてご案内します。

 

[内容]

Windows (Storage) Server 2016 にて、サーバー マネージャーの [役割と機能の追加] から [Windows Search サービス] の機能を追加しても、Windows Search サービスのスタートアップの種類が [無効] のままになります。

(なお、 Windows Search サービス自体は、 [役割と機能の追加] から追加しない場合でも、システムに初めからインストールされた状態となっております)

 

[原因]

Windows (Storage) Server 2016 では、[役割と機能の追加] から [Windows Search サービス] を追加した際の動作が変更されているためです。

 

[回避策]

当社では、この動作についての対応を検討中です。

現時点では、Windows (Storage) Server 2016 で Windows Search サービスの機能をご利用になる際は、[役割と機能の追加] を行うのではなく、サービスのスタートアップの種類を [自動 (遅延開始)] に変更いただくことで利用可能になります。

Viewing all 34890 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>