Question : : You work as a Network Administrator for ABC.com. The company has a single Active Directory Domain Services (AD DS) domain named ABC.com. All domain controllers in the ABC.com`domain run Windows Server 2008 R2. The company has an on-premise Microsoft Exchange 2010 organization and a Lync Server 2010 environment. The company has recently purchased a Microsoft Office 365 subscription. You plan to migrate to Exchange Online and Lync Online. You need to configure directory synchronization between the on-premise Active Directory and Azure Active Directory. The on-premise Active Directory contains many Organizational Units (OUs). Some OUs contain user accounts that are used as service accounts for on-premise services. You need to configure directory synchronization to enable you to exclude OUs from the synchronization schedule. Which of the following actions should you perform?
1. Use Active Directory Sites and Services to create Active Directory partitions before configuring DirSync. 2. Run the Set-MsolDirSyncEnabled PowerShell cmdlet after installing DirSync. 3. Run the Remove-MsolServicePrincipal PowerShell cmdlet after installing DirSync. 4. After the installation of Dirsync, run miisclient.exe to create directory partitions.
Correct Answer : 4 Explanation: You can enable Active Directory synchronization filtering in Azure Active Directory at any time. If you have already run the default configurations of directory synchronization and then configured the filtering, the objects that are filtered out are no longer synchronized to the cloud. As a result, any objects in the cloud that were previously synchronized but were then filtered out of the synchronization are deleted by the directory synchronization process. If objects were inadvertently deleted because of a filtering error, you can re-create the objects in the cloud by removing your filtering configurations, and then syncing your directories again.
Set up organizational-unit-based filtering Log on to the computer that is running directory synchronization by using an account that is a member of the MIISAdmins local security group. Open Identity Manager by double-clicking miisclient.exe that is located in the following folder: %ProgramFiles%\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell
In Identity Manager, click Management Agents, and then double-click Active Directory Connector. Click Configure Directory Partitions, and then click Containers. When prompted, enter your domain credentials for the on-premises Active Directory forest.
Question : You work as a Network Administrator for ABC.com. The company has a single Active Directory Domain Services (AD DS) domain named ABC.com. All domain controllers in the ABC.com domain run Windows Server 2008 R2. The company has an on-premise Microsoft Exchange 2010 organization and a Lync Server 2010 environment. The company has recently purchased a Microsoft Office 365 subscription. You plan to migrate to Exchange Online and Lync Online. The on-premise Active Directory contains many Organizational Units (OUs). User accounts are located in multiple OUs. You have configured Directory Synchronization (DirSync) to synchronize user accounts in selected OUs to Azure Active Directory and performed an initial user account synchronization. You find some user accounts in OUs that are excluded from synchronization that need to be synchronized to Azure AD. You move the user accounts to an OU that is included in the synchronization schedule. You discover that the users are unable to log in to Office 365. You confirm that the user accounts exist in Azure AD. However, event log error messages indicate a problem with password synchronization for the moved user accounts. How should you resolve the issue?
1. Log in to the DirSync server and perform a manual directory synchronization. 2. Run miisclient.exe to modify the directory partitions. 3. Run the Set-FullPasswordSync PowerShell cmdlet and restart the Forefront Identity Manager Synchronization Service service. 4. Run the Set-MsolUser PowerShell cmdlet for each user account that is unable to log in.
Correct Answer : 3 Explanation: In Windows Azure Active Directory Synchronization Tool (or DirSync), a full Password Sync and a full Directory Sync are two different events. A full Password Sync synchronizes password hashes for all DirSync users, while a full Directory Sync does not trigger a full password sync. By default, the only activity that triggers a full password sync is completing the DirSync's Configuration Wizard.
But there is a way around this. In order to trigger a full password sync, perform the following steps (you must be using DirSync v6438.0003 or above):
On the DirSync server, run the following .psc1: C:\Program Files\Windows Azure Active Directory Sync\DirSyncConfigShell.psc1; In the new Powershell console, run Set-FullPasswordSync; Now load the services console by running Services.msc; Restart the Forefront Identity Manager Synchronization Service Service. Once this is complete, you should see a series of 656 EventIDs (Password Sync Requests) and 657 EventIDs (Password Sync Results) indicating that a full password sync was triggered.
To trigger a full password sync, perform the following steps:
Open PowerShell, and then type Import-Module DirSync Type Set-FullPasswordSync, and then press Enter Type Restart-Service FIMSynchronizationService -Force , and then press Enter Once this is complete, you should see a series of EventId=656 (Password Sync Requests) and EventId=657 (Password Sync Results) indicating that your full password sync has kicked off. Having a need to rapidly sync passwords to Office 365 using Directly Sync (DirSync) I come across the following method that seems to work with minimal effort. By default the DirSync only kicks off ever 3-5 min's.
To initiate a full password sync you can do the following:
Open PowerShell, and then type:
Import-Module DirSync
Then Type: Set-FullPasswordSync
Press Enter Load Services.msc Restart the Forefront Identity Manager Synchronization Service Service. (FIMSynchronizationService) In your application event logs you should notices multiple events of 656 (Password Sync Requests) and Even 657 (Password Sync Results) indicating that your full password sync has kicked off.
Question : You work for a company named ABC.com. Your role as Cloud Administrator includes the management of the company's public and private cloud infrastructure. You have applications and virtual machines hosted on Windows Azure. One application hosted in Azure provides a web-based portal that is used by users and customers. The application uses Microsoft Azure Active Directory Access Control and enables users to log in to the application using Microsoft or Google accounts. You want to enable users to log in to the application by using their Facebook accounts. Which two of the following actions should you perform? (Choose two) A. Configure Facebook as an identity provider. B. Install Active Directory Federation Services 2.0 (AD FS 2.0) C. Obtain a Facebook Application ID and a Facebook Application Secret. D. Configure Directory Synchronization with Facebook. E. Configure AD FS 2.0 as an Identity Provider.
1. A,B 2. A,C 3. C,D 4. A,E
Correct Answer : 2 Explanation: ACS does support this feature for the providers that do support that. It is not explicitly documented, because it is not special. ACS does not "just create own token for pure authentication purposes".
If you take the FaceBook IdP, ACS does provide you the FaceBook token, which you can use to query the FaceBook Graph API. And what permissions for the API you will get, depends on what permissions your FaceBook Application will require from authenticating user. I am not sure about the level of sophistication of FaceBook consent framework, but the last I plaid
with it, the authenticating user could only Accept all required consents, or reject all. He was not able to selectively chose which consents to grant to your application, out of all requested.
Having said that, from Google Authentication Provider, you do not receive additional tokens. At least with the old OpenID 2.0 imeplementation. Now with the deprication of OpenID 2.0 and moving Google to OpenID Connect, there is a requirement that you explicitly register your ACS Namespace as application with Google. At that point, I assume (speculation of mine) you may declare requested consents, just as you do with FaceBook. And if Google sends the token, you will definitely receive it in your application through the ACS.
ACS is super powerful service that will not die. As in the referenced blog post, all of its features will sooner or later be moved to Azure AD itself. And a migration plan will be provided (hopefully :) ).
But also, note that ACS do only talk with Yahoo, Google, Facebook, Azure AD and any WS-Federation IdP. And WS-Federation protocol is not known for being very flexible and giving you the flexibility you want. ACS in theory also supports OAuth 2.0, but its support does not include Federation, only local identity management (identities local to ACS self).
Also, note, that ACS is being used by a lot of Microsoft owned services, like Visual Studio Online, Azure Service Bus and others. ACS is neither dead, nor will just die letting all its customers on the wild.
You can decide to use it today. Or you can decide to use whatever features are today available in the Azure AD itself. Or wait until ACS is fully migrated to Azure AD.
1. Add an alert to the CPU metric, and configure the alert threshold to send email to administrators and co-administrators of the subscription. 2. Add an alert to the CPU metric, and configure the alert threshold to send email to a specific email address. 3. Access Mostly Uused Products by 50000+ Subscribers 4. There is no way to configure an alert to use a specific email. You must build a custom solution.