Neudesic Blogs

PowerShell commands to help configure a development environment

Continuing my PowerShell fetish for another week I thought I’d write about some of the PowerShell commands I have been using to configure my development environments in this article.

The set of commands I run are used to disable a lot of the security features that are great to have in production but do nothing aside from producing headaches in a development environment.  I’ll start with a base installation of Windows Server 2008 R2 Enterprise and then begin to run these scripts.

First we run this command to make sure that we are allowed to run scripts in the PowerShell command window that aren’t signed.

  Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force

Next up is disabling the IE ESC settings.  We do this by updating the registry keys for this property.

  Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A7-37EF-4b3f-8CFC-4F3A74704073}" -Name "IsInstalled" -Value "0"

  Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A8-37EF-4b3f-8CFC-4F3A74704073}" -Name "IsInstalled" -Value "0"

We will also want to disable User Access Control as well so we don’t have to keep remembering to run things as administrator.  Again this is just a registry update.

  Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name "ConsentPromptBehaviorAdmin" -Value "00000000"

Of course we need to disable the shutdown tracker so we don’t have to type “adfs” in a prompt every time Windows is being shut down.  Also a registry change, this time we’re adding a key instead of modifying an existing one but it’s essentially the same process.

  New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT" -Name "Reliability" -Type "RegistryKey"

  New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Reliability" -Name "ShutdownReasonOn" -Value "0" -PropertyType dword

This one is to disable the loopback check.  If you’re not familiar with the problem, it is caused when attempting to authenticate against a site being hosted on the same machine you’re browsing from if the URL is not the same as the computer name.  You’ll be challenged for credentials and no matter what you enter you’ll be prompted 3 times and then denied access.  This is a symptom of a security feature to help prevent certain types of reflection attacks that you probably won’t care about in your development environment so here is the command you can use to turn it off.

  New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Lsa" -Name "DisableLoopbackCheck" -Value "1" -PropertyType dword

  Restart-Computer

To rename my computer to something a little more useful than a randomly generated name I use this command.

  $ComputerName = “MyComputerName”

  $computer = Get-WmiObject Win32_ComputerSystem

  $computer.Rename($ComputerName)

  Restart-Computer

I also tend to need my development box to run as a domain controller.  To promote my server to a DC I use the following command.

  $DNSName = “DEV001.NET”

  $NetBiosName = “DEV001”

  $SafeModeAdminPassword = “pass@word1”

  dcpromo /unattend /ReplicaOrNewDomain:Domain /NewDomain:Forest /NewDomainDNSName:$DNSName /DomainNetBiosName:$NetBiosName /InstallDNS:Yes /RebootOnCompletion:No /SafeModeAdminPassword:$SafeModeAdminPassword

  Restart-Computer

So that is all I’ve got for this article.  I hope this was useful for some of you.

Posted: Mar 14 2012, 05:29 by Michael.Thompson | Comments (2)

9794c9ca-2255-46b2-8a8c-fabe2941d73b|0|.0

Tags: PowerShell, SharePoint, Development
Categories: General | Portals & Collaboration

A PowerShell Script to Restart Computer and Continue Execution

So originally I had set out to write an article about setting up a SharePoint 2010 development environment.  I know it’s been written about ad nauseam but thought it would be a great way to get my feet wet in the blogging world.  Anyway as usual I got myself distracted so this article is not about building a SharePoint 2010 development environment.  It’s about one piece of that puzzle, specifically a simple pattern to automate the executing, restarting, and continuation of a PowerShell script.

So when I started I had one goal.  I wanted to be able to take a fresh installation of Windows Server 2008 R2 and with one click install and configure all of my development tools.  At the time I knew next to nothing about PowerShell but I was pretty sure it was going to be the correct tool.

The first hurdle I had to get over, and the one this article focuses on, was how to get my PowerShell script to restart the box and then continue where it left off.  Some quick searching got me headed in the correct direction.  Basically you can get PowerShell to write to the registry and by doing so you can get it to add itself to the Windows startup routine.  With some clever passing of parameters you have the ability to get the script to start where it left off.  Here’s a stripped down version of the code:

param($global:Step=1)

function Set-NextStep() {

  $global:Step++

  Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" -Name "SystemSetupStep" -Value "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe &C:\Setup.ps1 -Step $global:Step"

}

function Run-NextStep() {

  switch ($global:Step) {

    1 { Step-1; break; }

    2 { Step-2; break; }

    default { Remove-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" -Name "SystemSetupStep" }

  }

}

function Step-1() {

  Write-Host "This is step 1"

  Set-NextStep

  Restart-Computer

}

function Step-2() {

  Write-Host "This is step 2"

  Set-NextStep

  Run-NextStep

}

Run-NextStep

Ok, so let’s break this thing down.  First line is the $Step parameter.  This allows me to pass a value into the script when I call it from the command line or if I omit the parameter it sets itself to 1.

Next is the function Set-NextStep().  It increments the parameter $Step by 1 and then writes some information to the registry.  Specifically it adds an entry that tells Windows to execute a command on startup.  What is that command?  I’m asking it to start the PowerShell command window and to load my script as well as pass in the parameter $Step which would now be one value greater than when I started.

The Run-NextStep() function is simply a switch statement driven by the value of the parameter $Step.  What I really like about this is how well it documents what is actually going on.  It clearly shows you what steps are going to be executed and in what order.  The default behavior of the switch statement is some cleanup of the registry to remove the command that tells Windows to execute the script on startup.

Then I have two sample functions in there.  Step-1() outputs to the command window and then sets the next step before it restarts the computer.  Step-2 outputs to the command window sets the next step and runs the next step.

And that is that.  A simple little pattern to execute multiple functions in PowerShell over as many reboots as you need.  In the future maybe I’ll post my full blow version of this that actually does build a SharePoint 2010 Development box.

Posted: Mar 07 2012, 04:28 by Michael.Thompson | Comments (9)

966e1e15-74f3-4f40-a431-49ebed37dea2|0|.0

Tags: SharePoint, PowerShell
Categories: General | Portals & Collaboration

Neuron ESB 2.5.14 Release Launched!

Stay tuned this channel! Once I finish the “What’s New” and “How to use it” documentation, I’ll post the download link and the docs.

Kind regards,

Marty Wasznicky
Neuron ESB
Neudesic, L.L.C.
Work: (949) 754-5223
Fax: (949) 754-6523
marty.wasznicky@neudesic.com | www.neudesic.com

Posted: Nov 19 2011, 02:28 by marty.wasznicky | Comments (16)

1ec1da4f-9024-456f-87f0-3d32dd86a8fc|0|.0

Tags:
Categories: Neudesic Main | AppFabric | Connected Systems | Custom Application Development | General | Neuron | Neuron ESB | WCF

Neuron ESB 2.5.13 Release Available Now!

I’m very pleased to announce the July Feature release update (version 2.5.13) for Neuron ESB. This can be downloaded here. 

The product team is very excited about this release as it’s contains many new features which our customers will immediately benefit from. This release moves us further in ensuring that developing and deploying Neuron solutions continues to become easier for our customers. This release contains accumulated fixes, documentation updates, as well as incremental, customer requested updates to Neuron ESB:

·         Custom Pipeline Steps – Users will be able to create a reusable custom Pipeline Steps, register them, and use them within the Neuron ESB Pipeline Designer by simple drag and drop.

·         MSMQ Pipeline Step – This will provide users the ability to send messages to a Queue within a pipeline.  It will also support correlated receives from a Queue as well.

·         Pipeline Execution Pipeline Step – Provides the ability to create composite pipelines by executing existing pipelines within a pipeline for easy reuse.

·         Global Pipeline Cache – This will support the creation and initialization of any variable type that can be used across all instances of a pipeline executed by a Neuron Party

·         Custom SOAP Header Support for the Service Pipeline Step

·         Dynamic Transform Pipeline Step – Allows users to determine XSLT to run at runtime, rather than design time

·         Dynamic Schema Pipeline Step – Allows users to determine Schema to validate against at runtime, rather than design time

·         Environmental Variable support for Service/Client Connectors – This was the last step to make deployment truly easy for all customers. This deprecates the use of the Addresses tab located on Deployment Groups.

·         Multi-threaded receive for MSMQ based topics – This provides performance enhancements.

·         MSMQ Time to Live – The ability to set this property at the Topic level

·         WSDL support for Client Connectors - Ability to associate an existing WSDL endpoint with Client connectors so developers can use “add service reference” or “add web reference” within Visual Studio by referencing the client connector configured urls

·         Resubmit – the ability to resubmit a message directly from either the Audit or Failed Message reports.  In the next feature release we’re going to try to introduce bulk resubmit as well as the ability to resubmit to a specific adapter or service endpoint.

·         Reorder Pipelines – The ability to re order pipelines for a party within the UI so that users do not have to remove and then re-add.

·         RFID Sync and Async enhancements – Refactored to increase performance by 10 fold, as well as remove need to modify configuration files and enhanced tracing

·         Scatter Gather Sample – Updated the scatter gather sample and documentation (see attached) to use new Dynamic Transform Pipeline Steps

·         Unique WMI Performance Counters– By default Neuron ESB generates performance counter names for Parties using the Party Name appended by a guid.  Now we provide an option to generate these names by only using the Party name.  This allows predictable use of 3^rd party monitoring tools

Besides new features, this release includes all the accumulated bug fixes from the past few months, since our previous 2.5.10 release in April 2011. Some of these fixes include the following:

·         Performance enhancements for service endpoints

·         Exception propagation for service endpoints to calling clients

·         Several Neuron “Farm Mode” fixes/enhancements were introduced to ensure resilience and reliability. Neuron Farm mode is used to scale out Neuron servers when using TCP based topics in conjunction with  the remote Neuron ESB client API. 

·         Several “DirectConnect” fixes were introduced.  DirectConnect mode is used for routing to service endpoints within a Pipeline, circumventing the Neuron Pub/Sub engine

·         Under certain conditions a service connector’s service policy would fail to execute when the WCF Message could not be created from the Neuron ESB Message.

·         Removed duplicate event log registry entries which were causing event information to be written to the disk file in the Log directory rather than the event log.

·         Code pipeline step no longer uses temp files.

·         Exceptions that occur in a pipeline are now passed back to a requesting client.

·         Removed duplicate failure exceptions being logged in the failed message database

·         Corrected issue where Party name and direction were incorrectly logged or missing in failed message database

·         Corrected issue where the service url in the Service Pipeline Step could being used rather than the metadata url even though the value was empty.

As always, the complete list of changes can be found in the change log (Neuron Change Log) installed at the root of the Neuron ESB installation directory as well as on our support site.

As an addendum to our shipped documentation, I’ll be regularly posting information on how to use the new features, so continue to monitor our blog and forums!

Kind regards,

Marty Wasznicky
Neuron ESB
Neudesic, L.L.C.
Work: (949) 754-5223
Fax: (949) 754-6523
marty.wasznicky@neudesic.com | www.neudesic.com

Posted: Jul 29 2011, 13:00 by marty.wasznicky | Comments (0)

36cf4e67-057b-41c2-adcf-f70cd5f86882|0|.0

Tags:
Categories: AppFabric | Connected Systems | General | Headlines | Neuron | Neuron ESB | WCF

Exploring Azure AppFabric Service Bus V2 May CTP: Queues

As syndicated from http://rickgaribay.net/

Today, the AppFabric team announced the first Community Technology Preview of the Azure AppFabric Service Bus V2.

The second release of Azure AppFabric Service bus is a significant milestone that the team has been hard at work on for several months. While I’ve had the privilege of attending a number of SDRs and watching this release move from ideation to actual bits, this is the first time I’ve been able to actually get my hands on the code, so I’ve spent the better part of this evening diving in.

First, if you are new to the Azure AppFabric Service Bus, there are many resources available to get you up to speed. I highly recommend this whitepaper by Aaron Skonnard: A Developer’s Guide to the Service Bus. If you are a visual learner, please consider checking out my webcast on AppFabric Service Bus here: http://rickgaribay.net/archive/2011/01/12/neudesic-appfabric-webcast-series.aspx.

In a nutshell, like most ESBs, Azure AppFabric Service Bus is the manifestation of a number of core messaging patterns that provide the ability to design messaging solutions that are loosely coupled. What makes the Azure AppFabric Service Bus unique is that it provides these capabilities at “internet scale”, meaning that it is designed to decouple clients and services regardless of whether they are running on premise or in the cloud. As a result, the AppFabric Service Bus is a key technology for enabling hybrid scenarios at the platform level (i.e. PaaS) and serves as a key differentiator in the market today for enabling organizations to adopt cloud computing in a pragmatic way.

Messaging patterns in general provide a common frame on which to think about and build composite applications. Cloud and hybrid computing necessitate many of the same messaging patterns found within the on-premise enterprise and introduce new complexities that are somewhat unique.  Azure AppFabric Service Bus V2 introduces tried and true messaging capabilities such as Queues, Topics, Pipes and Filters (Rules/Actions) as well as sequencing semantics and of course durability.

It is important to note that the Azure AppFabric Service Bus is not a replacement for on-premise publish-subscribe messaging. It enables new scenarios that allow you to integrate your current on-premise messaging and provide the ability to compose clouds, be they your own, your partners or those of private cloud providers such as Microsoft. The drawing on the right is from the Microsoft whitepaper I mentioned in the introduction. Notice that the Azure AppFabric Service Bus is providing the ability to integrate clients and services regardless of where they reside, and for non-trivial SOA, on-premise pub-sub for decoupling composed services and clients is essential.

Queues

Queues are typically used to provide temporal decoupling, which provides support for occasionally connected clients and/or services. With a queue, a client writes to a known endpoint (private/local or public/somewhere on the network) without regard to the state of the downstream service. If the service/consumer is running, it will read work items or messages from the queue. Otherwise, the queue will retain the message(s) until the service is available to retrieve the message or the message expires.

As promised, Azure AppFabric Service Bus V2 delivers on durable messaging capabilities beyond the current Message Buffer feature with the introduction of Queues.

Queues are supported in the .NET API (shown below), REST API and with a new WCF Binding called “ServiceBusMessagingBinding”. While my preferred approach will certainly be WCF, the .NET API helps to understand the new API. In addition, the process of creating a queue is required even with WCF since queue creation is outside of WCF’s immediate area of concern.

The first thing you need to do when working with Queues, Topics and Subscribers is create a Service Bus Namespace Client which is an anchor class for managing Service Bus entities:

ServiceBusNamespaceClient namespaceClient = new  ServiceBusNamespaceClient(ServiceBusEnvironment.CreateServiceUri("sb",  serviceNamespace, string.Empty),  sharedSecretCreds);

Once you have an instance of the ServiceBusNamespaceClient, you can create a queue by simply instantiating the Microsoft.ServiceBus.Messaging.Queue class (I’ve set the queueName field to “Orders”):

  Queue queue = namespaceClient.CreateQueue(queueName);

Next, create a Queue client. The Queue Client manages both send and receive operations:

   1:    MessagingFactory messagingFactory = 
MessagingFactory.Create(ServiceBusEnvironment.CreateServiceUri("sb", serviceNamespace, string.Empty), sharedSecretCreds);

   2:  var queueClient = messagingFactory.CreateQueueClient(queue);

The code above uses the Microsoft.ServiceBus.Messaging.MessagingFactory which accepts your namespace and security credentials and returns an instance of the MessagingFactory.

Next, you create an instance of Microsoft.ServiceBus.Messaging.MessageSender using the CreateSender method:

   1:  var messageSender = queueClient.CreateSender();

   2:  messageSender.Send(msg);

   3:  messageSender.Close();

   1:  Order order = new Order();

   2:  order.OrderId = 42;

   3:  order.Products.Add("Kinect",70.50M);

   4:  order.Products.Add("SamsungFocus", 199.99M);

   5:  order.Total = order.Products["Kinect"] + order.Products["SamsungFocus"];

   6:   

   7:  var msg = BrokeredMessage.CreateMessage(order);

Finally, we can send the message:

   1:  var messageSender = queueClient.CreateSender();

   2:  messageSender.Send(msg);

   3:  messageSender.Close();

With much of the infrastructure code out of the way, we can use the same queueClient instance to create a MessageReciever and request the BrokeredMessage message from the Orders queue:

   1:  var messageReceiver = queueClient.CreateReceiver(ReceiveMode.ReceiveAndDelete);

   2:  var recdMsg = messageReceiver.Receive();

   3:  messageReceiver.Close();

Note the ReceiveMode in line 1 above. This has the effect of enforcing an “Exactly-Once” “At Most Once” (thanks David Ingham) receive semantic since the first consumer to read the message will pop it off the queue. The opposite option is RecieveMode.PeekLock which provides “At Least Once” delivery semantics. As David Ingham, Program Manager on the AppFabric team kindly adds in his comments below: “If the consumer is able to record the MessageIds of messages that it has processed then you can achieve “ExactlyOnce” processing semantics with PeekLock mode too.” –Thanks David!

   1:  var recdOrder = recdMsg.GetBody<Order>();

   2:  Console.WriteLine("Received Order {0} with total of ${1}",recdOrder.OrderId,recdOrder.Total);

The cool thing about the CTP is that Microsoft is offering you a free labs environment in which to explore and play. In the CTP, you can create a maximum of 100 queues, with a maximum size of 100MB each and messages can not exceed a payload size of 256KB- pretty workable constraints for a first CTP.

To get started, and dive in for yourself, be sure to download the Azure AppFabric V2 SDK at: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=D89640FC-C552-446E-AEAD-B1E0D940F31B

In my next post, we’ll explore Topics and Subscriptions which allow for rich pub-sub including the ability to multicast to thousands of potential subscribers.

Hats off to the AppFabric Messaging team for all of their hard work with this release!

Posted: May 17 2011, 08:00 by Rick.Garibay | Comments (0)

3f3b8b8d-b83b-4136-afe1-a46de2e86aeb|0|.0

Tags: AppFabric, WCF, Azure
Categories: AppFabric | Azure | Connected Systems | General | Headlines | WCF

Heading up to Redmond

I’ll be in Redmond most of the week of 7/5 for some meetings at Microsoft about this and that. If you’re in the area drop me a line and we can get together to discuss Azure, ApFabric, or other distributed computing topics. I’ve also got The David Pallmann™ with me in case you need someone intelligent in addition to me.

Posted: Jul 01 2010, 05:26 by mickey.williams | Comments (0)

fdcdab14-f270-4d3f-8ed1-c0d36b4c0c7c|2|4.0

Tags:
Categories: Connected Systems | Custom Application Development | General | Neudesic Main | Azure