For my particular issue, right clicking on IE and running it as an administrator solved the immediate issue, I was up and running, able to create Virtual Machines and reconnect previous ones -- but that is only part of the story. You might want to follow the steps presented in the blog entry listed below as well, most people know about changing the IE 7 settings on their credentials, however the Virtual Server setting is a little less known.

From the blog:

When you are running Windows Vista, you have the added complexity of having to run the Administration Website in Internet Explorer as administrator when User Account Control (UAC) is enabled. If you are running in an isolated test environment, you can avoid this additional step by disabling UAC. Otherwise, follow these steps to grant your user account full administrative privilege in Virtual Server and eliminate the need for UAC:

• Right-click the Internet Explorer icon in the Quick Launch section of the task bar, and choose Run As Administrator from the menu.
• In the User Access Control dialog box, click Allow.
• In the Internet Explorer address bar, type in the URL to the Administration Website.
• In the Virtual Server navigation menu, click Server Properties.
• Missing Step for VS 2005 R2: Click Virtual Server Security link located in content pane
• Click the Add Entry button.
• In the new Permission Entry, type in your account name in the User Or Group text box.
• In Permissions, select the Full check box to give your account full control.
• Click OK.

Full Blog post:

http://vscommunity.com/blogs/virtualzone/archive/2007/11/28/virtual-server-2005-r2-common-issues-and-tips-always-prompted-for-credentials.aspx

Recently a package of mine with a good running history suddenly started throwing errors. This package had been scheduled and running just fine for over a month – no changes to the code had been made. The error is consistently thus:

The script threw an exception: A deadlock was detected while trying to lock variables MyVariables for read access and variables MyVariables for read/write access. A lock cannot be acquired after 16 attempts. The locks timed out.Task MyTask failed.

Luckily, I am not the only one who has run into this issue, and it has now inspired a new practice for me in designing Script Tasks inside my SSIS packages. Previously in one of my posts, I had shown the following screenshot and described the standard method for using read only and read/write variables in a script task:

For many situations, this will probably work out just fine. However, my variable locking issue has evolved from my use of a Foreach container that holds my Script Task. There are other examples in my package store not involving a Foreach that also throw this error, however all of my packages that consistently throw this error all have in common the use of a Script Task inside a repeated process – for some reason, SSIS is not properly releasing the variables between runs of the step.

Daniel Read has written a detailed method on how to work around this; you may find his post here: http://www.developerdotstar.com/community/node/512/

I was reading the July 2007 MSDN Data Points column when I was reminded of a product I had once been looking for, and, if not found, wanted to develop. The article gives an overview of the new ADO.NET Entity Framework and how it abstracts the logical data schema, which reminded me of a project a friend and I had started at one of my previous workplaces.

Essentially, we were driving at building a metadata system that treated data as an abstract entity, and from there you worked down the train building relationships to how that entity actually was described, for example, in a database or even a raw text file. The idea was that a business person could use the tool to create and describe an entity, create abstractions such as metrics, and that the middle tier of it would tie the abstract entity to the potential sources of this data – even if several layers exist (for example, you might have an employee datamart that already contains described entities that have been pulled from several sources).

This could have many uses: build requirements for your warehouse or reporting data marts, use as a dependency mapping tool between entities that need to be tracked to how they are versioned, either at an application level or database level, building an ETL process, mapping data that you need to capture to meet business needs, etc. – just a small list of how it could potentially be used.  The power would be the collaboration points between the business and the I/T groups that manage and maintain the data; imagine a business user taking this tool and mapping out key information entities that are drivers in strategy discussions, and an I/T person being able to enter the same framework to either help map out an existing answer or using it as requirements for a new or revised process. Hopefully there is something like this and I haven’t found it yet…

Reference for your interest:

http://msdn.microsoft.com/msdnmag/issues/07/07/DataPoints/default.aspx

DDL Triggers are a new feature in SQL 2005; where the use of DML triggers have been common in imposing a simple data audit strategy, you can now use DDL triggers successfully as a means for schema and object auditing. As you can image, implementing such a solution can be immensely useful in a development project. 

Another feature in SQL 2005 that assist this solution is the EVENTDATA() function. This function only returns data when used inside of a DDL Trigger; scope for what the EVENTDATA function returns is set when you create the trigger. It is important to know what scope of events you want to track as it determines the content of the XML returned when the EVENTDATA function is called. You can find out more from BOL here: http://technet.microsoft.com/en-us/library/ms186438.aspx:

In this example, I am concerned mostly with capturing event data on events in the DDL_TABLE_VIEW_EVENTS and DDL_PROCEDURE_EVENTS scope.  

Since DDL_TABLE_VIEW_EVENTS and DDL_PROCEDURE_EVENTS both inherit from DDL_DATABASE_LEVEL_EVENTS, they share these base properties: SQLInstance, LoginName, PostTime, SPID,  ComputerName (according to BOL, however in practice I have not seen this returned in the XML schema in ALTER_TABLE and other similar events), UserName, and DatabaseName. 

DDL_TABLE_VIEW_EVENTS adds the following properties: SchemaName, TSQLCommand, ObjectType with DDL_PROCEDURE_EVENTS having the same plus ObjectName.  DDL_TABLE_VIEW_EVENTS does not have the ObjectName within its scope due to the child event scope that captures Statistics events – since the stat are really against an object, they carry the TargetObjectType and TargetObjectName properties.   

I go into all of this because it determines how you would design your DDL logging table. You might choose to build a different table for every event scope you are attempting to log, or choose to build one table for every event. Either way, knowing the DDL Events and what information each scope returns is important for your design in both the table and your trigger. In this example, since I am going to capture information within the scope of DDL_TABLE_VIEW_EVENTS and DDL_PROCEDURE_EVENTS, my table design will be as follows; be sure to create this table before you run the script for the trigger: 

CREATE TABLE [dbo].[DDLEvents](     

[DDLEventKey] [int] IDENTITY(1,1) NOT NULL,     

[EventLoginName] [varchar](50),     

[EventUserName] [varchar](50),     

[EventPostTime] [datetime],     

[EventDatabaseName] [nvarchar](50),     

[EventObjectSchemaName] [varchar](50) NULL,     

[EventObjectName] [varchar](250) NULL,     

[EventObjectType] [varchar](50) NULL,     

[EventType] [varchar](50) NULL,     

[EventTargetObjectType] [varchar](50) NULL,     

[EventTargetObjectName] [varchar](250) NULL,     

[SPID] [int],     

[TSQLCommand] [varchar](max) NULL

) ON [PRIMARY]  

The script to create the trigger: 

create trigger [DDL_Logger]on Database

for DDL_TABLE_VIEW_EVENTS, DDL_PROCEDURE_EVENTS

as

declare @eventdata XMLset @eventdata = eventdata()

insert into dbo.DDLEvents     

( EventLoginName, EventUserName, EventPostTime, EventDatabaseName      , EventObjectSchemaName, EventObjectName, EventObjectType, EventType      , EventTargetObjectType, EventTargetObjectName, SPID, TSQLCommand)

values     

( @eventdata.value('(/EVENT_INSTANCE/LoginName)[1]','varchar(50)')     

, @eventdata.value('(/EVENT_INSTANCE/UserName)[1]','varchar(50)')     

, @eventdata.value('(/EVENT_INSTANCE/PostTime)[1]','datetime')     

, @eventdata.value('(/EVENT_INSTANCE/DatabaseName)[1]','varchar(50)')     

, @eventdata.value('(/EVENT_INSTANCE/SchemaName)[1]','varchar(50)')     

, @eventdata.value('(/EVENT_INSTANCE/ObjectName)[1]','varchar(250)')     

, @eventdata.value('(/EVENT_INSTANCE/ObjectType)[1]','varchar(50)')     

, @eventdata.value('(/EVENT_INSTANCE/EventType)[1]','varchar(50)')     

, @eventdata.value('(/EVENT_INSTANCE/TargetObjectType)[1]','varchar(50)')     

, @eventdata.value('(/EVENT_INSTANCE/TargetObjectName)[1]','varchar(250)')     

, @eventdata.value('(/EVENT_INSTANCE/SPID)[1]','nvarchar(100)')     

, @eventdata.value('(/EVENT_INSTANCE/TSQLCommand)[1]','nvarchar(max)')           

)

GO

SET ANSI_NULLS OFF

GO

SET QUOTED_IDENTIFIER OFF

GO

ENABLE TRIGGER [DDL_Logger] ON DATABASE 

To test, all you need to do is create, alter or delete a table, view or stored procedure in the database you created the DDL Trigger in.

With this implemented, you now have basic auditing for your system – by no means comprehensive and should not replace a true versioning system, but it is a handy fallback should you be unable to acquire such a product or as a supplement to an enteprise versioning system. 

Additional links: 

Using the XML value method: http://technet.microsoft.com/en-us/library/ms178030.aspx