When running SharePoint solution deployment through a remote shell, solution deployment hangs - sharepoint

I have a remote shell (using PowerShell) running a solution deployment on SharePoint 2010. It hangs on the deployment and never finishes deploying. When I do this locally from the box, there are no issues deploying.
I thought originally that this could have to do with paging due to the remote shell memory limit (which is, by default, 512MB). I increased that to 2 GB:
Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 2048
This hasn't made any difference. I also ensure that the SharePoint Administration and Timer Service are started before attempting to deploy. Also, the credentials I have used to open the remote shell are for the farm account.
What would cause a solution deployment to hang only when run through a remote shell?

I attempted the same thing recently and found that remote shells have a limited amount of access to the remote environment depending on the credential provider used. Security policies inhibit some IO operations with the file system, etc. I was able to work around this leveraging a package management solution such as Chocolatey.org, which can kick off powershell commands in another process on the remote box, but from what I understand of the issue, it's a Double Hop credential problem that can be solved using CredSSP when establishing the remote connection.

Related

Executable to launch an Azure Virtual Machine

I need to create tools so that a non-experienced/non-technical users can use (which means connect and start/stop) a Virtual machine on Azure. For connection, the RDP connection is doing a good enough job and is easy to take a hand-on. On the other side, to start / stop a virtual machine you normally need to access to the Azure portal which (on top of being not straightforward for a non-technical user) causes some access policy problems. One option could be to just let the virtual machine always "on" but then we are billed for 100% of time even though the user only needs it for a couple hours a week.
That's why I investigated the possibility to create a script that could be put into an executable file that would launch automatically the virtual machine by just clicking the exec. I have already seen this stackoverflow question :
Start azure virtual machine without azure portal
which suggests to create an Azure PowerShell script that would start the virtual machine. Only problem is that launching a powershell script is out of the technical level of the person who would use it. On top of that, there is a need to install Azure add-on for powershell (if I understand correctly) which would not be possible depending on the machine and the rights the user have on it.
So my question : Do you have any idea on how I could make a simple program (in the form for example of an executable that would run on any machine without any dependency) that would start an azure virtual machine ?
One solution I thought about but it seemed very complicated : create a "super low cost" virtual machine that would be on 100% of time and just create an exec that instruct this VM to start the other virtual machine on demand ?
Thanks for your help
I have a problem with the idea that a powershell script is outside of the scope of a user that can run an exe file. If built properly, a ps1 should just be a double-click, exactly like an exe.
Aside from that, you have a couple hurdles to look at.
Your user can't have access to the resources that they need to interact with.
This can be done by passing custom PScredential objects through the script and pulling the credentials from a file. You would build the credential file with ConvertFrom-SecureString and then import it in with CovertTo-SecureString. The biggest problem with this is that if the user can see where that file is stored, they could potentially write a script to access that file and gain privileged access.
Your user doesn't have permission to run the powershell resources needed to execute the script. For this, you'd need to build in runas permission on the script, and I think creating an exe might be the best avenue for that. Although you could have the initial script call another shell with elevated permissions and work through that.
There are tools out there like PowerGUI, that will compile a ps1 file into an exe format. A properly compiled and secure exe file would hide the scripts that call out to secure string files and also allow for custom runas permissions built into the program.

What's the easiest approach to automate startup tasks on Azure VMs?

My current application scenario requires me to start several VM simultaneously with some startup tasks (the startup task on each VM triggers the same script but with different parameters). Previously in EC2 I can easily start a number of EC2 instances and then use Windows task scheduler easily to trigger the executable file, read the data in user-data of each instance and then everything is done.
I tried the same approach in Azure but found a number of issues:
Tried using task scheduler and start a task "at startup", but won't work since after syspreping the user information is lost and therefore I won't be able to start the same task.
Tried gpedit.msc and specify a startup script. Won't work. I don't know why.
Tried using task scheduler and start a task at a specific time point. Won't work. I've received an error message which says "the operator or administrator has refused the request".
So what's the simplest approach to automate a startup task in Azure VM?
Did you think about using the Azure-powershell?
You could use the Start-AzureVM-cmdlet to start your VMs.
You could use the following
code-snippet for starts:
$vmuri = Get-AzureWinRMUri -ServiceName $VMName
#region start hpc-azure-nodes
Invoke-Command -ConnectionUri $vmuri -Credential $credential {
#start your tasks with the according parameters
} -ArgumentList
A considerably fancier way would be to create a head-vm in Azure and install a HPC-cluster-manager. Utilizing the HPC-cluster-manager you can provision any number of Azure computing nodes within your limit, deploy your software and start/stop your software centrally from the cluster-manager.
Additionally the HPC-cluster-manager provides a number of helpful features:
add/remove nodes
connect via rdp to each node
view logging information for your jobs
and many, many more
There is also a HPC-powershell which provides a nice environment for automation. Admittedly this approach requires somewhat more effort but in the long run it almost certainly pays off.
I think what you're looking for is PowerShell Desired State Configuration (DSC).
This is a management platform introduced in PowerShell 4.0. You can use it to configure a VM or set of servers by providing a description of the desired state for each node in the system. Basically you can describe the state you want the server to be in when it boots up and if the configuration has drifted it will correct it.
A DSC script can:
Manage registry keys
Copy files and folders
Run PowerShell scripts
Deploy software
Manage server roles
Turn Windows features on/off
Here is a quick tutorial at blog.msdn.com that will get you started.

Azure Cloud Services file system access

The "Best Practice" for Azure Cloud Services describes the ugly hacks that make the most of the 1970s-era command line configuration API. (Sorry, I'm not quite old enough to realize the injustice I'm likely doing to computing in that decade.) The debugging approach is to output stdout and stderr to a file in %TEMP%.
My question is how can I access the file? Do I have to Remote Desktop in, or is there a better way, i.e. some sort of remote file system access?
I realize it's a nuisance to say the least to debug the actual Startup Task of a Cloud Service. I don't particularly enjoy it myself. There is a good way to do it though which takes a lot of the pain out of the process!
I advice you to script this and debug it on the machine itself using Remote Desktop! Once you have the script setup right for whatever it is you need to do on the machine, you simply copy the script into the startup task!
What I'm saying is remove the Startup task and let your Cloud Service launch fully. Then Remote into the instance and debug your script on the box.
I have a more lengthy explanation of this on my blog: How to set up and debug the Startup Task in a Windows Azure Cloud Service.
You'll be unable to RD there until the instance has been started. So if you have a problem during startup you're screwed with this approach. Additionally if the VM is returned to Azure (you scale out, then scale in or the VM is considered faulty) you lose all the logs.
The only reliable solution is to use permanent storage such as blob storage. This post (item 2) shows a decent implementation.

Role Instances are taking longer than expected - Workaround issues

Whenever we get the error "Role Instances are taking longer than expected". The only possible options to do are .
Shutdown the emulators and try again.
Restart the machine and see if that helps.
Uninstall the Azure Tools for that version.
Some times uninstalling the same takes a long time,some times even days. It appears that some process or service is blocking the same. Has anyone faced this before ? If yes does anyone know which process would be blocking the same?
When an instance starts it will run the OnStart method on the worker/web role (depending on your service type). The more stuff you have in there, the more time it will take to start up the role. Common caveats are the Cache as mentioned and blob/table storage (if you do read/write/create when you start the role).
Try minimizing the OnStart's workload and moving any storage stuff in async tasks.
I have had similar problems as well in the past
IISConfigurator could not map the web roles in IIS. In my case it was due to corrupted file system ACLs on the code directory. See logs under C:\Users\YOUR_USER_NAME\AppData\Local\dftmp\IISConfiguratorLogs\
Another cause might be that something else has tied up the Port Numbers that Azure is trying to bind your web role on. Or that the ports that the local storage needs for tables/blobs and queues (10000-10002) have been taken by another app. Open a command prompt and run netstat -anb
Try running the Visual Studio using "Run as Administrator" option.

Cloud environment on Windows Azure platform

I've got 6 web sites, 2 databases and 1 cloud environment setup on my account
I used the cloud to run some tasks via Windows Task Manager, everything was installed on my D drive but between last week and today the 8 of March my folder containing the "exe" to run as been removed.
Also I've installed SVN tortoise to get the files deployed and it not installed anymore
I wonder if somebody has a clue about my problem
Best Regards
Franck merlin
If you're using Cloud Services (web/worker roles), these are stateless virtual machines. That is: Windows Azure provides the operating system, then brings your deployment package into the environment after bootup. Every single virtual machine instance booted this way starts from a clean OS image, along with the exact same set of code bits from you.
Should you RDP into the box and manually install anything, anything you install is going to be temporary at best. Your stuff will likely survive reboots. However, if the OS needs updating (especially the underlying host OS), your changes will be lost as a fresh OS is brought up.
This is why, with Cloud Services, all customizations should be done via startup tasks or the OnStart() event. You should never manually install anything via RDP since:
Your changes will be temporary
Your changes won't propagate to additional instances; you'll be required to RDP into every single box to perform the same changes.
You may want to download the Azure Training Kit and look through some of the Cloud Service labs to get a better feel for startup tasks.
In addition to what David said, check out http://blogs.msdn.com/b/kwill/archive/2012/10/05/windows-azure-disk-partition-preservation.aspx for the scenarios where the different drives will be destroyed.
Also take a look at http://blogs.msdn.com/b/kwill/archive/2012/09/19/role-instance-restarts-due-to-os-upgrades.aspx which points you to the RSS feed and MSDN article where you can see that a new OS is currently being deployed.

Resources