I want to define a single configuration that uses Install-Package to install xSystemSecurity and then import it and define a resource that disable IE ESC.
It this possible to do in a single Configuration with a Script Resouce and a xSystemSecurity Resource?
As soon as I try to import xSystemSecurity at the top of the Configuration, DSC blows up because it's not installed yet.
DSC validates all resources in a configuration before it applies any changes. In order to do this, all resources must already be present on the box or available from a pull server. This means that you can't both install and use a resource in the same configuration. The best solution is to use the pull server to deploy the resource. If you can't use the pull server, then you have to use a 2 step process.
Here is an easy way to setup a module repository using a file share http://nanalakshmanan.com/blog/Push-Config-Pull-Module/ Once setup your configuration should work as DSC can pull down the required module from the file share
Related
I have a DSC I am creating for web server configuration. My website will be using HTTPS, meaning that I have to have a certificate in a store. I don't see any modules designed to do this, so I was wondering how I could run regular Powershell functions in a DSC but keep the good parts of the DSC.
My workflow is as follows:
1 . Check if certificate exists
If cert doesn't exist in the store, add it.
If the cert does exist, grab the the Thumbprint to use in the xWeb xWebsite.BindingInfo.MSFT_xWebBindingInformation.CertificateThumbprint property.
As of now, I've got the code written to do the following actions, but I would still like to make use of the [DependsOn] functionality found in DSCs so I can handle any errors involved with creating/accessing the certificate.
Any help is greatly appreciated.
https://serverfault.com/a/638926/236470
Use Microsoft's xCertificate module (with the xPfxImport resource) for this purpose.
Full disclosure: I wrote the original version of this resource (it's open source in Microsoft's repo now and has since had other contributors).
To answer your original question, you would use the Script resource to run arbitrary code without creating your own resource.
I am trying to deploy Powershell modules from my https pull server but couldn't. I don't know what I'm missing here. These are things which I already did or tried:
Setup a https based pull server using instructions outlined at https://msdn.microsoft.com/en-us/powershell/dsc/pullserver
Register a pull client using instructions mentioned here https://msdn.microsoft.com/en-us/powershell/dsc/pullclientconfignames
On my pull server I've placed modules under C:\Program Files\WindowsPowerShell\DscService\Modules as xWebAdministration_1.12.0.0.zip and xWebAdministration_1.12.0.0.zip.checksum
If I double click xWebAdministration_1.12.0.0.zip file it contains: DSCResources, Examples, Tests, HighQualityResourceKitPlan.md, README.md and xWebAdministration.psd1 at root level, Under DSCResources I have all MSFT_* folders and other stuff
When I run a custom configuration on my client node which requires xWebAdministration module, I get module not found exception.
I looked at client's event viewer for errors but don't see anything related.
Any help is appreciated.
Thanks!
Have you tried Publish-DSCModuleAndMof from xPSDesiredStateConfiguration?
You have to run Install-Module xPSDesiredStateConfiguration first.
You can find an example of using this here.
I'm using Visual Studio Online's build tools to deploy web applications from a single solution. I've occasionally been running into file locking issues.
Error: Web Deploy cannot modify the file 'Microsoft.CodeAnalysis.CSharp.dll' on the destination because it is locked by an external process.
After some Googling, I believe the "fix" is to stop the web applications before deployment on Azure and start it back up after. Sounds legit.
However, there does not seem to be a straight forward way to do this directly on VSO's build definitions. I've created an "Azure Powershell" build task, but it wants a PS1 file from the repository. It doesn't seem to let me just run Azure Powershell commands (e.g. Stop-AzureWebsite) from here. My team has created a work-around where we have a "run.ps1" that just executes the command you pass as a parameter, but none of us are satisfied by that.
What are we missing? There has got to be an easier way to do this without having a PS1 script checked into source control.
I solved this by installing Azure App Services - Start and Stop extension from Visual Studio Marketplace.
When installed, it will allow you to wrap the Deploy Website to Azure task in your Release definition with Azure AppServices Stop and Azure AppServices Start tasks, effectively eliminating the lock issues.
Check if you are using "/" on the "Web Deploy Package" path for folder separators instead of "\".
i.e. change
$(System.DefaultWorkingDirectory)/My Project/drop/MyFolder/MyFile.zip
for
$(System.DefaultWorkingDirectory)\My Project\drop\MyFolder\MyFile.zip
I noticed that was the only difference between the one I was getting the error and the others (the Restart step I added was not helping). Once I modified the path, I got it working.
Sounds crappy, but fixed my issue.
Did you use the Build Deployment Template that sets the correct msbuild parameters for you for your package? You can see how here. I would create a build using that template and see if you have the same issues. If so ping me on Twitter #DonovanBrown and I will see if I can figure what is going on.
As a rule it is good practice to have any scripts or commands required to deploy your software to be checked into source control as part of your build. They can then be easily run repeatedly with little configuration at the build level. This provides consistency and transparency.
Even better is to have deployment scripts output as part of the build and use a Release Management tool to control the actual deployment.
Regardless having configuration as code is a mantra that all Dev and Ops teams should live by.
I am using proget to upload packages, I am manually uploading from disk, but when I go to check if the package exists in the feed it isn't there. When I logon to the server which is hosting proget and go to the PackagesRootPath I can see the package is indeed on the server!
Any ideas why it's not showing up in the feed?
p.s. I have restarted the website/application pool and ProGet service and still doesn't work.
If you're not seeing any packages in the web application (and you've verified that they are, in fact, in the right place on disk), this means that the packages aren't getting indexed by the ProGet Service.
Since you've already restarted the ProGet web service, it's likely a problem with the individual package.
Check to see if there are "indexing errors" in the admin section; this will give some insight into what the problem might be. Often times, the file name does not match the package name/version; this is a requirement. If you're package is named MyFoo and is version 3.0.1, it must be MyFoo.3.0.1.nupkg and have an appropriately named MyFoo.nuspec within it.
If there are no errors logged, then you can try to run the service interactively. Simply stop the Windows service, then run the .exe file and select the appropriate option to run.
Another option to verify that the indexing is working OK is to pull a package from a remote connector (like JQuery or something), then drop that package in another feed (that doesn't use a connector).
Is there a way to load a package from an alternative server when Visual Studio Package Manager (NuGet) is responding with a "The remote server returned an error: (503) Server Unavailable" message?
This is an obscure condition that will likely only occur on an "enterprisy" network environment. If these conditions apply you:
you are required to access the Internet via an HTTP proxy server
the HTTP proxy server requires a valid user ID & password (or AD authentication) to allow requests to proceed
you've been messing with cool developer tools that were ported to Windows from a Linux/Unix environment
the new cool tool(s) work after adding the HTTP_PROXY (or possibly HTTPS_PROXY or both) environment variable(s)
you can access the NuGet servers from a browser without getting a 503 error
Then it's likely you broke NuGet by inadvertently invoking this configuration feature. I'm not sure exactly how the environment variable breaks NuGet but I suspect NuGet is detecting & using the http_proxy URL but sending an empty user ID & password which causes the HTTP proxy to reject the request.
Fix: remove the environment variable(s) you added and see if the cool tool can be configured to use an HTTP proxy without them.
Update: Ran into a version of this issue with the NuGet config file referenced in the "this configuration feature" link above. Open this file:
%appdata%\nuget\nuget.config
in your favorite editor. If it contains elements with http_proxy or https_proxy then removing these elements may fix the issue too.
PS: Hopefully I'll get an up vote from Colonel Panic :-)
If you have used the package in the past it is probably in your cache. You can add the local cache as an available package source by going into the Library Package Manager Settings under the Tools menu in Visual Studio. For Visual Studio 2012, choose Tools, Library Package Manager, Package Manager Settings, and then click on Package Sources.
In the Available package sources section, type a name like "Cache" and then in for the source, browse to %LocalAppData%\NuGet\Cache. You may need to use Windows Explorer to translate %LocalAppData%\NuGet\Cache into the full path (usually C:\Users\YourAccountName\AppData\Local\NuGet\Cache).
Once you have the Cache as an available source, you can now use the Package Manager Console (found under the View menu under Other Windows or also under the Tools menu under Library Package Manager).
From the Console (which is a PowerShell window with commandlets for NuGet) you can type "get-help NuGet" to see available commands.
Then using Get-Package, you can get a list of Package ID's. Make sure the "Package source" is set to "Cache" (or whatever you called it) and the Default project is set to the project you need manipulate, both of these are dropdowns located at the top of the Page Manager Console. You can also use the Get-Project to verify you are working against the correct project in your solution.
Finally, you can type Install-Package and when prompted enter the Package ID from the output of the Get-Package commandlet.
i had also this problem, it was becouse of my network.
if you have any blocking on your Internet, (like in companies internet or etc..)
you may not allowed to download the nuget package.
try to download the package in another network, maybe it can help you!
Talbott's answer did not work for me, as my cache was empty. However, if you have used the package in another solution, you can copy the items you want from the "packages" folder in the other solution to a packages folder in your target solution.
If you have no packages installed in the target solution, you may need to add the following to a repositories.xml file in the packages folder:
<?xml version="1.0" encoding="utf-8"?>
<repositories>
</repositories>
After doing that, the packages appeared to be installed in my solution and I was able to add them to projects.
Additional Note: I had to use the "Manage NuGet Packages for Solution" option at the solution level to add the package to individual projects. Using Install-Package from the console still returns a 503 even though the packages is already installed in the solution.
You can also get this error if you are using a VPN client (e.g. Cisco AnyConnect) and you have recently renewed your VPN certificate. The issue can occur after you have updated your certificate, but before you have rebooted. A reboot resolves the issue.
It is a pretty old question, but I have just encountered the same problem. In my case it occurred because I had more than one nuget package source configured in the Visual Studio Package Manager. In my company we use NuGet to get mainstream packages and MyGet for our own stuff.
When I attempted to pull a pretty big package it failed with a 503 code and the error link looked pretty odd, it had MyGet in it istead of NuGet. Turns out Visual Studio package manager tried to pull it from another source despite having NuGet chosen as a current source. Disabling other sources and then proceeding with a download fixed it.
Hopefully it will help somebody who stumbled upon this thread just like I did.
Another possible reason for recieving 503: If you're using Azure DevOps feed, then NuGet packages are limited to 500 MB.