Edit : After a lots of testing, we managed to find a comon point between the machines which, when connected using RDP to our environment, breaked the excecution of excel funtionnalities called from a powershell script launched by an azure devops agent : All these machines have a touchscreen, machines without a touchscreen do not break it (tryed with 3 machines with touchscreen, different contructors and 4 machines without touchscreen)
Edit 2: When the touchscreen is disabled being connected to the machine with RDP do not break the script anymore
I'm using AzureDevops agents to execute a powershell task on a Cloud Hosted environment, the task is very simple it justs creates a workbook and saves it:
try{
write-host 'initalized excel'
$Excel = New-Object -ComObject Excel.Application
write-host 'adding WB'
$Workbook = $Excel.Workbooks.Add()
write-host 'Saving Wb'
$Workbook.SaveAs('C:\test\test.xlsx')
}
finally{
write-host 'quitting excel'
$Excel.quit()
}
Here's the output of the devops Task :
##[section]Starting: PowerShell Script
==============================================================================
Task : PowerShell
Description : Run a PowerShell script on Linux, macOS, or Windows
Version : 2.151.2
Author : Microsoft Corporation
Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/utility/powershell
==============================================================================
Generating script.
========================== Starting Command Output ===========================
##[command]"C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'C:\agent\_work\_temp\33ed6d09-53ba-427a-a7ac-ea425a98767c.ps1'"
initalized excel
adding WB
quitting excel
Exception from HRESULT: 0x800A03EC
At C:\agent\_work\_temp\33ed6d09-53ba-427a-a7ac-ea425a98767c.ps1:6 char:5
+ $Workbook = $Excel.Workbooks.Add()
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [], COMException
+ FullyQualifiedErrorId : System.Runtime.InteropServices.COMException
This is what happens when my colleague is connected to the virtual machine on which the agent executes the script. My colleague is connected with the windows remote desktop tool.
When I'm the one connected on the VM using RDP it works fine :
##[section]Starting: PowerShell Script
==============================================================================
Task : PowerShell
Description : Run a PowerShell script on Linux, macOS, or Windows
Version : 2.151.2
Author : Microsoft Corporation
Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/utility/powershell
==============================================================================
Generating script.
========================== Starting Command Output ===========================
##[command]"C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'C:\agent\_work\_temp\436b2d56-2a41-4f75-97bb-01d4c41407e6.ps1'"
initalized excel
adding WB
Saving Wb
quitting excel
##[section]Finishing: PowerShell Script
My colleage and I RDP to the virtual machine with the same exact user.
We tried on another virtual machine with another devops agent, the same issue arise.
I'm a bit lost and I dont know how to troubleshoot this issue at all, also if you have any other suggestion for the title I'll take every piece of advice.
Edit:
We also tried to put this script in a loop and write if it succeed or fail, when I rdp to the virtual machine, it works, if I disconnect it works, as soon as my colleague RDP into the virtual machine it starts failing, if I reconnect (thus disconnecting my colleague) it works again. (We RDP with the same user)
Edit2 :
I'm receiving an edit suggestion from someone who noticed me that :
From the user's comment->' when the agent is already running and
creating excel files in a loop, the simple fact my colleague rdp to
the vm breaks the excel file creation.' This issue seems to have
nothing to do with azure devops. The reason for the problem is due to
rdp
Well it's an azure devops agent problem as well since simply running the script manually works for both of us. It's a RDP issue that cause the Devops agent to be unable to use some of the excel-powershell functions, so I think the Azure Devops tag is still accurate
Edit :
In the finally block try outputting the full error stack with: $Error
| Format-List -Force – HAL9256
Here's the error :
Exception : System.Runtime.InteropServices.COMException (0x800706BE): The remote procedure call failed.
(Exception from HRESULT: 0x800706BE)
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode,
IntPtr errorInfo)
at System.Management.Automation.ComInterop.ComRuntimeHelpers.CheckThrowException(Int32
hresult, ExcepInfo& excepInfo, ComMethodDesc method, Object[] args, UInt32 argErr)
at CallSite.Target(Closure , CallSite , ComObject )
at System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0 arg0)
at CallSite.Target(Closure , CallSite , Object )
at System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0 arg0)
at System.Management.Automation.Interpreter.DynamicInstruction`2.Run(InterpretedFrame frame)
at
System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame
frame)
TargetObject :
CategoryInfo : OperationStopped: (:) [], COMException
FullyQualifiedErrorId : System.Runtime.InteropServices.COMException
ErrorDetails :
InvocationInfo : System.Management.Automation.InvocationInfo
ScriptStackTrace : at <ScriptBlock>, C:\agent\_work\_temp\fae3ef7a-700d-49c1-8f1f-7f7d2bc0d49e.ps1: line 8
at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {}
PSMessageDetails :
Running Excel under an automated, unattended process (such as an Azure DevOps Agent) in unsupported and can lead to all kinds issues, like the ones you are running into.
The official recommendation is to rely on a 3rd party component like Excel Package Plus (free), NPOI (free), SpreadSheetGear (Commercial) or Aspose Cells.NET (Commercial). Or to use System.IO.Packaging and edit the XML for the Office document directly. These do not depend on having Excel installed on your server, are actually supported and don't have all kinds of license issues associated with them. Migrating your scrips over to these other package types is often not very hard, since they take a very similar API for portability.
Besides the technical issues you're running into, the licensing may be even hairier, as Office isn't allowed to be automated 'on behalf of other users' and generally isn't allowed to run on a server.
Besides the technical problems, you must also consider licensing issues. Current licensing guidelines prevent Office applications from being used on a server to service client requests, unless those clients themselves have licensed copies of Office. Using server-side Automation to provide Office functionality to unlicensed workstations is not covered by the End User License Agreement (EULA).
https://support.microsoft.com/en-us/help/257757/considerations-for-server-side-automation-of-office
You may be able to solve some of the issues, like the one you are experiencing now, but you're likely going to run into new ones. Running the Azure DevOps agent interactively may help, that way Excel will be launched in the interactive session as well, instead of a protected hidden user session with no real desktop. What's likely happening, is that the second user connecting over RDP is closing all other sessions when they log on, or locking all sessions as they log off.
here are security risks when you enable automatic logon or disable the screen saver because you enable other users to walk up to the computer and use the account that automatically logs on. If you configure the agent to run in this way, you must ensure the computer is physically protected; for example, located in a secure facility. If you use Remote Desktop to access the computer on which an agent is running with auto-logon, simply closing the Remote Desktop causes the computer to be locked and any UI tests that run on this agent may fail. To avoid this, use the tscon command to disconnect from Remote Desktop. For example:
%windir%\System32\tscon.exe 1 /dest:console
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-devops#interactive-or-service
Another problem concerning excel automation on a server, is that existing Excel instances are re-used. This may cause the host excel to run under different credentials than the process doing the automation.
To run the agent interactively configure the serves to auto-logon (this utility encrypts the credentials used) and add run.cmd in the agent folder to the start-up executable list (either in the registry or a shortcut in the start menu). You can also make the agent executable (c:\windows\system32\cmd.exe /c path\to\agent\run.cmd) the default shell. There are quite a few docs on setting a custom shell.
You'll need to disable the screensaver and lockscreen for this session as well, which well require you to physically secure the server, otherwise anyone with access to the servers console will be able to access the running interactive session.
And you must unsure you always disconnect the remote desktop session without locking it (like above).
We finally identified that the problem only happened when using the RDP from a laptop having a touchscreen.
We then disabled the touchscreen using this documentation :
In the search box on the taskbar, type Device Manager, then select
Device Manager.
Select the arrow next to Human Interface Devices and
then select HID-compliant touch screen. (There may be more than one
listed.)
Select the Action tab at the top of the window.
Select Disable device or Enable device, and then confirm. If there's more
than one HID-compliant touchscreen device listed, perform steps 2–3
for that one too.
https://support.microsoft.com/en-us/help/4028019/windows-enable-and-disable-your-touchscreen-in-windows-10
And the script stopped crashing.
If someone want to post an answer to solve this problem without disabling touchscreen by tweaking the parameters in RDP or in the server we RDP to, i'd accept his answer as it's easier to change the parameter once than to ask people to disable their touchscreen when they rdp to our machine.
I'm trying to set up continuous deployment (.NET Core 1.1 Web Application) with the build mechanism of VSTS.
To do so I'm following the steps displayed on the official doc of Microsoft :
Use VSTS to Build and Publish to an Azure Web App with Continuous Deployment.
The first 3 steps (restore/publish/zip) work without any issue. But the fourth step is failing. I'm not able to publish the app to my Azure App Service.
Here is the error (from the log) :
2016-12-22T14:12:13.1175907Z Got connection details for azureRM WebApp:'devoteamlogin-staging'
2016-12-22T14:12:13.5419583Z Running command: "C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:getParameters -source:package="C:\a\1\a\DevoteamLogin.zip" > "C:\a\1\s\parameter.xml"
2016-12-22T14:12:14.8449274Z Error Code: ERROR_EXCEPTION_WHILE_CREATING_OBJECT
2016-12-22T14:12:14.8449274Z More Information: Object of type 'package' and path 'C:\a\1\a\DevoteamLogin.zip' cannot be created. Learn more at:
2016-12-22T14:12:14.8449274Z Error: The Zip package 'C:\a\1\a\DevoteamLogin.zip' could not be loaded.
2016-12-22T14:12:14.8449274Z Error: Package file 'C:\a\1\a\DevoteamLogin.zip' is not in a supported .zip format and therefore cannot be read.
2016-12-22T14:12:14.8449274Z Error count: 1.
2016-12-22T14:12:14.8509276Z ##[error]TypeError: Cannot read property 'output' of null
2016-12-22T14:12:14.8589281Z ##[section]Finishing: Deploy AzureRM App Service: devoteamlogin-staging
Step details
Am I missing something somewhere ? I did exactly what the documentation says (same variables, same steps, same configuration).
Update: After making some new tests, I see that the 'dotnet restore' command does not restore anything because it does not find the project.json. But there is no project.json file anymore in the new ASP.NET Core 1.1 Web application (everything is in the .csproj file).
warn : The folder 'C:\a\1\s' does not contain a project to restore.
Here is a solution https://twitter.com/DonovanBrown/status/816380372028002304. This shows the requirements to build csproj projects with Team Services. It is a full working solution.
I think the format of your zip archive is wrong, I used the native archive file task instead and unchecked "Prefix root folder name to archive paths".
Also I followed the documentation from the Visual Studio Team instead of the one from the dotnetcore team. It works better I found.
My goal is to create a Deployment Manager profile in my Websphere on Linux.
Reading tons of documentation pages gives just two methods:
1) using X GUI application WAS_root/bin/ProfileManagement/pmt.sh
In this case, according to manuals, i should choose Management option, click "Next" and choose Deployment Manager server type.
Actually when i run pmt.sh in my WAS installation there is no option to choose Deployment Manager in Management section and only one profile type that i'm able to create is AdminAgent.
2) using manageprofiles.sh script under WAS_root/bin directory.
The manuals say that i can use -serverType DEPLOYMENT_MANAGER option in order to create deployment manager profile.
Actually when i run the script:
./manageprofiles.sh -create -templatePath ../profileTemplates/management/ -ServerType DEPLOYMENT_MANAGER -isDefault -profileName dmgr -adminUserName websphere -adminPassword websphere1
I get the following message:
The following validation errors were present with the command line
arguments:
serverType: The value for this parameter must be within this set of values [ADMIN_AGENT]
That means that i don't have the ability to create Deployment Manager at all.
Please advise what steps i can perform to be able to install Deploy Manager except erase my WAS installation and install it from scratch once again.
Thanks a lot.
You have standalone aka base edition of WebSphere Application Server. To create Deployment Manager you need Network Deployment edition.
Unfortunately you will have to install it from scratch from different installation files (from ND, not base or developers edition).
The steps I have taken:
1) Get-AzurePublishSettingsFile
I then download the file.
2) Import-AzurePublishSettingsFile
now the problem is here, I have put the first file in the C drive, but it cant seem to find it.
I do the following
Import-AzurePublishSettingsFile C:\-credentials.publishsettings
powershell returns the following error
CategoryInfo : InvalidArgument: (:) [Import-AzurePublishSettingsFile], ParameterBindingException
FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.WindowsAzure.Management.Cmdlets.ImportAzurePublish
SettingsCommand
any idea how to resolve this.
thanks
You are passing the the incorrect publishsettings file location in your command as below and that's why you are getting the exception:
PS> import-AzurePublishSettingsFile C:\-credentials.publishsettings
Nobody knows where you are storing the publishsettings in your machine so what you really need is to download publishsettings file again using Get-AzurePublishSettingsFile PS command and this time remember where you are saving it in your local machine.
Once you know the publishsettings file path pass it correctly with import-AzurePublishSettingsFile PS command and it will work.
PS> import-AzurePublishSettingsFile CORRECT_PATH_TO_PUBLISHSETTINGS_FILE
I have created a sample PS script menu to use Windows Azure so you can take a look here.
From what I understand, there are 2 ways to publish to Azure using VS 2012: the first one is 1) via "publish" and 2) the second one is "publish via azure".
1) If you are selecting "publish" which is just to Azure websites the while it gives up an option to select the downloaded publish settings these settings do not actually import and the only way I get the website deployed is by setting up the profile manually.
2) to use your downloaded publish settings, you must select "publish to azure", which then imports the certificate and allows you proceed to the next steps within the VS 2012 deployment to a cloud service.
It took me a while to understand that publishing via VS 2012 is a completely separate process from using Azure Powershell to manage Azure VMs (or blobs) which also requires you to work with the downloaded publishsettings which I left in my "downloads" folder per below:
PS C:> Import-AzurePublishSettingsFile 'C:\Users[me]\Downloads[Pay-As-You-Go-credentials.publishsettings]'
Note: the single quotes seem to be required.
I'm using Visual Studio 2012 and the publishing feature. I have created a publishing profile that deploys my application to a development server, and it works great when executed from vs2012 on my machine. Here is my problem; on the development server I also have TeamCity installed and I would like to trigger the publishing after a build have completed. So I created a simple build step that looks like this:
Build file path: .\src\Solution.sln
Targets: Rebuild
Command line parameters: /p:DeployOnBuild=true;PublishProfile=Ci
When this step is executing I get the following error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets(4377, 5): error ERROR_USER_NOT_ADMIN: Web deployment task failed.
(Connected to 'dev.domain.com' using the Web Deployment Agent Service, but could not authorize. Make sure you are an administrator on 'dev.domain.com'.
The Ci profile contains a username and password that works when I run the publishing from Visual Studio on my machine. I have also tried passing in username and password as parameters in the build step, but I get the same result. Do I need to run the TeamCity services under admin accounts to get this working? All suggestions are appreciated.
I have just blogged about this at http://sedodream.com/2013/01/06/CommandLineWebProjectPublishing.aspx.
You are pretty close, hopefully I can close the gap.
You are correct that username and password are specified in the VS publish dialog, but we do not save the password in the .pubxml file. It is currently being saved in the .pubxml.user file, and that file is not used at all for command line scenarios. Because of that you will need to pass in the property. So in your case it should be
msbuild .\src\solution.sln /p:DeployOnBuild=true /p:PublishProfile=ci /p:Password=<insert-password>
If your web server does not have trusted certs you may need to also pass in /p:AllowUntrustedCertificate=true.
One little addition which may not be directly related to your issue, but may be helpful for others which may see this later.
If you are building the .csproj/.vbproj file (and potentially in some scenarios where the .sln file is used) you should pass in the property /p:VisualStudioVersion=11.0. More info on this available at my blog http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx