• Azure Event Grid is a fully-managed event routing service which greatly simplifies the development of event-based applications and simplifies the creation of serverless workflows. Using a single service, Azure Event Grid manages all routing of events from any source, to any destination, for any application.
• Azure Event Grid, is also intelligent, i.e. it enables direct event filtering using event type, prefix or suffix, so your application will only need to receive the events you care about. Whether you want to handle built-in Azure events, like a file being added to storage, or you want to produce your own custom events and event handlers, Event Grid enables this through the same underlying model. Thus, no matter the service or the use case, the intelligent routing and filtering capabilities apply to every event scenario and ensure that your apps can focus on the core business logic instead of worrying about routing events.

Wait.. Isn't this identical to Azure Service Bus ?

What about Azure Event Hubs?

So is this like AWS Simple Notification Service?

What else do we get?

• Near-real-time event delivery
• Fan-out - Subscribe multiple endpoints to the same event to send copies of the event to as many places as needed.
• Massive scale - Supports high-volume workloads with support for millions of events per second. 
• Reliable Delivery - Event Grid will perform an exponential back off for all deliveries. Ex: If your WebHook does not return a HTTP 2xx, the retry begins immediately. When the back off interval reaches one hour, retries will be performed every hour. After 24 hours, the service will stop attempting to deliver events

What can we do with Event Grid?

Azure Event Grid provides several capabilities that vastly improve serverless, ops automation, and integration work:

Serverless application architectures

To connect various cloud services so as to react to changes. For example, use Event Grid to instantly trigger a serverless function to run image analysis each time a new photo is added to a blob storage container. Another example could be that of an ad-serving app built on Azure publishes millions of events to an application topic that has several event subscriptions connected to it. All events are pushed to SQL Data Warehouse and are also sent to one of several custom Node.js apps for processing, based on the origin of the event.

Ops Automation

Event Grid also allows to speed up automation and simplify policy enforcement. For example, Event Grid can notify Azure Automation when a virtual machine is created, or a SQL Database is spun up. These events can then be used to check that service configurations are compliant, tag virtual machines, or file work items, etc.

Custom Application integration

Event Grid connects can also connect a custom app with other services. For example, we can create a custom topic to send your app's event data to Event Grid, and take advantage of its reliable delivery, advanced routing, and direct integration with Azure and use it in an Azure Function that is created with Webhook Trigger.

1. Getting started with Azure PowerShell
2. Create your first Azure Resource Manager template.
3. Create network security groups
4. Azure Active Directory and Microsoft Graph
5. Deploying Active Directory Federation Services in Azure
6. Encrypt and decrypt blobs in Microsoft Azure Storage using Azure Key Vault
7. Azure AD B2C
8. Transparent Data Encryption with Azure SQL Database
9. Custom Roles for Azure RBAC
10. Web API 2 in an Azure Worker Role
11. Run Background tasks with WebJobs
12. Set up staging environments in Azure App Service
13. Configuring App Service application to use Azure Active Directory login
14. Service Bus Topics
15. Azure Scheduler
16. Azure Machine Learning
17. Integrate and App with a Virtual Network
18. Back up files and folders in Resource Manager deployment
19. Powershell Workflow Runbook

1. Read the Azure documentation (as in my previous blog) and make short notes. Like my notes here.
2. Do the hands-on lab exercises (Listed above).
3. Go through these videos and tips from Mark Grimes just the day before your exam and co-relate them to your notes.

1. Time management:
   1. Always keep an eye on the timer – if you don’t know an answer, click on the ‘Review Later’ checkbox and move on.
   2. Case studies take up a lot of time, so be prepared:
      1. Case studies are usually about Apps; they are net new for Azure or need to be migrated to Azure.
      2. Write down some short notes in your erasable notepad about each App in the case study by quickly going through the business requirements and the technical requirements. This is important – For questions following the case study you will need to know the context when attempting to answer. Ex: You are asked to choose between Storage Queue and Service Bus Queue, now unless you got to know from the requirement, which told you that the application must store over 80 GB of messages in a queue, you wouldn’t know the right answer.
      3. While quickly skimming through to get some context is important, don’t spend too much time (no more than 10mins on each case study), you just need to know where to find info when you see a related question.

2. Elimination: For several questions, use logic and try to eliminate some of the wrong answers. Some answers are far from truth making your life easier.

• Easy customization:  No need to ramp up on XAML workflow to customize the build. Edit in the web and leverage existing knowledge of popular script languages.
• Cross-platform support: The build agents can now run not only on Windows, but also on Linux and Mac OSX.
• No more controllers: Agents can now span team project collections. Side-by-side installs and remote agents are xcopy (download from the web UI). And no need to install TFS on your build machines anymore.

Read more: https://msdn.microsoft.com/Library/vs/alm/Build/feature-overview

In this blog, I'd like to describe and walk you through to show how easy it is to build a windows build agent and create a new build definition.

Before we begin, lets us make sure the build agent machine is set up with:

• An operating system that is supported by Visual Studio 2013 or newer
• Visual Studio 2013 or Visual Studio 2015
• PowerShell 3 or newer

Note: If you are not the Team Services account owner or an on-premises server team project collection administrator, make sure you have been added as an agent pool administrator.

Let’s get started, login to the box you want to configure as the Build agent, navigate to the TFS Web URL home page, and click on Settings at top-right corner of the page.

From the Control panel > select the tab ‘Agent Pools’

Since this is the first agent we are configuring we will see the message – ‘No agents are registered or you do not have permission to view the agents’ as shown below.

Now click on the ‘Download Agent’ option, download and extract the zip file to any location on the machine you want to configure as the build agent.

In case the zip file or any of its files are is ‘blocked’, ‘unblock’ them.

Run the ‘ConfigureAgent.cmd’ as administrator.

Few questions may be asked during this configuration step:

1. Enter the name for this agent (default is Agent-SUTESIVS2013U4)
2. Enter the URL for the Team Foundation Server (default is ) https://sutestvs2013u4:8080/tfs/
3. Configure this agent against which agent pool? (default pool name is 'default')
4. Enter the path of the work folder for this agent (default is 'C:\TFS2015NewAgent\agent\_work')
5. Would you like to install the agent as a Windows Service (Y/N) (default is N)
6. Enter the name of the user account to use for the service (default is NT AUTHORITY\LOCAL SERVICE)

Most questions are self-descriptive and we can choose to configure it as a Windows service, if desired.  We can also create additional pools in which to run other instances of agents if required. For example, you might want to configure different security settings
for individual agents. For now, we will stick with the Default pool. Once run, we should see the following success message:

Installing service vsoagent.sutestvs2013u4.Agent-SUTESTVS2013U4...
Service vsoagent.sutestvs2013u4.Agent-SUTESTVS2013U4 has been successfully installed.
Creating EventLog source vsoagent.sutestvs2013u4.Agent-SUTESTVS2013U4 in log Application...  

Refresh the TFS Portal page and Voila! we should now be able to see the new build agent and its capabilities.

Next, let us create a simple new build definition.

First navigate back to Home page > Select Team project and click on ‘Build’ Menu. Here we can see the older XAML build definitions as well as the new Web-based Build Definitions. We can add a new build definition by clicking on the big ‘+’ icon, which brings up the below dialog:

The Definition Templates dialog helps us choose from either existing templates or start with an empty definition. Let us choose the empty definition and then add build steps by selecting the ‘Add Build Step’ option. Clicking on ‘Add Build Step’ brings us the following dialog.

Here, add the option ‘Visual Studio Build’ and close the dialog. We can now select the solution location and save the definition with a name of our choice.  

There are multiple other properties (variables, triggers, etc.) we can set and we can also add multiple build steps depending upon what we want to achieve – but that’s for another day!

Once the build definition is saved, let us perform a quick test of our new build definition by queuing a new build – This should give us the sweet ‘Build Succeeded’ message.

We can also create a Custom Build Template that can be used as a starter for other build definitions. Or set a build definition as a team favorite for others to follow when creating their build definitions by right clicking on a build definition and selecting the required option as shown here:

Related article to build ClickOnce apps: https://blogs.msdn.com/b/tfssetup/archive/2015/10/15/building-clickonce-apps-using-build-vnext.aspx

For those unfamiliar with WebActivator it’s an incredibly useful tool to have if you are a packager or a framework developer. Read more: https://blogs.msdn.com/b/davidebb/archive/2010/10/11/light-up-your-nupacks-with-startup-code-and-webactivator.aspx

It basically provides three methods – PreStart(), PostStart and ShutDown() to which we can hook any custom code. What’s the big deal, we can do this in Global.asax? Well, this becomes incredibly useful when one is making their own package and would like to perform certain actions when application starts or shuts down but don’t want the package consumer to do these actions manually!

This little library really intrigued me on how it is possible to achieve it without hooking into the consuming code – so decided to perform a little bit of investigation to understand how it works and here is what I found.

Step One: Long time - no see! Global Attributes.

Global attributes have been in .NET for a very long time, but I have not seen them used much except for defining the usual title, description, version, etc AssemblyInfo.cs as shown in below example:

[assembly: AssemblyTitle("WindowsApplication1")]

More: https://msdn.microsoft.com/en-us/library/284c1c4s(v=vs.90).aspx

This is what we find in WebActivator assembly:

[assembly: System.Web.PreApplicationStartMethod(typeof(ActivationManager), "Run")] 

Step Two: What is PreApplicationStartMethod?

Turns out that this attribute in System.Web namespace was added in .NET 4.0 and is the key to functioning of WebActivator. The PreApplicationStartMethodAttribute constructor takes two parameters. First parameter is the Type of the class required to be called before an application starts and the second parameter is a string that represents the static method within the type to be called.

More: https://msdn.microsoft.com/en-us/library/system.web.preapplicationstartmethodattribute(v=vs.110).aspx

So we head to ActivationManager > Run method.

Step Three: Unravelling the mystery.

As I slowly understand the code written in ActivationManager’s static Run method, things become a little clearer.

public static void Run()
        {
            if (!ActivationManager._hasInited)
            {
                bool flag = Type.GetType("Mono.Runtime") != null;
                if (flag)
                {
                    ActivationManager.RunPreStartMethods(false);
                }
                else
                {
                    ActivationManager.RunPreStartMethods(ActivationManager.IsInClientBuildManager());
                }
                if (HostingEnvironment.IsHosted)
                {
                    Type typeFromHandle = typeof(ActivationManager.StartMethodCallingModule);
                    if (flag)
                    {
                        HttpModuleActionCollection modules = (WebConfigurationManager.GetWebApplicationSection("system.web/httpModules") as HttpModulesSection).Modules;
                        modules.Add(new HttpModuleAction(typeFromHandle.FullName, typeFromHandle.AssemblyQualifiedName));
                    }
                    else
                    {
                        DynamicModuleUtility.RegisterModule(typeFromHandle);
                    }
                }
                else
                {
                    ActivationManager.RunPostStartMethods();
                }
                ActivationManager._hasInited = true;
            }
        }

Ok so there is a checkfor Mono.Runtime. Then the PreStartMethods are called. Obvious takeaway is hosting on mono is different and hence the flag.  

RunPreStartMethods calls ActivationManager.RunActivationMethods<PreApplicationStartMethodAttribute>(designerMode); 

As shown below this code scans all the assemblies for all custom PreApplicationStartMethod attributes, orders them and invokes the methods. The same scheme of method invocation is true for PostApplicationStartMethodAttribute and ApplicationShutdownMethodAttribute, the difference is only when they are called. 

private static void RunActivationMethods<T>(bool designerMode = false) where T : BaseActivationMethodAttribute
        {
            IOrderedEnumerable<T> orderedEnumerable = 
                from att in ActivationManager.Assemblies.Concat(ActivationManager.AppCodeAssemblies).SelectMany((Assembly assembly) => assembly.GetActivationAttributes<T>())
                orderby att.Order
                select att;
            foreach (T current in orderedEnumerable)
            {
                if (!designerMode || current.ShouldRunInDesignerMode())
                {
                    current.InvokeMethod();
                }
            }
        }

That kind of solves the puzzle of how PreStartMethod is works.

Step four: Post Start Method and let’s shutdown!

The PostApplicationStartMethodAttribute attribute allows to execute code after Application_Start method in Global.asax. But how is it determined. If we look back at the code in static Run method of ActivationManager class we will notice StartMethodCallingModule being registered. This is custom Http Module implementing IHttpModule interface with two methods - Init() and Dispose().

Inside Init() method RunPostStartMethods() is called. Also interesting to note here is that if the application is not hosted on IIS, activation method in this attribute will be invoked immediately after PreApplicationStartMethod.

Since HTTPModules may call Init() method more than once, there is a counter _initializedModuleCount inside a lock statement to ensure its called only once.

And now for the last attribute, ApplicationShutdownMethodAttribute, it’s called in Custom HTTPModule’s Dispose() method and the counter now runs in reverse and the shutdown methods will be invoked on dispose of the last module.

private class StartMethodCallingModule : IHttpModule
{
    private static object _lock = new object();
    private static int _initializedModuleCount;
    public void Init(HttpApplication context)
    {
        lock (ActivationManager.StartMethodCallingModule._lock)
        {
            if (ActivationManager.StartMethodCallingModule._initializedModuleCount++ == 0)
            {
                ActivationManager.RunPostStartMethods();
            }
        }
    }
    public void Dispose()
    {
        lock (ActivationManager.StartMethodCallingModule._lock)
        {
            if (--ActivationManager.StartMethodCallingModule._initializedModuleCount == 0)
            {
                ActivationManager.RunShutdownMethods();
            }
        }
    }
}

If you are a custom package developer, this tool will come really handy. It can be downloaded from Nuget. The source is available at https://github.com/davidebbo/WebActivator

This blog describes the steps I took to install SharePoint 2013 in the Complete installation mode.

The installation of SharePoint 2013 in the Complete mode is fairly simple with a few clicks and some patience. It took about 15-20 mins for this to complete. Next is the SharePoint Products Configurations Wizard.  On the screen shown below, the wizard doesn't allow to proceed without selecting the right version of SQL Server and specifying a domain account.

I could have setup an Active Directory on the same box, but it is not recommended to install SharePoint on a Domain Controller. The other option was to setup a second virtual machine as AD-Controller and third as SQL Server. But then, I would have to manage three servers! So I closed the wizard window.

Please note that following steps are good only for a development setup.

Next I installed  SQL Server SQL Server 2008 R2 Expression Edition on the default instance and not the named instance.

Note that SharePoint 2013 only supports SQL Server 2008 R2 (versions > 10.50.1600.1). You may use this link to install  SQL Server 2008 R2 Express SP2.

Once the SQL Server Express installation was complete, the trick is to use the powershell command: New-SPConfigurationDatabase to create the Config DB. You can specify the local account here! I could use the Powershell to create the SharePoint_ConfigDB successfully.

Once this was done, I went back to the SharePoint Products Configurations Wizard, and this time I had the default option of Connect to an Existing Farm checked. A few more clicks and I was ready to explore the new SharePoint 2013.