Remote Desktop Connection To Azure WebRoles (Cloud Services)

Connecting to virtual machines though Azure IaaS is common, but you may have wondered how content can be managed for web roles, hosted as Cloud Services. Cloud Services are somewhat of a "black box" when it comes to traditional websites hosted in Microsoft Azure and rightfully so, since web roles are more complex and align with traditional tiered architecture for enterprise web applications. This post will walk through setting up RDP for your cloud services, so you can RDP to one or more instances of the web roles and debug or make necessary changes.

There are a couple of ways to setup RDP for cloud services. One way is by enabling RDP while publishing a webrole to Microsoft Azure,

http://msdn.microsoft.com/en-us/library/gg443832.aspx

however you can also use the portal to set it up. 

1. After filtering a subscription from the Azure Portal, select "Cloud Services" from the menu.

 

2. Select the service and choose Configure

 

3. Down at the bottom of the configuration page, click on the Remote link. The link below walks through the rest for setting it up and more details around removing the RDP configuration.

http://azure.microsoft.com/en-us/documentation/articles/cloud-services-how-to-configure/

but the next step is setting up the configuration by selecting the role, username/psw, certificate and when the RDP will expire on. The above link also provides more detail around the certificate and rebooting of the role once RDP is configured.

4. After selecting the check button from the Configure Remote Desktop window from the Azure Portal, Azure will crunch for a bit and indicate that it is processing the request ot configure RDP for the role. This can take a little bit of time.

5. Once configuration is completed, RDP can be accessed from within Visual Studio and Server Explorer.

 

6. Right-clicking on either of the instances for WebRole1 will start an RDP session, where you can remote into either instances.

Once remoted in, go to IIS so you can see your hosted site and demystify the web role for both instances, and see the file structure for the files that were uploaded during the last deployment. You can also save the .RDP profile so you can remote in from a different computer.  

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted by: BayerWhite
Posted on: 4/24/2014 at 6:13 AM
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed

Processing Service Bus Subscriptions Through WCF - Part 2

In my last post I showed how a WCF service is used to process messages that are sent to Windows Service Bus topic. This post completes the concept by showing how a client application can send event engagement requests to a Windows Service Bus topic, so the messages can later be processed by the WCF service built in my previous post. This post assumes that Windows Service Bus has already been installed. For more information on installing service bus, visit here.

1. Create a new Console Application, which will serve as the client application that will submit messages to the service.

2. Add the service contract which has the interface the WCF service implements, and the data contract for the engagement request. Since the console application does not need a reference to System.ServiceModel.Web, this directive can be commented out.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Runtime.Serialization;

using System.ServiceModel;

//using System.ServiceModel.Web;

using System.Text;

namespace SB.WCF.Subscription

{

[
ServiceContract]

public interface IEngagementService

{

[
OperationContract(IsOneWay = true, Action = "RequestEngagement")]

[ReceiveContextEnabled(ManualControl = true)]

void RequestEngagement(EngagementRequest request);

}

[
DataContract]

public class EngagementRequest

{

[
DataMember]

public Guid EngagementId { get; set; }[

DataMember]

public EngagementInfo Venue { get; set; }[

DataMember]

public string Description { get; set; }[

DataMember]public List<EngagementEvent> EventSchedule { get; set; }

}

public class EngagementEvent

{

[
DataMember]

public string EventName { get; set; }[

DataMember]public DateTime EventDate { get; set; }

}

public class EngagementInfo

{

[
DataMember]

public int Capacity { get; set; }[

DataMember]public string Location { get; set; }

}

}

3. Add the nuget package for Service Bus 1.1. This will add some default configuration to the app.config.

4. Change the app.config with the configuration indicated below. Notice that the configuration is not too different then the configuration used for setting up the WCF service.

<?xml version="1.0" encoding="utf-8"?>

<configuration><

system.serviceModel>

<extensions><

bindingElementExtensions>

<add name="netMessagingTransport" type="Microsoft.ServiceBus.Messaging.Configuration.NetMessagingTransportExtensionElement, Microsoft.ServiceBus, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /></

bindingElementExtensions>

<bindingExtensions><

add name="netMessagingBinding" type="Microsoft.ServiceBus.Messaging.Configuration.NetMessagingBindingCollectionElement, Microsoft.ServiceBus, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

</bindingExtensions><!--

In this extension section we are introducing all known service bus extensions. User can remove the ones they don't need. -->

<behaviorExtensions><

add name="connectionStatusBehavior" type="Microsoft.ServiceBus.Configuration.ConnectionStatusElement, Microsoft.ServiceBus, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

<add name="transportClientEndpointBehavior" type="Microsoft.ServiceBus.Configuration.TransportClientEndpointBehaviorElement, Microsoft.ServiceBus, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /><

add name="serviceRegistrySettings" type="Microsoft.ServiceBus.Configuration.ServiceRegistrySettingsElement, Microsoft.ServiceBus, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

</behaviorExtensions></

extensions>

<behaviors><

endpointBehaviors>

<behavior name="endpointBehavior"><

transportClientEndpointBehavior>

<tokenProvider><

windowsAuthentication>

<stsUris><

stsUri value="https://attpa-10130435.at.local:9355/ServiceBusDefaultNamespace" />

</stsUris></

windowsAuthentication>

</tokenProvider></

transportClientEndpointBehavior>

</behavior></

endpointBehaviors>

</behaviors><

bindings>

<netMessagingBinding><

binding name="messageBinding" closeTimeout="00:03:00" openTimeout="00:03:00" receiveTimeout="00:03:00" sendTimeout="00:03:00" sessionIdleTimeout="00:01:00" prefetchCount="-1">

<transportSettings batchFlushInterval="00:00:01"></transportSettings></

binding>

</netMessagingBinding></

bindings> <client>

<endpoint name="EngagementRequestor"

address="sb://attpa-10130435.at.local/ServiceBusDefaultNamespace/EngagementTopic"

binding="netMessagingBinding"

bindingConfiguration="messageBinding"

contract="SB.WCF.Subscription.IEngagementService"

behaviorConfiguration="endpointBehavior"></endpoint>

</client></

system.serviceModel>

</configuration>

 You will notice that the endpoint only has an address, which was different than the configuration used for the WCF service. This is because the client only needs to know the address (topic) of where the message will be sent.

 4. Now add the following code, which references the WCF service and builds the data contract that will be sent as a message to the service bus.

using SB.WCF.Subscription;

using System;

using System.Collections.Generic;

using System.Linq;

using System.ServiceModel;

using System.Text;

using System.Threading.Tasks;

namespace SB.Subscription.Client

{

class Program

{

static void Main(string[] args)

{

CreateServiceClient();

}

private static void CreateServiceClient()

{

ChannelFactory<IEngagementService> channel = new ChannelFactory<IEngagementService>("EngagementRequestor");

var engagementRequest = new EngagementRequest

{

EngagementId =
Guid.NewGuid(),

Venue = new EngagementInfo { Capacity=50, Location="Hotel California" },Description =

"Geographical Beetle Fighting Tournament",

EventSchedule = new List<EngagementEvent> //[] //indicates a dynamic array

{

new EngagementEvent { EventDate = Convert.ToDateTime("5/6/2014"), EventName="US Beetle Competition"}, new EngagementEvent { EventDate = DateTime.Now, EventName="Asia Beetle Competition"}

}

};

var engagementService = channel.CreateChannel();

engagementService.RequestEngagement(engagementRequest);

channel.Close();

}

}

}

Your client is now ready to send messages to the service bus. Make sure the WCF service is running, that will consume service bus messages and then fire up the client to send a message.

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted by: BayerWhite
Posted on: 4/22/2014 at 1:43 AM
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed

Processing Service Bus Subscriptions Through WCF - Part 1

Microsoft provides a .NET API for working with Windows Service Bus, therefore you can write applications that interact asynchronously with queues, topics & subscriptions, however MS also provides WCF bindings that natively process service bus messages through WCF. After setting up the configuration, messages can be sent to a WCF service for processing. Let me show you how in this post by building a service that will take engagement requests for planned events. Note: This post assumes that you already have Windows Service Bus running locally and that you are aware of how to build Topics and Subscriptions. Another post will come later that illustrates how to send messages to service bus. For more information on installing service bus, visit here

1. Create a new WCF Service Application.

 2. Renamed the default service and interface files to:

EngagementService.svc
IEngagementService.cs

3. Change the IEngagementService.cs code as follows building the interface that the service will use. It also has the data contract that will pass data about the engagement:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Runtime.Serialization;

using System.ServiceModel;

using System.ServiceModel.Web;

using System.Text;

namespace SB.WCF.Subscription

{

[
ServiceContract]

public interface IEngagementService

{

[
OperationContract(IsOneWay = true, Action = "RequestEngagement")]

[ReceiveContextEnabled(ManualControl = true)]

void RequestEngagement(EngagementRequest request);

}

[
DataContract]

public class EngagementRequest

{

[
DataMember]

public Guid EngagementId { get; set; }[

DataMember]

public EngagementInfo Venue { get; set; }[

DataMember]

public string Description { get; set; }[

DataMember]public List<EngagementEvent> EventSchedule { get; set; }

}

public class EngagementEvent

{

[
DataMember]

public string EventName { get; set; }[

DataMember]public DateTime EventDate { get; set; }

}

public class EngagementInfo

{

[
DataMember]

public int Capacity { get; set; }[

DataMember]public string Location { get; set; }

}

}

4. Before changing the code for the service, there are some references that need to be added. Add the nuget package for Service Bus 1.1 .

5. Add the following code to the EngagementService.svc. I am using a complex object for requesting an engagement to illustrate a little more complexity. The only objective for the code below is to show that the engagement request has been sent to the WCF service:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Runtime.Serialization;

using System.ServiceModel;

using System.ServiceModel.Web;

using System.Text;

using System.ServiceModel.Channels;

namespace SB.WCF.Subscription

{

public class EngagementService : IEngagementService

{

public void RequestEngagement(EngagementRequest request)

{

try

{

Guid engagmentId = request.EngagementId;

var capacity = request.Venue.Capacity;

var location = request.Venue.Location;foreach (var engEvent in request.EventSchedule)

{

var docName = engEvent.EventDate;

var docValue = engEvent.EventName;

}

var desc = request.Description;

var messageProperties = OperationContext.Current.IncomingMessageProperties;

ReceiveContext receiveContext;if (ReceiveContext.TryGet(messageProperties, out receiveContext))

{

receiveContext.Complete(
TimeSpan.FromSeconds(10.0d));

}

}

catch (Exception)

{

//something un-amazing has happened

}

}

}

}

6. Next step is to add the glue, which is the configuration. If you noticed, once Service Bus 1.1 gets installed, it loads a ton of config settings within the web.config. Go ahead and delete what is in the web.config and add the following:

<?xml version="1.0" encoding="utf-8"?>

<configuration><

system.web>

<compilation debug="true" targetFramework="4.5" /><

httpRuntime targetFramework="4.5" />

</system.web><

system.serviceModel>

<behaviors><

serviceBehaviors>

<behavior><!--

To avoid disclosing metadata information, set the values below to false before deployment -->

<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" /><!--

To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information -->

<serviceDebug includeExceptionDetailInFaults="false" /></

behavior>

</serviceBehaviors><

endpointBehaviors>

<behavior name="EndpointBehavior"><

transportClientEndpointBehavior>

<tokenProvider><

windowsAuthentication>

<stsUris><

stsUri value=https://ServerName:9355/ServiceBusDefaultNamespace />

</stsUris></

windowsAuthentication>

</tokenProvider></

transportClientEndpointBehavior>

</behavior></

endpointBehaviors>

</behaviors><

services> <service name="SB.WCF.Subscription.EngagementService">

<endpoint name="EngagementProcessor"

listenUri="sb://ServerName/ServiceBusDefaultNamespace/EngagementTopic/subscriptions/EngagementSub1"

address="sb://ServerName/ServiceBusDefaultNamespace/EngagementTopic"

binding="netMessagingBinding"

bindingConfiguration="messageBinding"

contract="SB.WCF.Subscription.IEngagementService"

behaviorConfiguration="EndpointBehavior"/>

</service></

services>

<bindings><

netMessagingBinding>

<binding name="messageBinding" closeTimeout="00:03:00" openTimeout="00:03:00" receiveTimeout="00:03:00" sendTimeout="00:03:00" sessionIdleTimeout="00:01:00" prefetchCount="1"><

transportSettings batchFlushInterval="00:00:01"></transportSettings>

</binding></

netMessagingBinding>

</bindings><!--

<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />-->

<extensions><!--

In this extension section we are introducing all known service bus extensions. User can remove the ones they don't need. -->

<behaviorExtensions><

add name="transportClientEndpointBehavior" type="Microsoft.ServiceBus.Configuration.TransportClientEndpointBehaviorElement, Microsoft.ServiceBus, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

</behaviorExtensions><

bindingElementExtensions>

<add name="netMessagingTransport" type="Microsoft.ServiceBus.Messaging.Configuration.NetMessagingTransportExtensionElement, Microsoft.ServiceBus, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /></

bindingElementExtensions>

<bindingExtensions><

add name="netMessagingBinding" type="Microsoft.ServiceBus.Messaging.Configuration.NetMessagingBindingCollectionElement, Microsoft.ServiceBus, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

</bindingExtensions></

extensions>

</system.serviceModel><

system.webServer> <modules runAllManagedModulesForAllRequests="true" />

<!--

To browse web app root directory during debugging, set the value below to true.

Set to false before deployment to avoid disclosing web app folder information.

-->

<directoryBrowse enabled="true" /></

system.webServer>

</configuration>

I want to explain two settings from the web.config are the following:

listenUri="sb://ServerName/ServiceBusDefaultNamespace/EngagementTopic/subscriptions/EngagementSub1"

address="sb://ServerName/ServiceBusDefaultNamespace/EngagementTopic"

ListenUri listens to the subscription where address points to the topic where messages are being sent.

There are some ok examples out there but nothing fully complete in my opinion. Must of the samples use Azure Service Bus which is fine, but I wanted to show strictly how to use Windows Service Bus, as a pure on-premise setup. My next post will demonstrate how to send messages to the service created in this post. Fire away if you have any questions.

Currently rated 5.0 by 3 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted by: BayerWhite
Posted on: 4/18/2014 at 2:39 AM
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed

Updating The Password For The Account Windows Service Bus Is Running Under

At the end yesterday's work day,my Service Bus Farm was working as expected, however this morning I was checking messages and they were failing to be sent to the queue. The error I was getting was, "The service did not start due to a logon failure." This particular farm is on the domain, so I have to use VPN to see it, which is one of the potential points of failure. Also, this morning I was informed that my password needed to be changed for the domain, and I did that too, for the second point of failure. My first thought pointed me to a post I did a while back for checking the status of the SB farm, and the power-shell commands for checking that the farm was up and running. All of the services were up and running, however I knew that changing my password caused the issues, next steps were to understand how it could be fixed.

The services were running because I had left the machine running, so I decided to reboot the machine. when I did I found that there were a couple of the services that failed to start up.

When tried to restart the SB host, is when I realized that changing the password was what was causing my issue. Therefore the solution was to go to the services and reset the password for the account that the windows services FabricHost and Service Bus Message Broker are running under.

 

Once the password is updated, the services can be either restarted from the "Services" window or simply by re-issuing the "start-sbhost" power-shell command. Messages will now continue to flow.

Currently rated 5.0 by 2 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted by: BayerWhite
Posted on: 4/17/2014 at 3:12 AM
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed