How to enable Remote Desktop for your Windows Azure Roles

Wednesday, December 1, 2010

The latest Azure SDK 1.3 makes it possible to login to the VM of your web/worker role instances via Remote desktop. So you are not limited to use VM Role in case you need to establish a RDP connection to your VM.

This helps you to monitor the error events that occur in your events, also you can install small softwares, copy few files etc, though it is recommended to use Startup tasks with elevated privileges i.e. Admin Mode. (Note that once the machine is restarted your softwares will no longer be there, so better use startup tasks)

The steps to enable and configure remote desktop are really simple.

First you will need to install the latest Azure SDK 1.3 tools for Visual Studio. You can just install VSCloudService.exe as it contains SDK as well.

Once done with the installation, create a new Cloud Service project and add a new worker or web role and then foloow the below steps:

1. Go to http://windows.azure.com and create a new Hosted Service. This hosted service will be the one where you will deploy your roles.
2. Create a pfx certiciate and export its private key. If you already have the certificate then upload that certificate to your service else upload the certificate you just created.
3. Then in Visual Studio, Right Click your service and click Publish.





4. In the dialog that appears click “Confiure Remote Desktop connections…”



5. Enable the checkbox for "Enable connections for all roles".
6. Select the same certificate that you uploaded to your service in step 2.
7. Enter username, password and expiration date for the credentials that you need to use for remote desktop log in.



8. Click Ok and Publish.
9. Now go back to the portal, select the instance and click on Connect button at the top.

This is it. You are done You can optionally save the rdp file you get in the last step to your desktop to connect to your instance without going to the portal again.

Active Directory Domain Join of Azure Roles Using Connect

Tuesday, November 16, 2010

We already have seen how Windows Azure connect can help us in connecting our windows azure role instances to our local computers in the previous post. We also saw in the use cases/scenarios for azure connect, that we can domain join our windows azure roles with our on-premise Active Directory, and this is possible by using connect plug-in.

This is a very useful feature provided by Windows Azure Connect. Active Directory Domain Join might help you in following regards:
  1. You can now control access to your azure role instances based on domain accounts.
  2. You can now provide access control using windows authentication along with on-premise SQL server.
  3. In general, as customers migrate existing Line of Business applications to cloud; many of those applications today are written or assume domain joined environment. And with this capability of domain joining your azure roles to on-premise AD, this process of migration can be made simpler.

The process to setup, enable and configure Active Directory Domain Join using connect, involves following steps:

  1. Enable one of your domain controller/DNS servers for connectivity by installing Windows Azure Connect Agent on that machine.
    Many customers with multiple Domain Controller environment, will have many DCs. For such scenario it is recommended to create a dedicated AD site to be used for domain joining of your azure roles.
  2. Configure your Windows Azure connect plug-in to automatically domain join your azure role instances to active directory. For domain joining there are specific settings to be done in Service Configuration file (.cscfg )
    – credentials (domain account that has permission to domain join these new instances coming online)
    - target organizational unit (OU) for where your azure role instances SHOULD be located within your AD
    - you can specify list of domain users or groups that will automatically be added to local admin groups for your azure role.
  3. Configure your network policy. This will specify which roles will connect to what Active Directory servers. This is done from admin portal.
  4. New Windows Azure Role instances will automatically be domain-joined

Guide to Windows Azure Connect

Monday, November 15, 2010

Building applications for cloud and hosting them on cloud is one of the great things that happened in recent times. However, you might be having number of existing applications that you wish to migrate to cloud, but you do not want to move your database server to the cloud. Or you want to create a new application and host it in the cloud, but this new application needs to communicate with your existing on-premise applications hosted in your enterprise's network. Other case might be that your new application that you wish to host in cloud will rely for its authentication on your enterprise's Active Directory.

What options do you have? You can think of re-writing your on-premise applications for azure and then host them in azure, or in case of Database servers, you can move your DB servers to SQL Azure in cloud. But you have other easier option too, that has been announced in PDC10 and which will be released by the end of this year. What we are talking about is Windows Azure Connect.

Later in this post we will talk about How to setup windows azure connect and Azure Connect Use Cases & Scenarios. But first let's go through what connect is and why do we need it.



What is Windows Azure Connect

Windows Azure Connect provides secure network connectivity between your on-premises environments and Windows Azure through standard IP protocols such as TCP and UDP. Connect provides IP-level connectivity between a Windows Azure application and machines running outside the Microsoft cloud.

Figure 1: Windows Azure Connect



This combination can be of different scenarios, which we will see later in the section of Use Case and Scenarios.
In first CTP release we can access Azure resources by installing connect agent on the non-azure resources. The upcoming release will support Windows Server 2008 R2, Windows Server 2008, Windows 7, Windows Vista SP1, and up. A point to be noted here is that this isn’t a full-fledged virtual private network (VPN). However, future plans are to extend current functionality which will enable connectivity using your already existing on premise VPN devices that you use within your organization today.

Setup Azure Connect

Windows Azure Connect is a simple solution. Setting it up doesn’t require contacting your network administrator. All that’s required is the ability to install the endpoint agent on the local machine. Process for setting up Azure Connect involves 3 steps:

1. Enable Windows Azure Roles for external connectivity. This is done using service model.
2. Enable your on-premise/local computers for connectivity by installing windows azure connect agent.
3. Manage Network Policy through Windows Azure Portal.

Final step is to configure and define network policy. This defines which WA roles and local computers that you have enabled for connect are able to communicate with each other. This is done using WA admin portal. It provides very granular level of control.

1. Enable Windows Azure Roles for external connectivity

To use Connect with a Windows Azure service, we need to enable one or more of its Roles. These roles can be Web/worker role or a new role Vm Role announced at PDC10.
For web/worker role, the only thing we need to do is to add an entry in your .csdef. You simply add a line of xml in your .csdef specifying to import or include windows connect plugin. Then, you need to specify your ActivationToken in ServiceConfiguration (.cscfg) file. ActivationToken is a unique per-subscription token, which means if you have two different Azure subscriptions then you will have individual Activation Token for each subscription. This token is direclty accessed from Admin UI.

For VM role, install the Connect Agent in VHD image using the Connect VM install package. This package is available through Windows Azure Admin Portal and it contains the ActivationToken within itself.

Also, in our .cscfg file you can specify optional settings for managing AD domain-join and service availability.

Once these configuration are done for a role, connect agent will automatically be deployed for each new role instance that starts up. This means, if tomorrow, for example, you add more instances to the roles then each new instances will automatilcally be provisioned to use Azure Connect.

2. Enable your on-premise/local computers for connectivity

Your Local on-premise computers are enabled for connectivity with Azure Services by installing & activating the Connect agent. The connect agent can be installed to your local computers in two ways:
1. Web-based installation: From your Windows Azure Admin portal you get a web-based installation link. This link is per-subscription basis and it has the activation token embedded within the URL.
2. Standalone install package: Other option you have is to use standalone installation package. You can run this installation package using any standard software distribution tool installed in your system, as you do it for other programs. It will add activation token into registry and read its value from there.

Once Connect agent is installed, you will also have a client UI on your system as well as connect agent tray icon in your system tray. Connect agent tray icon & client UI let you view the current status, both the activation status as well as network connectivity status, of azure connect agent. Also it provides basic tasks such as network refresh policy.

Connect agent automatically manages network connectivity between your local computers and Azure services/apps. To do this it does several things including:

  • Setting up virtual network adapter
  • “Auto-connects” to Connect relay service as needed
  • Configures IPSec policy based on network policy
  • Enables DNS name resolution
  • Automatically syncs latest network policies


3. Manage Network Policy

Once you have identified your Azure Roles that need to connect to on-premise comouters, and also you have installed and actiated Connect Agents on your local computers, you need to configure which roles connect to which of the configured local computers. To do this we specify Network Policy and it is managed through Windows Azure admin portal. Again, this is done on a per-subscription basis.

Management model for connect is pretty simple. There are 3 different type of operations you can do:

1. You can take your local computers, that have been enabled and activated for Windows Azure Connect by installing connect agents on them, and organize them into groups. e.g. you might create a group that contain your SQL Server computers that one of your azure role needs to connect to, and call this "SQL Server Group". Or you might put all you developer laptops into My Laptops group or you might put computers related to a given project into a group. However, there are two constraints - first, a computer can only belong to a single group at a time and second, when you have a new computer where you just installed Windows Azure Connect agent on, the newly activated computer is unassigned by default meaning it doesn’t belong to any group, and therefore they wont have connectivity.

Figure 2: Connect Groups and Hosted Relay

As shown in the Figure 2 above, we can have groups of local Development machines, and call this group “Development Computers” and our Windows Azure Role – “Role A” will connect to this group. Similarly, we can have a group of our DB servers and name this group as “Database Servers” and have our Role B connect to this group. All these configurations will be done from Azure Admin Portal.

2. Windows Azure roles can be connected to the group of these local computers from admin UI. It is done for all of the instances that make up that azure role and all the local computers in that group. One thing to note is that WINDOWS AZURE CONNECT DOES NOT CONTROL CONNECTIVITY WITHIN AZURE. In other words you can’t use WA connect to connect between two roles which are part of a service or two instances that are part of the same role. The reason for this there are already existing mechanisms for doing this. WA connect is all about connecting azure roles to computers outside of azure.

3. Additionally, it has the ability of connecting group of local computers to other groups of local computers. This enables network connectivity between computers in each of these groups. Additionally, we can have interconnectivity for a given group. This allows all computers within that group to have connectivity with each other. This functionality is useful in ad-hoc or roaming scenarios e.g. if you like to have your developer laptop to have a secure connectivity back to a server that resides in your corporate network.

Networking Behavior

Once you have defined network policy , Azure connect service will automatically setup secure IP level network connection between all of those role instances that you enabled for connectivity and local computers, based upon the network policy you specified.

All of the traffic is tunneled through Hosted relay service. This ensures Windows Azure Connect will allow you to connect to resources regardless of firewalls and NAT configuration of the environment they are residing in. Your Azure Role Instances and your local computers, all will have, through WA Connect, secure IP level connectivity. This connectivity holder is established regardless of the physical network topology of those resources. Due to any firewalls or NATS, many local computers might not have direct public IP addresses. But using Windows Azure Connect you can establish connectivity through all of those firewalls and NATs, as long as those machines have outbound HTTPS access to the hosted relay service.

Figure 2 above shows how local on-premise computers are connected to web role instances through Hosted Relay Service.

Other point to note here is that network connectivity that Windows Azure Connect establishes is secured fully in an end to end fashion using IPSec, and Azure Connect agent takes care of setting this up automatically.

Each connected machine has a routable IPv6 address. Important point to note is even being part of Windows Azure Connect network, any of your existing network behavior remains unchanged. Connect doesn't alter the behavior of you existing network configuration. It just joins you to an additional network with connect.

Once the network connectivity is established, applications running either in azure or on local system will be able to resolve the names to IP address using DNS name resolutions that connect provides.

Use Cases/Scenarios

Let's go through few of the scenarios where Windows Azure Connect might be our solution:

1. Enterprise app migrated to Windows Azure that requires access to on-premise SQL Server. This is most widely seen scenario. You have your on-premise application which connects to your on-premise database server. Now you are willing to move your application to Azure, but due to some business reasons the database this application uses needs to stay on premises. Using Windows Azure connect, the web role, converted from on-premise ASP.NET application, can access the on-premises database directly. The wonderful thing here is that it does not even require to change the connection string, as both web-role and database server are in the same network.

2. Domain-joined to the on-premises environment. This scenario opens up various other use cases. One such case is letting the application use existing Active Directory accounts and groups for access control to your Azure application. Theefore, you should not be bothered about exposing your AD to internet to provide access control in cloud. Using Windows Azure Connect your azure services/apps are domain joined with your Active Directory domain. This enables to control who can access azure services based on your existing windows user or group accounts.

Also, domain-joining allows single sign-on to the cloud application by on-premises users, or it can allow your azure services to connect to on-premise SQL server using Windows Integrated Authentication.

We will see in a seperate post How to Domain Join Azure Roles with Active Directory using Connect.

3. Since you have direct connectivity to VMs running in cloud, you can remotely administer and trouble-shoot your Windows Azure Roles

Cap your SQL Azure Database Automatically: Limit the Size

Tuesday, October 26, 2010

You might already be aware that you can set an upper limit for your SQL Azure Database. This way we can specify that your database size should not grow beyond this upper limit, to avoid being billed without your knowledge. Not only this you will not be billed based on your cap size, rather you will be billed on the basis of the storage you are currently using. You will be charged for the range within which your database size lies.

What i mean by this is, we have different ranges in SQL Azure on which we are billed : e.g. For the web edition those ranges are 0-1 Gigabytes, and 1-5 Gigabytes. These are different for Business Editions.

So, suppose you specify your cap size to be 5 Gigabytes, and you are currently using around 0.6 Gigabytes of storage. Then you will be charged based on the range 0-1 Gigabytes. However, when your database size increases, say above 1 Gigabytes, your database grows automatically till the cap size. This time you will be billed for the range 1-5 Gigabytes. The database will stop growing automaticaly when it reaches the cap size you specified.

Once cap-size is reachedand you try to use more storage you will get error 40544, the error message is:
“Msg 40544, Level 20, State 5, Line 1
The database has reached its size quota. Partition or delete data, drop indexes, or consult the documentation for possible resolutions. “

This excpetion can be caught in your C# code based on the Exception number of 40544.

One limitation to auto growth is that SQL Azure currently will not let you switch between web edition and business edition. To automaticaaly change the cap-size based on growth and to switch from Web Edition to Business Edition some code is required.

To implement this we must catch the excpetion 40544 and write a logic to automatically switch the edition or increase the cap. What may be useful here will be following queries:

Knowing Current Cap of your Database
SELECT DATABASEPROPERTYEX ('yourDataBaseName' , 'MaxSizeInBytes' )

Current Size of your Database
SELECT SUM(reserved_page_count) * 8192
FROM sys.dm_db_partition_stats

Increase Cap Size and Switch Edition
ALTER DATABASE AdventureWorksLTAZ2008R2 MODIFY (EDITION='BUSINESS', MAXSIZE=10GB)

To get more idea on this see SQL Azure Team Blog

HTTP Error Code: 400 Message: No tenant signing key of type X509 certificate is provisioned.

Tuesday, October 5, 2010

After the September release if you are configuring your service namespace as per old method you might get following error:

HTTP Error Code: 400
Message: No tenant signing key of type X509 certificate is provisioned.
Trace ID: 2c46fa55-8ae8-443b-9f8a-ab885593c3fb
Timestamp

This is caused because your token signing certificate is not configured properly. In order for Federation Metadata to work, this signing certificate should be configured for Service Namespace.

You have to do this by selecting the value in "Used For" set to "Service namespace". To perform this under your Service Namespace, select 'Certificate and Keys' and then in "Token signing Key/Certificate" under Used for select "Service namespace". This will solve the issue.


No tenant signing key of type X509 certificate is provisioned

 

Access Control Service will use a Service Namespace certificate or key to sign tokens if none are present for a specific relying party application. Service Namespace certificates are also used to sign WS-Federation metadata.

For SAML tokens, ACS uses an X.509 certificate to sign the token. ACS will use a relying party's certificate, if the relying party has its own certificate. Otherwise, the service namespace certificate is used as a fallback. If there isn't one, an error is shown.

The Appfabric ACS needs a service namespace certificate configured in order to sign Fed metadata. Without this, the Fed metadata cannot be signed and attempting to view it will fail.

What is Relying Party (RP)

Wednesday, September 22, 2010

An application that accepts tokens from an STS is called as a Relying Party (or RP). In modern scenarios, web applications use WIF and accept tokens from an STS to manage authentications process.

These tokens acts a proof that user has been authenticated by our application. Thus, our application relies on an external service i.e. an STS to provide Access Control and thus our application is termed as a Relying Party.

More Explanation about Security Token Service.

What are Claims

The security tokens generated by STS contain various attributes based on which a grant/deny access is provided or based on which user experience is customized. These attributes are called as Claims.

A claim can be a user name, user’s email, it can even be permissions such as canWrite, canRead etc or it can be roles or groups to which the user belongs. When an STS generates a token, it embeds the claims within it; therefore, once a token has been issued the values of these claims cannot be tampered with.

If our application trusts the STS that issued this token, it uses the claims issues by the token to describe the user, thus eliminating the need to look up user attributes to provide authorization and customization.

What is Security Token Service (STS)

Traditionally, access control was implemented within the main application by writing a code against user’s credentials to authenticate them and based on their attributes grant/deny access to various resources. This required application developers to be skilled in implementing security and writing a code which is hard to implement and maintain.

Due to Windows Identity Foundation (WIF) all this has changed and it made the things much easier. WIF externalizes authentication and thus application designers can focus only on implementing Business Logic. So, instead of implementing authentication in our application, we use an external system to provide authentication. This system is nothing but a service, which generates secure tokens and transmits those using standard protocols such as SOAP. This service is known as Security Token Service or STS.

Our application is configured to accept these tokens generated by STS. These tokens act as the proof of authentication of a user and hence there is no need for our application to manage these credentials. In this case, our application acts as a Relying Party.

The tokens generated by STS also provide attributes of these users which can be used to prevent access to resources and customize user experience. These attributes are called as Claims.


Get this great book for more clarifications directly from master of WIF, Vittorio Bertocci

AppFabric ACS Exception: A potentially dangerous Request.Form value was detected from the client (wresult="<t:RequestSecurityTo...")

Monday, September 20, 2010

AppFabric ACS Exception : A potentially dangerous Request.Form value was

When you are working with AppFabric ACS labs and implement identity providers such as Windows Livefollowing error might show up when you try to run your application

A potentially dangerous Request.Form value was detected from the client (wresult="<t:RequestSecurityTo...").

This error occurs because ACS sends you a SAML in a POST request, as the wresult value token. ASP.NET considers this as if a user typed some XML content in a textbox called "wresult" which is considered to be unsafe by ASP.NET. ASP.NET considers this kind of values as potentially dangerous, as some kind of script injection.

Therefore, if in your application Request Validation is enables this exception is thrown.

As a solution, you need to add ValidateRequest="false" in your page or in you web.config. This is a required step in case you want to integrate AppFabric ACS.

AppFabric ACS September release is announced

Well, i was just over with integrating AppFabric ACS with windows azure cloud app, using the August release, and now i hear that September release is out.

September release of AppFabric ACS contains incremental updates including support for OAUth 2.0 Web Server, additional support fpr X.509 certificates, ability to upload WS-Fed metadat through portal, expanded support for machine keys.

You can read the announcement at Windows Azure blog. Documentation and updated samples are avaialble on CodePlex project: http://acs.codeplex.com.

Hosted first AppFabric ACS Labs integrated App on Azure

Wednesday, September 15, 2010

After all initial hiccups and with the help of MSDN forums and Justin Smith and Vittorio Bertocci's Blogs i have been able to integrate my web role with AppFabric ACS Labs.

What i implemented is just Single Sign On with Windows Live ID. Yes, only one Identity Provider, though i could have opted for Facebook Connect, Google and Yahoo too.

My next target is to implement ADFSv2 with Appfabric ACS and put it into cloud. Will update how i was able to do that soon.

What is Passive Federation

When i started working with ACS on Appfabric I kept on encountering various terminologies, one of them was Passive Federation and it was widely used. I could understand the term Federation but passive was not clear to me ever.

So, I did some research and finally got an answer by Vittorio at Vibro.net .

The term Passive refers to all those requests that are made by a requestor which is not capable of producing proper SOAP request, for example Web Clients. This means all Web clients are Passive Requestor. Passive Federation emulates WS-Trust on top of GET, POST and cookies. This involves multiple redirects involving browser, resources, requestor and cookies. Check the diagram by Vittorio for details.

At Present whenever someone refers to WS-Federation it simply means Passive Federation, as Active requestors are capable of handling WS-Trust directly.

So now if we are implementing Windows Live ID single sign on in a our application, may be by using Appfabric ACS Labs we essentially mean Passive Federation. I will be shortly talking about my experiences with AppFabric ACS Labs.

Lock held by distributed in doubt transactions for some transaction id

Friday, August 13, 2010

If you will get an error like this "locked held by distributed in doubt transactions for some transaction id". Please follow the following steps to recover from locking.

  • Try to find out the locked transaction id from the server error logs.
  • Execute select * from dba_2pc_pending in DB console. You should be able to see the particular locked transaction Id under "local_tran_id" column, and "state" for this should be PREPARED in dba_2pc_pending table.
  • Login to the database as sysdba. Execute the following command - sqlplus './as sysdba' rollback force "locked transaction id" Now if you will check dba_2pc_pending table again, the "state" should be changed to FORCED ROLLBACK for the transaction id.
  • Now you should not get the above error any more. You can also execute commit force "locked transaction id" to avoid this error.

Microsoft Windows 7 PC better than MAC

Wednesday, August 11, 2010


Windows 7 powered PC is better than Mac. I agree with this new campaign that Microsoft has started. Microsoft added a new section to their Windows 7 site titled "PC vs Mac".

It's the first time i have seen Microsoft going this way of directly marking their products as better than those of their competitors.  Apple has been doing this for past 4-5 years in more than 60 campaigns targeting "Get a Mac".

Well, now when i see what Microsoft has mentioned as comparison i am in total agreement of what they have to say, especially when it comes to most popular Games not available for Mac and the entertainment options that Microsoft has.

I know number of people who buy MAC just to show off that they are different from other or to show off that they are gadget freaks as they can afford a MAC. However, in their hearts they know how good their so called gadget is.

Following are the points, directly from Windows 7 PC vs Mac page, that I believe are correct:


HAVING FUN: Macs might spoil your fun.

There are some things you simply can't do out of the box with a Mac like watch, pause, rewind, and record TV like a DVR.

It's showtime.
You can't get a Mac that ships with a Blu-ray player, TV tuner, Memory Stick reader, or built-in 3G wireless. You can with PCs running Windows 7.

Game on!
Most of the world's most popular computer games aren't available for Macs. And Macs can't connect to an Xbox 360. PCs are ready to play.

Direct TV connection.
Most Macs can't hook up to your TV unless you buy a converter dongle. Many PCs running Windows 7 are designed to connect directly to TVs, so you can watch movies and see photos on the big screen.

WORKING HARD: Macs don't work as well at work or at school.


If most of the computers in your office or school run Windows you may find it harder to get things done with a Mac.


Sharing documents and spreadsheets.

If you use Apple's productivity suite, sharing files with PC users can be tricky. Your documents might not look right and your spreadsheets might not calculate correctly.

Giving presentations.

You'll have to buy a separate hardware dongle to plug your Mac into a standard VGA projector. Most PCs with Windows 7 hook up easily.

Protecting your drives.

On a Mac, out of the box, you can only encrypt your home folder. With Windows 7 Ultimate, you can encrypt your entire hard drive and even USB drives. So your stuff can be safer wherever you go.

SHARING: Macs don't like to share.

At least half the fun of having a computer is sharing the stuff that matters to you with other people. This is harder to do on a Mac.

Securely share your movies, music, and photos.

With a Mac, it's harder to set up secure sharing for your photos, music & movies, documents, and even printers with other computers on your home network. With HomeGroup, it's easy to connect all the computers in your house running Windows 7.

It's easy with a PC.

On a Mac, you have to manually set up photo sharing, manually set up music and movie sharing, manually set up file sharing, and manually set up printer sharing. It's easy to automatically and securely network with all the computers in your house when they're running Windows 7.

CHOICE: Macs don't let you choose.

PCs give you a lot more choice and capabilities for your money. You can get the PC you want, in the size and color you want, with the features you want. You just don't have as many options with a Mac.

Loaded with features.

You can't get a Mac with a Blu-ray player, TV tuner, Memory Stick reader, or built-in 3G wireless. PCs running Windows 7 often come with features that aren't available on even the highest end Macs, including Blu-ray, eSATA, multi-format card readers, Touch, and mobile broadband.

Available in your favorite color.

Macs only come in white or silver. PCs are available in a full spectrum of colors across a range of price points.

More digital media.

With PCs running Windows 7, you can play the videos and music stored on your home PC while you're on the go, for free. Apple charges $99/year for its online service.

BEA-010061 Error in deploying MDB in weblogic 10

Tuesday, July 20, 2010

Error Details:
<EJB> <BEA-010061> <The Message-Driven EJB: testingMDB is unable to connect to the JMS destination: Queue_use1. The Error was: Cannot get destination information. The destination JNDI name is Queue_use1, the provider URL is null>

It was showing “Not connected” in weblogic user interface also.
Platform Details: Developing a Message driven bean in eclipse 3.4.2 and deployed in weblogic 10

Solution:
While creating the MDB in eclipse 3.4.2, it was found that there is no annotation regarding the queue name details. So, you need to add one more annotation “mappedName”. See below for more details. The “mappedName” should be the JNDI name of the queue.

@MessageDriven(mappedName = "Qmdb.use.request",
activationConfig = { @ActivationConfigProperty(
propertyName = "destinationType", propertyValue = "javax.jms.Queue") })


Testing:
Check the weblogic console, if the MDB is successfully deployed, you will be able to see the following

Weblogic BEA-010061 Error Cannot get destination information

Restricting access to pages such as AllItems.aspx, EditForm.aspx in MOSS

Friday, March 19, 2010

In Moss 2007 we have the pages such as AllItems.aspx which are used to view the contents of a List or a document Library. Similary, the page AllForms.aspx is used to view all the Forms in a Forms Library. So as we have other pages Editform.aspx, DispForm.aspx.

Now if you have enabled anonynmous access on your system, then these forms are viewable for all the users, no matter if they are registered users or not, by simply typing the url.

However, these pages should be viewable only for the Admin users. So what's the trick?

One way is to go to each of these forms and add server side code blocks to check if the current user is Admin or not and depending on that redirect them to home page or may be login page in case of anonymous users. That's what i did initiall, but later found out an easy out-of-the-box solution available with Sharepoint 2007.

This issue is resolved using the feature called ViewFormsPagesLockdown Feature. This lockdown feature is enabled using the stsadm command as below:

stsadm.exe –o activatefeature –url -filename ViewFormPagesLockdown\feature.xml


You may have to first switch to the bin directory containing stsadm.exe and then change the text with your site collection's URL. Also, you may have to give the full path for the feature ViewFormPagesLockdown\feature.xml.

After you run this command, disable the anonymous access and enable it back again.

In case you want to go deep into this feature then follow this MSDN Blog Post.

VSTS: Failed to queue test run Error : Unable to find assembly Smartdevice

Tuesday, March 2, 2010

During my stint with Load Tests in Visual Studio Team System, I was able to successfully run my Load Test, but after i configured the Rig and edited the configuration file i started getting following error whenever i ran the test.

Failed to queue test run Unable to find assembly 'Microsoft.VisualStudio.SmartDevice.TestHostAdapter

After trying various things i finally found out it has to do with the Hosts entry in the configuration file. There exists an entry for Smart Device under Hosts section in the local configuration file.

To solve this issue follow the following steps:

  1. In Solution Explorer, under Solution Items, right-click the test run configuration file (file with extension .testrunconfig) and then click Open With.
  2. Choose a program to open the file, such as XML Editor, and then click OK.
  3. Remove or comment the following entry (marked in red) for Smart Device under Hosts section


<hosts>
<devicehostrunconfigdata name="Smart Device" deviceid="AE1FD546-ECB8-4553-B0AA-53E129544859" devicename="Pocket PC 2003 Device" platformid="3C41C503-53EF-4c2a-8DD4-A8217CAD115E" platformname="Pocket PC 2003" uiplatformid="00000000-0000-0000-0000-000000000000"></devicehostrunconfigdata>
</hosts>

Followers

 

2009 ·Techy Freak by TNB