I am trying out the new Desired state configuration stuff and trying to work with a new class resource. I have installed the pre-production preview of WMF 5.0 on all servers involved in the process.
I have a Http pull server setup where I have deployed my class resource to.
The target nodes are configured to get their resources from this server which they seem to be doing.
However when I try to push a configuration out to the target nodes that use this class resource I get the following error
Checksum for module DeploymentClass_1.0 doesn't match. Could not install module dependencies needed by the configuration.
+ CategoryInfo : InvalidResult: (root/Microsoft/...gurationManager:String) [], CimException
+ FullyQualifiedErrorId : WebDownloadManagerModuleMismatchChecksum,Microsoft.PowerShell.DesiredStateConfiguration.Commands.GetDscModuleCommand
+ PSComputerName : DDsTest002
I am not sure what the dependencies are that it needs as pretty much the same code wrapped up in the old powershell way of creating a custom resource works fine. Any ideas on how to identify the missing dependencies? Once identified any ideas on how I would make these automatically available to an nodes that require the resources without going and installing a bunch of stuff on each target node that needs them?
Answer Edit - With thanks to Dan1el42
Here is the modified code to generate the checksum that fixed this for me. As Dan suggested just adding the -Force flag to New-DscChecksum command did the trick.
$modulePath='M:\Modules\DeploymentClass'
#get module Version
$content=Get-Content $modulePath\DeploymentClass.psd1
$version=$content[14].Split("'")[1]
$version
$archiveFQN = 'C:\Program Files\WindowsPowerShell\DscService\Modules\DeploymentClass_' + $version + '.zip'
$archiveFQN
Compress-Archive -Path $modulePath -DestinationPath $archiveFQN -Force
New-DscChecksum $archiveFQN -Force
Looks like the checksum file DeploymentClass_1.0.zip.checksum does not match your DeploymentClass_1.0.zip. Please run New-DscChecksum again with the -Force switch.
Related
I am using Get-ChildItem with a path to navigate to a common file share.
I was able to navigate to common file share from my local machine without any issues but when I deploy this code into the PROD server, there I am running into Cannot find path issue.
Power Shell Command:
Get-ChildItem "\\servername.net\abcd\"
Error:
Get-ChildItem : Cannot find path '\\servername.net\abcd\' because it does not exist.
At line:2 char:1
+ Get-ChildItem '\\servername.net\abcd\'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (\\servername.net\abcd\:String) [Get-ChildItem], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand
Not sure if anyone experienced this issue and how to resolve these environmental issues.
Any help is greatly appreciated.
Power shell error
Based on your screenshot, I believe this to be a limitation of Get-ChildItem accessing UNC Paths while the current location is a SqlServer provider. I see a few options:
Map a PSDrive to the UNC path so that Get-ChildItem has a FileSystem provider to work with directly.
New-PSDrive -Name Z -Root "\\servername.net\abcd" -PSProvider FileSystem
Get-ChildItem Z:
Use a different method to retrieve files and directories.
[System.IO.Directory]::EnumerateFileSystemEntries("\\servername.net\abcd")
Use the location stack to go into a FileSystem. Then return to your previous PSDrive.
Push-Location C:
Get-ChildItem "\\servername.net\abcd"
Pop-Location
After evaluating the environments found that these UNC path issues are happening because of Domain differences.
My laptop and archive file share are residing in the same domain, and that's how archiving script was working without any issues.
Whereas the PROD server where I have deployed the script is residing in a different domain.
Resolved the issue by identifying another PROD server with the same domain name as the archive file share and deployed the script using task schedular.
I'm pretty new to TFS and I'm still learning how to use it (so hopefully this isn't just a stupid oversight on my end). I'm working an internship this summer at a seasonal developer position, and essentially my end goal is to automate load testing for the company's website. I'm using TFS to achieve this goal; the build I currently have has two tasks only right now: one to start the controller and the testing environment, and one to stop them. My problem is that the build keeps failing before it really even starts, due to a "term not recognized" error on line 1, specifically caused by what appears to be the default working folder not being recognized.
Here are the relevant log files:
2019-05-30T20:00:02.0942883Z Executing the following powershell script. (workingFolder = D:\RM_agent\_work\11\s)
2019-05-30T20:00:02.0942883Z D:\RM_agent\_work\11\s
2019-05-30T20:00:02.4999117Z ##[error]. : The term 'D:\RM_agent\_work\11\s' is not recognized as the name of a
2019-05-30T20:00:02.4999117Z ##[error]cmdlet, function, script file, or operable program. Check the spelling of the
2019-05-30T20:00:02.4999117Z ##[error]name, or if a path was included, verify that the path is correct and try again.
2019-05-30T20:00:02.4999117Z ##[error]At line:1 char:3
2019-05-30T20:00:02.4999117Z ##[error]+ . 'D:\RM_agent\_work\11\s'
2019-05-30T20:00:02.4999117Z ##[error]+ ~~~~~~~~~~~~~~~~~~~~~~~~
2019-05-30T20:00:02.4999117Z ##[error] + CategoryInfo : ObjectNotFound: (D:\RM_agent\_work\11\s:String)
2019-05-30T20:00:02.4999117Z ##[error] [], CommandNotFoundException
2019-05-30T20:00:02.4999117Z ##[error] + FullyQualifiedErrorId : CommandNotFoundException
I know that the working folder defaults to $(Build.SourcesDirectory), so I'm assuming that D:\RM_agent\_work\11\s is what $(Build.SourcesDirectory) evaluates to. RM_agent is obviously an agent, so /_work/11/s should be the local path where it stores the source code. Why is it unrecognized then?
I tried manually setting the working folder for the scripts through tfs to the folder where the build is stored, but the build still failed and the logs still showed that workingFolder = D:\RM_agent\_work\11\s.
Additionally, the line of code that the build is failing on, Executing the following powershell script. (workingFolder = D:\RM_agent\_work\11\s), is nowhere in the script I am trying to execute, which confuses me. Where is this script coming from?
(I can remove this if it doesn't fit the guidelines/is off topic, but if anyone could point me towards any resources about tfs and/or load testing it would be massively helpful as well)
EDIT: Here is the powershell script for the first task
########################################
# start environment
########################################
# import modules
Import-Module '\\neenah-san1\TSbuild\Deployment\Tools\PowerShell\Azure\JJK.TS.Azure.psm1' -Force -Prefix 'TS'
# provide azure credentials
$credential = Get-Credential
# login to azure subscription
Login-AzureRmAccount -Credential $credential
# start the controller
Get-AzureRmVM -ResourceGroupName 'TS-LoadTest-TST' | Where-Object {$_.Name -match 'vstc'} | Start-TSAzureVM -Credential $credential
# wait for controller to fully start
Start-Sleep -Seconds 120
# start the agents
Get-AzureRmVM -ResourceGroupName 'TS-LoadTest-TST' | Where-Object {$_.Name -match 'vsta'} | Start-TSAzureVM -Credential $credential
# check status of all servers
Get-AzureRmVM -ResourceGroupName 'TS-LoadTest-TST' -Status | Sort-Object -Property Name | Select-Object -Property Name, PowerState | Format-Table -AutoSize
Solution structure:
EDIT 2: [RESOLVED] It's all fixed now, thank you! I went into the repository and mapped the folder my scripts were in directly to $(build.sourcesDirectory). Consequently I was able to change the file path to $(build.sourcesDirectory)\StartControllerAndAgents.ps1 and the build is now able to find the files to run.
You need to specify the path to the script as $(Build.SourcesDirectory)\Path\To\Script. Not the TFVC path which you've configured now $/Project/Path/To/Script.
The exact path depends on the workspace mapping of the build definition.
The same applies to the working directory.
There are a number of variables in Azure Pipelines (the current name for the Build hub in TFS/Azure DevOps) that resolve to different standardized paths on the agent. Almost all tasks take a relative path off of those variables.
I'm trying to load a .dll of itext7, but if I use this
Add-Type -Path "D:\Eigene\Packages\itext7.7.1.5\lib\net40\itext.kernel.dll"
I get the following exception (translated from german):
Add-Type : Add-Type : Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
In Zeile:2 Zeichen:1
+ Add-Type -Path "D:\Eigene\Packages\itext7.7.1.5\lib\net40\itext.kerne ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Add-Type], ReflectionTypeLoadException
+ FullyQualifiedErrorId : System.Reflection.ReflectionTypeLoadException,Microsoft.PowerShell.Commands.AddTypeCommand
When I use:
try { Add-Type -Path "D:\Eigene\Packages\itext7.7.1.5\lib\net40\itext.kernel.dll" }
catch { $_.Exception.LoaderExceptions }
It says (also translated from german):
The File or Assembly "BouncyCastle.Crypto, Version=1.8.1.0,
Culture=neutral, PublicKeyToken=0e99375e54769942" or a dependency of
it was not found. The system can not find the specified file.
How can I fix this?
EDIT:
I found a BouncyCastle dll on my system that it also downloaded when I installed the itext7 package but it also doesn't work, if I load "D:\Eigene\Packages\Portable.BouncyCastle.1.8.5\lib\net40\BouncyCastle.Crypto.dll" before i load the itext.kernel.dll.
Your assembly is looking for a different version than you have.
I'm not sure if you can do an assembly binding in powershell like you could with an application where you could bind an older assembly to a new one example:
https://learn.microsoft.com/en-us/dotnet/framework/deployment/configuring-assembly-binding-redirection
Your error is asking you to load the dll of version 1.8.1.0 with the public token of: PublicKeyToken=0e99375e54769942
Generally the assembly publisher isn't changing their public token although it is technically possible bouncy castle could so you likely don't need to specify that.
Anyway you need to find the older version (seems like you have 1.8.5). It is likely these are compatible, but best / safest bet is to use the same assembly the one you are loading needs.
You may find some help here if you need to do binding redirection to the newer assembly: Powershell - Assembly binding redirect NOT found in application configuration file
I have Windows 10 / Windows 2016 TP5 (PowerShell 5.1). I want to use a PowerShell DSC module from GitHub in my configuration, for example xTimeZone.
What shall I do to be able to reference it with Import-DSCResource?
It's the first time I try to add a module other than from an installer-based product and maybe I am missing something obvious. Isn't there a git clone-based procedure like pip or gem utilise?
I verified the value of $env:PSModulePath and it has two directories defined: C:\Users\techraf\Documents\WindowsPowerShell\Modules;C:\Windows\system32\W
indowsPowerShell\v1.0\Modules.
I copied the contents of xTimeZone directory to C:\Users\techraf\Documents\WindowsPowerShell\Modules.
PowerShell does not see it. Tried to copy on different levels of the repository - all failed.
When running the example script I get:
At line:12 char:4
+ Import-DSCResource -ModuleName xTimeZone
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Could not find the module 'xTimeZone'.
At line:16 char:9
+ xTimeZone TimeZoneExample
+ ~~~~~~~~~
Undefined DSC resource 'xTimeZone'. Use Import-DSCResource to import the resource.
+ CategoryInfo : ParserError: (:) [], ParseException
+ FullyQualifiedErrorId : ModuleNotFoundDuringParse
Per advice from the answer, after moving the module from C:\Users\techraf\Documents\WindowsPowerShell\Modules to C:\Windows\system32\W
indowsPowerShell\v1.0\Modules the first error disappeared and I get only:
At line:16 char:9
+ xTimeZone TimeZoneExample
+ ~~~~~~~~~
Undefined DSC resource 'xTimeZone'. Use Import-DSCResource to import the resource.
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : ResourceNotDefined
About DSC resources
DSC resources are, in essence, specialised PowerShell modules. The resource module must export Get, Set and Test-TargetResource commands (another option is available with PowerShell 5, but out of scope in the context of xTimeZone).
Resources are always deployed in the following structure:
<Modules>\<ModuleName>\DSCResources\<ResourceName>
Get-DscResource looks for "modules" inside the DSCResources folder, as a sub-folder of an existing module. If it can't see the resource you cannot use it.
xTimeZone
xTimeZone consists of:
A PowerShell module which contains little more than a manifest and some examples.
A DSC resource named xTimeZone.
Windows PowerShell cannot find the resource unless it's correctly deployed. These instructions apply for downloading the module.
Select the master branch and download the zip of the repository from: https://github.com/PowerShell/xTimeZone/tree/master
Extract the zip file to a folder.
Rename xTimeZone-master to xTimeZone.
Copy xTimeZone to C:\Program Files\WindowsPowerShell\Modules
Verify you can discover the DSCResource:
Get-DscResource
If, for some reason, you're having problems with Program Files\Modules, you might use:
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\
However, as this area is part of the operating systems files it's a lower preference.
Configuration
Once you can discover the resource, you need to import it into each Configuration element in which you wish to use it.
Configuration SomeConfiguration {
Import-DscResource -ModuleName xTimeZone
# Nodes statement follows
}
*Not trying to answer, just wanted to put in additional feedback, but don't have enough stack-street-cred to add a comment...
Depending on the DSC you're trying to use, sometimes you have to copy the content from the "source" folder (that contains aforementioned "modules" and "DSCResources" sub folders) up to the root of the dscname you're trying to work with. In my instance I was using the SqlServerDsc (url below) and am not overly versed so it took a while to figure out what was going on.
https://github.com/dsccommunity/SqlServerDsc
I initially followed directions provided on github of extracting the zip to a PS accessible directory, but nothing new was accessible via get-dscresource. After seeing the syntax outlined by the poster above, I gave manually copying the content of the DSC's source folder to the modules/SqlServerDsc root a try, and everything came back gravy fries.
All I needed was to refresh my resource since some new methods came out and couldn't remember how I did it before... This is definitely different.
I'm trying to deploy my first web part on 2010. I developed a web part using VS2008 and tested it on SP2007.
I copied the CAB to the 2010 server and tried to use the power shell to install it:
PS C:\Users\sa_portalt> Install-SPWebPartPack -LiteralPath "c:\transfer\webparts\redirectwebpart.cab" -Name "RedirectWebPart"
Install-SPWebPartPack : Parameter set cannot be resolved using the specified named parameters.
At line:1 char:22
+ Install-SPWebPartPack <<<< -LiteralPath "c:\transfer\webparts\redirectwebpart.cab" -Name "RedirectWebPart"
+ CategoryInfo : InvalidArgument: (:) [Install-SPWebPartPack], ParameterBindingException
+ FullyQualifiedErrorId : AmbiguousParameterSet,Microsoft.SharePoint.PowerShell.SPCmdletInstallWebPartPack
What am I doing wrong? Is this the right way to install web parts?
If you can, I recommend you upgrade to Visual Studio 2010 which has built-in support for SharePoint 2010. When you build a project built from the SharePoint template it will create the wsp for you. You can also immediately deploy to the local server from VS2010 so you never need to get into PowerShell on your local development machine.
When you need to deploy to a different server, you can then run
Add-SPSolution -LiteralPath C:\webparts\MyWebPart.wsp to add the solution to Central Administation
and then
Install-SPSolution -Identify MyWebPart.wsp -WebApplication http://mySharePointserver to deploy the solution to the specified web application
This was the first article I found that provided the actual answer, however, in the Install-SPSolution, there is a typeo, the -Indentify parameter should be -Identity
Also, in most cases (if adding to the GAC) need to add the -GACDeployment to the Install-SPSolution.
So the line should look like:
Install-SPSolution -Identity BasicWebPart.wsp -WebApplication http://vsp -GACDeployment