I am new to tfs-2018, I am trying to do deploy on one of my servers but getting below error in the log. I was able to deploy on other 2 systems but one system is giving the bellow error. Any help will be appreciated
Log:
2018-01-29T06:55:20.8002862Z ##[section]Starting: IIS Web App Manage
2018-01-29T06:55:20.8484384Z ==============================================================================
2018-01-29T06:55:20.8484384Z Task : IIS Web App Manage
2018-01-29T06:55:20.8484384Z Description : Create or update a Website, Web App, Virtual Directories, and Application Pool
2018-01-29T06:55:20.8484384Z Version : 0.4.4
2018-01-29T06:55:20.8484384Z Author : Microsoft Corporation
2018-01-29T06:55:20.8484384Z Help : More Information
2018-01-29T06:55:20.8484384Z ==============================================================================
2018-01-29T06:55:24.2725407Z ##[command]"C:\Windows\system32\inetsrv\appcmd.exe" list app "Default Web Site/PDM"
2018-01-29T06:55:24.4872952Z ##[command]"C:\Windows\system32\inetsrv\appcmd.exe" set app /app.name:"Default Web Site/PDM" -[path='/'].physicalPath:"E:\inetpub\wwwroot\PDM" -[path='/'].userName: -[path='/'].password:
2018-01-29T06:55:24.7066288Z APP object "Default Web Site/PDM" changed
2018-01-29T06:55:24.7066288Z ERROR ( hresult:80070057, message:Failed to commit configuration changes.
2018-01-29T06:55:24.7998202Z
2018-01-29T06:55:24.7998202Z The parameter is incorrect.
2018-01-29T06:55:24.7998202Z
2018-01-29T06:55:24.7998202Z )
2018-01-29T06:55:25.1905059Z ##[error]Process 'appcmd.exe' exited with code '87'.
2018-01-29T06:55:25.3169881Z ##[section]Finishing: IIS Web App Manage
Below is the configuration details attached.
I had similiar symptoms at one Windows Server 2012 R2 - on all other Windows Server 2012 R2 it would work.
Symptoms
"C:\Windows\system32\inetsrv\appcmd.exe" set app /app.name:"Default Web Site/foo" -applicationPool:"foo" -[path='/'].physicalPath:"C:\temp\foo" -[path='/'].userName: -[path='/'].password:
ERROR ( hresult:80070057, message:Failed to commit configuration changes.
The Parameter is incorrect.
)
We tried to figure out what was happening, and found that the appcmd.exe password Parameter would not work.
When omitting the password parameter the command would work fine:
"C:\Windows\system32\inetsrv\appcmd.exe" set app /app.name:"Default Web Site/foo" -applicationPool:"foo" -[path='/'].physicalPath:"C:\temp\foo" -[path='/'].userName:
Another symptom that led us to the root of the problem was:
specifying Physical Path credentials for a VirtualDirectory via the mgmnt-console would also not work.
Solution
For us, the problem was with a corrupt IIS Configuration Key. That prevented us from encrypting passwords in the applicationhost.config
We fixed the problem by importing the IIS Configuration Key from another test-machine.
Reinstalling IIS would have worked as well (if we ever had that problem on a production server)
Exporting the config key from a working IIS Server:
aspnet_regiis -px "iisConfigurationKey" "C:\temp\iisConfigurationKey.xml" -pri
Importing the config key at the renitent IIS Server:
aspnet_regiis -pi "iisConfigurationKey" "C:\temp\iisConfigurationKey.xml"
Replace AesProvider Element
Finally we replaced the AesProvider Provider Element from applicationHost.config
configProtectedData Section with the element from the working IIS Server and restarted the IIS.
Buried in there you will see The parameter is incorrect. which is what Microsoft’s standardized error code 87 means.
In my case the list of urls was wrong (I wasn’t delimiting them correctly with colons, or the wildcards were incorrect). Looking at yours, I don’t see an equivalent field. But try simplifying the fields you have specified until you get something working, then add the real values back gradually.
Related
I am trying to use JasperReports integration for the first time. I am using the included Jetty server, Oracle database XE 18c and Windows 7.
I am following the quick start guide https://github.com/daust/JasperReportsIntegration/blob/main/src/doc/github/installation-quickstart.md
I downloaded the zip folder, configuired database access through adding schema credentials in application.properties file as follows...
[datasource:default] type=jdbc
url=jdbc:oracle:thin:#localhost:1521:XEPDB1 username=hr password=hr
this parameter is limiting access to the integration for the specified
list of ip addresses, e.g.:
ipAddressesAllowed=127.0.0.1,10.10.10.10,192.168.178.31 if the list is
empty, ALL addresses are allowed.
Then I deployed the jri.war file successfully. Then I started the server successfully as well. But when I tried to test it through http://localhost:8090/, I got the following page, and I do not know if that's the norm or there's something wrong...
I need to know if testing is successful, and what's meant by "context" here?
Thanks
You deployed the jri.war to the context path /jri, this isn't an error, and is quite normal.
Just access your webapp via http://localhost:8080/jri/
I'm trying to connect the SPGo plugin in Visual Studio Code to a Sharepoint Online site. There are lots of guides for this, for instance this one: https://medium.com/niftit-sharepoint-blog/saying-goodbye-to-sharepoint-designer-ac939a0b79ba
In short, I'm doing it like this:
Open VS Code
Open a local, empty folder)
SPGO: Configure workspace (follow guide, ending up with spgo.json
looking like the one I pasted)
SPGO: Populate local workspace (asking me for credentials and I plot
it in O365 style (email and password).
Statusbar says "Populating workspace"
After about 10 seconds I get the pasted error in the output window (spgo)
I'm using newest versions:
Visual Studio Code 1.37.1
SPGo 1.4.3
I have tried various sites in my tenant and I know they are up. I am Site Collection Administrator for the sites. I know the credentials are correct, of course. the remoteFolders and publishingScope doesn't affect anything, when changed. I assume authenticationType should be "Digest".
SPGo.json:
{
"sourceDirectory": "src",
"sharePointSiteUrl": "https://domain.sharepoint.com/sites/SiteName",
"publishingScope": "Major",
"authenticationType": "Digest",
"remoteFolders": [
"/SitePages/"
]
}
I don't get any files in the local folder, instead I get an error in the output:
================================ ERROR ================================
<s:Fault>
<s:Code>
<s:Value>s:Receiver</s:Value>
<s:Subcode>
<s:Value xmlns:a="http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher">a:InternalServiceFault</s:Value>
</s:Subcode>
</s:Code>
<s:Reason>
<s:Text xml:lang="en-US">The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs.</s:Text>
</s:Reason>
</s:Fault>
Error Detail:
----------------------
{}
===============================================================================
Sorry I missed this post for so long. First- thanks for the detailed write-up. This is the first time I've seen this specific issue with SPGo, so I do not know for sure what is the root cause.
Couple questions:
Are you using ADFS Authentication with your Office 365/SharePoint Online instance?
Are you able to use Addin-Only Authentication on this SP Site?
SPGo should be able to automatically work with ADFS in SharePoint Online but, as a fall-back, you could use Addin-Only Authentication. In this scenario you would create a ClientId and ClientSecret pair for the SharePoint Site Collection you are accessing and authenticate using those credentials. The ClientId would act as your UserName, and the ClientSecret would be your password.
Under the covers, I am using the node-sp-auth package for user authentication. Sergei (s-KaiNet on Github) has a great write-up on how to enable Addin-Only Authentication in SharePoint Online on his site, which you can find here.
Thanks for using SPGo!
Have a simple two-step release definition in Visual Studio Team Services / VSTS based on the "IIS Website Deployment" template set to configure an application pool (v4, integrated, application pool identity) and website (http, 192.168.0.xxx LAN IP, port 80, valid hostname) which is throwing an error I've struggled to find any details on. Isolated the issue to some AppCmd parameters but can't seem to remove them via the step settings.
Deploying out to a 2008 R2 target via VSTS agent v2.127.0 which installed without any issues but AppCmd consistently fails on the "IIS Web App Manage" step (after reconfiguring the application pool, creating a directory etc. without problems) then exits with code 8
hresult 80070008, Failed to commit configuration changes. Not enough storage is available to process this command.
Full log below but this line causes the error
"C:\Windows\system32\inetsrv\appcmd.exe" set site /site.name:"Example - Website Name" -applicationDefaults.applicationPool:"Example - AppPool Name" -[path='/'].[path='/'].physicalPath:"D:\Test\Example - Website Name" -[path='/'].[path='/'].userName: -[path='/'].[path='/'].password:
Running this directly on the target produces the same error, if I strip the blank username & password parameters it works. Checked we're not trying to set credentials and combinations of the authentication settings against the website and these two parameters won't either dissappear or format in a way which doesn't throw an error.
Tried searching for similar questions and it's lead nowhere, restarted the target in case it was a memory issue, even tried building a website-only step but the error remains.
##[section]Starting: Configure IIS AppPool & Website
==============================================================================
Task : IIS Web App Manage
Description : Create or update a Website, Web App, Virtual Directories, and Application Pool
Version : 0.5.4
Author : Microsoft Corporation
Help : [More Information](https://go.microsoft.com/fwlink/?linkid=839731)
==============================================================================
##[command]"C:\Windows\system32\inetsrv\appcmd.exe" list apppool /name:"Example - AppPool Name"
##[command]"C:\Windows\system32\inetsrv\appcmd.exe" set apppool /apppool.name:"Example - AppPool Name" -managedRuntimeVersion:v4.0 -managedPipelineMode:Integrated -processModel.identityType:ApplicationPoolIdentity
APPPOOL object "Example - AppPool Name" changed
##[command]"C:\Windows\system32\inetsrv\appcmd.exe" list site /name:"Example - Website Name"
##[command]"C:\Windows\system32\inetsrv\appcmd.exe" add site /name:"Example - Website Name" /physicalPath:"D:\Test\Example - Website Name"
SITE object "Example - Website Name" added
APP object "Example - Website Name/" added
VDIR object "Example - Website Name/" added
##[command]"C:\Windows\system32\inetsrv\appcmd.exe" set site /site.name:"Example - Website Name" -applicationDefaults.applicationPool:"Example - AppPool Name" -[path='/'].[path='/'].physicalPath:"D:\Test\Example - Website Name" -[path='/'].[path='/'].userName: -[path='/'].[path='/'].password:
SITE object "Example - Website Name" changed
ERROR ( hresult:80070008, message:Failed to commit configuration changes.
Not enough storage is available to process this command.
)
##[error]Process 'appcmd.exe' exited with code '8'.
##[section]Finishing: Configure IIS AppPool & Website
After discussing with MS Developer Support my problem appeared to be an issue with the target server's applicationHost.config encryption/security keys complicated by a less-than-useful error message being returned by AppCmd
The easiest way to verify the applicationHost.config being at fault was backing up the current config before reverting to an original, default copy of the applicationHost.config (C:\Windows\System32\inetsrv\config) then restarting the W3SVC service - was able to execute the "IIS Web App Manage" step without any issues afterwards.
Unfortunately keeping it reverted wasn't an option, so diffed the two versions of the config and found two keys with different sessionKey values in <configuration><configProtectedData><providers>
Copied the version of the highlighted keys (AesProvider & IISWASOnlyAesProvider) from our clean config to the current, restarted the W3SVC service and the same AppCmd line was able to run successfully.
Will continue to monitor as this was only happening on a physical internal development server with many potential ways the applicationHost.config could have accidentally changed while it's been in service - none of which should ever apply to a production system.
I am using SQL Server CE 4.0 with WebApi on Windows Azure Websites. I have been successfully able to deploy SQL Server CE. The weird problem I am facing is that my site is able to log me in using the same DB but I am not able to use any of the controllers to fetch the data.
I am using same connection string for both. The only difference is that for logging in I am using WebSecurity as I have enabled OAuth on the site.
Can someone throw some light on how to debug and fix this issue? The error I am getting for the calls is
Format of the initialization string does not conform to specification
starting at index 0.
However the same string works for authentication, change password, adding OAuth connections etc.
Thanks in advance
I connected to the site using FTP. I was not giving the site name as domain name and it was denying me access earlier. On connecting, I got hold of the Web.config file and I found something interesting. While publishing the site, the web.config was modified to add another connectionstring with the name of context_DatabasePublish.
This string had following details connectionString="ContextName_DatabasePublish.ConnetionString" providerName="System.Data.SqlClient"
Also there was a new section called context added to the entityframework section of the config file with all the details for the context to use but again pointing to same connection string. The provider it is using is sql and not sqlce. I believe that is the reason it was failing.
I uploaded my normal config file and the site started working. I need to explore more on to why and how the new connection string got added. I will post the details in comments.
Last night, at home, where I do not work with a proxy, updated a NuGet repository using NuGetPowerTools / Enable-PackageRestore.
Worked great.
Came into the office, where i am working with the same Repository under the following conditions:
in a VMWare based VM,
using Bridged Networking,
Reinstalled NuGet today, restarted (to be sure I have latest version)
runnning under an account in a DEV Domain (ie, DEV\Me)
Accessing the outer world via a Proxy that requires a corp Domain Account (ie, CORP\Me)
Ie 9's Configuration/Internet Options/Connection is setup as:
Use Proxy:
Address: yadayada1
Port: 80
Bypass proxy for local addresses
Automatically detect Settings
Above settings are correct in as much that I can access the web via IE9, Chrome, etc.
NOTE: Can list and download Nuget packages...it's just the new Build process that can't.
As per suggestion on the web I have looked at DevEnv.exe.config and have the following settings:
-<system.net><settings><ipv6 enabled="true" /></settings></system.net>
I also tried with these settings as
<system.net><defaultProxy useDefaultCredentials="true"><proxy autoDetect="True" usesystemdefault="True" /></defaultProxy></system.net>
so that DevEnv.exe falls back for to same connection settings that IE 9 is using. Didn't do it.
What I get for all this is:
------ Build started: Project: XAct.Core, Configuration: Debug Any CPU ------
Please provide proxy credentials:
UserName: Password:
C:_Workspaces\XAct\CS.FF.XAct.Lib2.nuget\NuGet.targets(43,9): error : Cannot read keys > when either application does not have a console or when console input has been redirected > from a file. Try Console.Read.
C:_Workspaces\XAct\CS.FF.XAct.Lib2.nuget\NuGet.targets(43,9): error MSB3073: The
command ""C:_Workspaces\XAct\CS.FF.XAct.Lib2.nuget\nuget.exe" install
"C:_Workspaces\XAct\CS.FF.XAct.Lib2\XAct.Core\XAct.Core\packages.config" -source "" -o
"C:_Workspaces\XAct\CS.FF.XAct.Lib2\packages"" exited with code 1.
Found (but unfortunately lost again) a thread somewhere on the net where I saw NuGet developers thrashing it out -- referring to downloading the latest build from their TeamCity (which I could not access/join) -- but the thread did not clearly say Eureka! at the bottom.
Thanks.
Reiterating what Sky and Pranav mentioned - this issue seems to be fixed in NuGet 1.7 - see http://nuget.codeplex.com/workitem/1655:
pranavkm wrote Jan 31 at 8:17 PM
Fixed in changeset 6c156e0dc214