I am trying to use the xWebsite resource in powershell DSC but it keeps failing to Set-TargetResource. the error is
PowerShell provider MSFT_xWebsite failed to execute Set-TargetResource functionality with error message:
+ CategoryInfo : InvalidOperation: (:) [], CimException
+ FullyQualifiedErrorId : ProviderOperationExecutionFailure
The resource looks like
WindowsFeature IIS
{
Ensure = “Present”
Name = “Web-Server”
}
xWebsite Website
{
Ensure = "Present"
Name = "Website"
PhysicalPath = "E:\www\site"
State = "Started"
BindingInfo = MSFT_xWebBindingInformation
{
Protocol = 'HTTP'
Port = 7777
HostName = '*'
}
DependsOn = "[WindowsFeature]IIS"
}
I just copied it from one of the DSC examples, and initially it did not return the above error. I do not know what changed, but now it cannot create the website on subsequent runs. There is not a lot of troubleshooting content on DSC yet either, and I am hoping that someone else has run into this problem as well.
Regarding the initial run not returning an error
This may be related to this bug.
Regarding the error itself
Let's check the obvious stuff first:
All components of the PhysicalPath must exist; the resource won't create any of those paths. So use a File resource to create them if needed then make xWebsite depend on it.
Make sure a different web site is not using the port.
You show a DependsOn but don't show the rest of your configuration. Make sure that you're actually specifying a WindowsFeature resource in your config for it to depend on.
If those don't help
Post the rest of your config (if there is more).
Check out the xDscDiagnostics module in the DSC Resource Kit. It's not a resource, it's 2 functions that help you turn on the diagnostic and debug logs for DSC and then retrieve the events related to a specific run. This should help you figure out the actual underlying error.
I ran into problems trying to use the xWebsite resource on Windows Server 2008 R2 too. Then I noticed that at the bottom of the documentation page, it says:
Verified on the following platforms
Windows Server 2012: Yes
Windows Server 2008 R2: No
I ended up debugging through the module code outside of DSC. I found that there were several bits that didn't work on 2008R2, and so had to create my own version of the module that worked on that operating system.
Sorry - no easy fix!
Related
We run our domains via Google. We have those domains verified in Azure for various purposes.
What I'd like to accomplish is to allow my user that use O365 to be able sign in with their Google Credentials. As I understand it, this is done through federation, SAML, and SSO. I've followed Google's instruction on setting this up and have hit a snag.
Using PowerShell's Set-MsolDomainAuthentication command I get an error every time I try to change the Authentication method from Managed to Federated. I can confirm that I can see the domains and their managed status via PowerShell commands, so I am at least connected to our Azure.
Set-MsolDomainAuthentication : Unable to complete this action. Try again later.
At line:1 char:1
+ Set-MsolDomainAuthentication
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [Set-MsolDomainAuthentication], MicrosoftOnlineException
+ FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.InternalServiceException,Microsoft.Online.Adm
inistration.Automation.SetDomainAuthentication
Azure logs show the attempt as
DirectoryManagement
Set domain authentication
Failure
Microsoft.Online.Workflows.ValidationException
Any help and direction is welcome. I've been searching high and low for solutions.
Side note: I have tried the convert command as well, with no luck.
Found a solution using this method rather than googles prescribed method.
https://medium.com/#james.winegar/how-to-single-sign-on-sso-between-g-suite-and-office-365-with-g-suite-as-identity-provider-idp-5bf5031835a0
IMPORTANT SIDE NOTE: For some reason or another, you cannot federate multiple domains with the same entityID in Azure. The workaround is to add spaces to the end of the entityID and Location URLs.
In my instance, I edited the metadata.xml and added the space within the quotes. There are two Location URLs in the XML, make the same change in both of them.
IE entityID="https://accounts.google.com/o/saml2?idpid=yourGoogleId "
And Location="https://accounts.google.com/o/saml2/idp?idpid=yourGoogleId "
Repeat this process for each additional domain from the same entityID. Keep in mind this is NOT a supported workaround, so use with caution.
Solution:
Run the following command:
Set-MsolDomainAuthentication -Name <domainName> -Authentication Managed -ActiveLogOnUri <ActiveLogOnUri> -FederationBrandName <FederationBrandName> -PassiveLogOnUri <PassiveLogOnUri> -SigningCertificate <SigningCertificate> -IssuerUri <IssuerUri> -LogOffUri <LogOffUri> -MetadataExchangeUri <MetadataExchangeUri> -PreferredAuthenticationProtocol <PreferredAuthenticationProtocol>
My requirement is as follows:
I have an web API whose port I have removed from the ServiceManifest.xml file. This is done so that I can implement multiple node multiple calls feature from API management. (i.e. I want to remove dependency on port number)
While deploying API management resource files, I am facing issues while deploying apim.json and apim.parameters.json file.
Following is the exception I am getting always.
"Service activation failed. Please look at the details in Activity Log on the left side. In case you are deploying into VNET please make sure prerequisites are followed as described on https://aka.ms/apiminvnet"
There is nothing in the log files when I am uploading.
I am using following link for the deployment and testing. https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-tutorial-deploy-api-management
I am getting exception in running powershell script
New-AzureRmResourceGroupDeployment -ResourceGroupName $groupname -TemplateFile "$templatepath\apim.json" -TemplateParameterFile "$templatepath\apim.parameters.json" -Verbose
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.
We have upgraded windows from 8.1 to 10.
Now in Windows 10 services installed by us are not running.
The same services are running properly if we install these services on Windows 8.1.
ON windows 10, we tried below things which didn't solve the problem.
services-> select service -> properties -> Set [Log on] as LOCAL SERVICE
Set full permission to "perticuler" user or "everyone" user for the folder where service files exist.
Change owner of folder as "everyone", "system" or "perticuler" user where service files exist.
Below is a workaround which works but not feasible for us since it requires password and actually we want to know the actual reason behind this problem.
workaround :
1. services-> select service -> properties -> Set [Log on] as "This account" where user can be selected and it also requires password. Refer attached image.
Please note that the service is a dot net(c#) service and it runs internally a jar file. if it is able to run jar file then only service starts successfully.
Thanks in advance
I have found the cause and solution.
[Cause of problem]
Service unable to understand that, to run JAR file, which program should be run.
[Detail]
I tried to debug the code.
At the location where process is started, popup message like shown in below image is occurred.
location : processSample.Start()
It means that atleast once user need to select the program.
If we select [Java(TM) Platform SE binary] once, then after that the
service always runs successfully.
This behavior is in Windows 10 only.
In addition to program selection, user setting shown in image in question is also required to run the service.
I want to say that, in default program setting already correct program is selected for .jar files as shown in below image, but still windows 10 asks user to select program once.
[Solution]
Run JAR file from windows(c#) service with settings below :
sampleProcess.StartInfo.FileName = "javaw.exe";
sampleProcess.StartInfo.Arguments = "-jar Sample.jar";
sampleProcess.StartInfo.WorkingDirectory = #"C:\SampleFolder";
sampleProcess.StartInfo.UseShellExecute = false;
sampleProcess.EnableRaisingEvents = true;
sampleProcess.StartInfo.CreateNoWindow = false;
Here working directory is the location where the [Sample.jar] does exist.
additinally a Path environment variable must be set in order to execure "javaw.exe".
Before fix I had implementation as below which is not proper for every system environment :
sampleProcess.StartInfo.FileName = "Sample.jar";
sampleProcess.StartInfo.WorkingDirectory = #"C:\SampleFolder";
sampleProcess.EnableRaisingEvents = true;
sampleProcess.StartInfo.CreateNoWindow = false;
We are running TFS and Release Management on premises, and i want to deploy my applications to a remote datacenter.
Access is over the internet, so there is no windows shares available.
I am using the vNext templates, and afaik RM seems to only support unc paths over windows shares.
How can i use Release Management to deploy software to this datacenter?
Im working on this solution:
Use WebDav on a IIS located inside the datacenter.
RM server and Target can use the WebDav client built into windows and access it by an unc path.
I haven't gotten this to work yet, as RM won't use the correct credentials to logon to the webdav server.
Updated with my solution
This is only a proof of concept, and is not production tested.
Setup a WebDav site accessible from both RM server and Target server
Install the feature "Desktop experience" on both servers
Make the following DLL
using System;
using System.ComponentModel.Composition;
using System.Diagnostics;
using System.IO;
using Microsoft.TeamFoundation.Release.Common.Helpers;
using Microsoft.TeamFoundation.Release.Composition.Definitions;
using Microsoft.TeamFoundation.Release.Composition.Services;
namespace DoTheNetUse
{
[PartCreationPolicy(CreationPolicy.Shared)]
[Export(typeof(IThreadSafeService))]
public class DoTheNetUse : BaseThreadSafeService
{
public DoTheNetUse() : base("DoTheNetUse")
{}
protected override void DoAction()
{
Logger.WriteInformation("DoAction: [DoTheNetUse]");
try
{
Logger.WriteInformation("# DoTheNetUse.Start #");
Logger.WriteInformation("{0}, {1}", Environment.UserDomainName, Environment.UserName);
{
Logger.WriteInformation("Net use std");
var si = new ProcessStartInfo("cmd.exe", #"/c ""net use \\sharedwebdavserver.somewhere\DavWWWRoot\ /user:webdavuser webdavuserpassword""");
si.UseShellExecute = false;
si.RedirectStandardOutput = true;
si.RedirectStandardError = true;
var p = Process.Start(si);
p.WaitForExit();
Logger.WriteInformation("Net use output std:" + p.StandardOutput.ReadToEnd());
Logger.WriteInformation("Net use output err:" + p.StandardError.ReadToEnd());
}
//##########################################################
Logger.WriteInformation("# Done #");
}
catch (Exception e)
{
Logger.WriteError(e);
}
}
}
}
Name it "ReleaseManagementMonitor2.dll"
Place it in the a subfolder to The service "ReleaseManagementMonitor"
Configure the shared path as the solution below states.
DO NOT OVERWITE THE EXISTING "ReleaseManagementMonitor2.dll"
The reason that this works is MEF.
The ReleaseManagementMonitor service tries to load the dll "ReleaseManagementMonitor2.dll" from all subfolders.
This dll implements a service interface that RM recognises.
It the runs "net use" to apply the credentials to the session that the service runs under, and thereby grants access to the otherwise inaccessible webdav server.
This solution is certified "Works on my machine"
RM does work only with UNC, you are right on that.
You can leverage that to make your scenario work -
In Theory
Create a boundary machine on the RM domain, where your drops can be copied.
The deploy action running on your datacenter can then copy bits from this boundary machine, using credentials that have access on that domain. (These credentials are provided by you in the WPF console)
How this works
1. Have a dedicated machine on the RM server domain (say D1) that will be used as a boundary machine.
2. Define this machine as a boundary machine in RM by specifying a shared path that will be used by your data centre. Go to settings tab in your WPF console, create a new variable - { Key = RMSharedUNCPath, Value = \\BoundaryMachine\DropsLocation }. RM now understands you want to use this machine as your boundary machine.
3. Make sure you take care of these permissions
RM Server should have write permissions on the \\BoundaryMachine\DropsLocation share.
Pass down credentials of domain D1 to the target machine in the data centre (Domain D2), that can be used to access the share.
4. Credentials can be passed down fron the WPF console, you will have to define the following two config variables in the settings tab again.
Key = RMSharedUNCPathUser ; Value = domain D1 user name
Key = RMSharedUNCPathPwd ; Value = password for the user defined above.
PS - Variable names are case sensitive.
Also, to let RM know that you want to use the SharedUNC mechanism, check the corresponding checkbox for the RM server and connect to it via IP and not DNS name as these must be in different domains, i.e.
Try to use Get-Content on local-server then Set-Content on the remote server passing the file contents over;
Could package everything into an archive of some kind.
The Release Management is copying VisualStudioRemoteDeployer.exe to C:\Windows\DtlDownloads\VisualStudioRemoteDeployer folder on the target server then is copying the scripts from the specified location to target server using robocopy.
So you have to give permissions from your target server to your scripts location.
Release Management update 4 supports "Build drops stored on TFS servers"
http://blogs.msdn.com/b/visualstudioalm/archive/2014/11/11/what-s-new-in-release-management-for-vs-2013-update-4.aspx