I'm trying to get Microsoft's PKI module imported to powershell on some offline 2008 servers, yes, 2008 :(, (don't ask)
I copied the module, PKI, from the source machine's modules directory to the target machine. Confirmed that the target directory for PKI is in $env:PSModulePath
Executed Import-Module on the target machine and:
import-module : The module to process 'Microsoft.CertificateServices.PKIClient.Cmdlets', listed in field 'NestsedModules' of module manifest 'C:\windows\sysstem32\Windows\Powershell\v1.0\Modules\pki\pki.psd1' was not processed because no valid module was found in any module directory.
Source Machine is 2016, PSVersion 5.1.14393.5127
Target Machine is 2008R2, PSVersion 5.1.14409.1005
Thanks in advance if anyone knows why this isn't working.
Related
Recently, I tried to create self-signed certificate for Azure Service Factory accordingly with Microsoft's manual:
Azure Docs: Secure a Service Fabric cluster, step 2.5, 02/05/2016
But command Invoke-AddCertToKeyVault failed with the next error:
Invoke-AddCertToKeyVault : The term 'Invoke-AddCertToKeyVault' is not
recognized as the name of a cmdlet, function, script file, or operable
program. Check the spelling of the name, or if a path was included,
verify that the path is correct and try again.
I think that Azure Powershell successfully installed on my machine because I was able to login into my Azure account by running Login-AzureRmAccount. Also $env:PSModulePath says that Azure Modules path added to path variable (accordingly with the article: Azure Docs: How to install and configure Azure PowerShell, 04/22/2016). Here they are:
...\Microsoft SDKs\Azure\PowerShell\ResourceManager\AzureResourceManager\;
...\Microsoft SDKs\Azure\PowerShell\ServiceManagement\;
...\Microsoft SDKs\Azure\PowerShell\Storage\;
Also, I have restarted my PC after installing Azure PowerShell.
It is possible that I have missed something, but I am stuck with it. How could it be resolved?
That commandlet is in the package that should be imported -
Import-Module "C:\Users\chackdan\Documents\GitHub\Service-Fabric\Scripts\ServiceFabricRPHelpers\ServiceFabricRPHelpers.psm1"
That is its implementation, by the way, for a reference that it even exists :). Try Import-Module and it should work.
I want test my storage driver using fuzzing techniques and I choosed Microsoft tool called IoAttack that is represent as test case in WDK 8.1 and not standalone application like in previous versions of WDK. This tool work with IoSpy tool that gather all IOCTLs and WMI command that are send to the driver. IoSpy attach to driver stack as filter driver and record all traffic. Problem occurs after I successfull attach IoSpy, record all data than remove IoSpy and run IoAttack. Because IoAttack do not see my device that is created by my storage driver I cannot fuzz my driver. Below are steps and configurations that I use.
Any tip or solution will be very welcome :)
[Setup steps for test machine:]
Install driver that created storage device
Install package "WDK Test Target Setup"
default location: C:\Program Files (x86)\Windows Kits\8.1\Remote\x64
default location on machine that has WDK 8.1 component installed
installation command: msiexec /i "WDK Test Target Setup x64-x64_en-us.msi"
2.1 If your target computer is running Windows Server, find the DriverTest folder that was just created by WDK Test Target Setup MSI. (Example: c:\DriverTest). Right click the DriverTest folder, and choose Properties. On the Security tab, give Modify permission to the Authenticated Users group.
Install package Test Authoring and Execution Framework (TAEF)"
default location: C:\Program Files (x86)\Windows Kits\8.1\Testing\Runtimes
default location on machine that has WDK 8.1 component installed
installation command: msiexec /i "Test Authoring and Execution Framework x64-x64_en-us.msi"
Install package "WDTF runtime library"
default location: C:\Program Files (x86)\Windows Kits\8.1\Testing\Runtimes
default location on machine that has WDK 8.1 component installed
installation command: msiexec /i "Windows Driver Testing Framework (WDTF) Runtime Libraries-x64_en-us.msi"
installation verification:
Open a Command Prompt window on the test computer.
Run %WDTFDir%\Tools\CheckWDTFInstall.cmd
default location: C:\Program Files (x86)\Windows Kits\8.1\Testing\Runtimes\WDTF
Open the log file CheckWDTFInstall.log and examine the results which contains information on all installed WDTF components
Setting mode "kernel debugging"
steps:
Open a Command Prompt window as Administrator. Enter bcdedit /debug on
If the computer is not already configured as the target of a debug transport, enter bcdedit /dbgsettings local
Reboot the computer.
[Test procedure that uses IoSpy and IoAttack:]
Enable IoSpy using WDK test "EnableIoSpy" and application "TAEF"
command:
Te.exe "%SystemDrive%\Tests\Additional
Tests\DeviceFundamentals\ERT\Basic\Devfund_IOSpy_EnableSupport_ERT_Basic.wsc"
/select:"#Name='Devfund::EnableIoSpy'"
/p:"DQ=INF::OriginalInfFileName='my_storage_driver.inf'"
/p:"DFD=%systemdrive%\DriverTest\IoSpy"
/rebootStateFile:%SystemDrive%\DriverTest\Logs\DriverTestReboot.xml
/enableWttLogging
/wttDeviceString:$LogFile:file="%SystemDrive%\DriverTest\Logs\Enable_I_O_Spy_(Quick)_(possible_reboot)_00000.wtl",writemode=append,encoding=unicode,nofscache=true,EnableLvl="WexStartTest|WexEndTest|WexXml|WexProperty|WexCreateContext|WexCloseContext|*"
/runas:Elevated
Reboot operating system
Use IOCTL commands for public and private IOCTLs
Verify that IoSpy data file that records the data sent throught IOCTL and WMI requests to drivers for devices enabled for fuzz tests is larger that initial 1 KB size (if not data acquiring failed for specific driver)
default location for IoSpy data file: %SystemDrive%\DriverTest\IoSpy
Disable IoSpy using WDK test "DisableIoSpy" and application "TAEF"
command:
te.exe "%SystemDrive%\Tests\Additional
Tests\DeviceFundamentals\ERT\Basic\Devfund_IOSpy_DisableSupport_ERT_Basic.wsc"
/select:"#Name='Devfund::DisableIoSpy'"
/rebootStateFile:%systemdrive%\DriverTest\Logs\DriverTestReboot.xml
/enableWttLogging
/wttDeviceString:$LogFile:file="%systemdrive%\DriverTest\Logs\Disable_I_O_Spy_(Quick)_(possible_reboot)_00000.wtl",writemode=append,encoding=unicode,nofscache=true,EnableLvl="WexStartTest|WexEndTest|WexXml|WexProperty|WexCreateContext|WexCloseContext|*"
/runas:Elevated
Reboot operating system
Run I/O Attack (Quick) fuzzer using WDK test "RunIoAttack" and application "TAEF"
command:
te.exe "%SystemDrive%\DATA\Tests\Additional
Tests\DeviceFundamentals\ERT\Basic\Devfund_IOAttack_ERT_Basic.wsc"
/select:"#Name='Devfund::RunIoAttack'"
/p:"DQ=DeviceID=’my_device_id_that_was_created_by_my_storage_driver"
/rebootStateFile:%SystemDrive%\DriverTest\Logs\DriverTestReboot.xml
/enableWttLogging
/wttDeviceString:$LogFile:file="%SystemDrive%\DriverTest\Logs\Run_I_O_Attack_(Quick)_00001.wtl",writemode=append,encoding=unicode,nofscache=true,EnableLvl="WexStartTest|WexEndTest|WexXml|WexProperty|WexCreateContext|WexCloseContext|*"
/runas:Elevated
[Issue:]
Microsoft fuzzer IoAttack that is ran as test from WDK does not see my_storage_driver. Test pass because no devices we found for testing. Output from test:
*
StartGroup: Devfund::RunIoAttack Property: TAEF: Description [Runs I/O
Attack. ] WDTF_TARGETS: - Query("IsDevice AND IoSpy::") WDTF_TEST: No
devices were found for testing EndGroup: Devfund::RunIoAttack [Passed]
Summary: Total=1, Passed=1, Failed=0, Blocked=0, Not Run=0, Skipped=0
*
Command that was used to run test using WDK application "TAEF" (te.exe)
te.exe "%SystemDrive%\Tests\Additional
Tests\DeviceFundamentals\ERT\Basic\Devfund_IOAttack_ERT_Basic.wsc"
/select:"#Name='Devfund::RunIoAttack'"
/p:"DQ=DeviceID=’my_device_id_that_was_created_by_my_storage_driver’"
/rebootStateFile:%SystemDrive%\DriverTest\Logs\DriverTestReboot.xml
/enableWttLogging
/wttDeviceString:$LogFile:file="%SystemDrive%\DriverTest\Logs\Run_I_O_Attack_(Quick)_00001.wtl",writemode=append,encoding=unicode,nofscache=true,EnableLvl="WexStartTest|WexEndTest|WexXml|WexProperty|WexCreateContext|WexCloseContext|*"
/runas:Elevated
[Additional information:]
I tried to address my driver / storage device for fuzzing test using DQ=DeviceID, DQ=INF::OriginalInfFileName (like in IoSpy case) but in the end doesn't work.
Procedure source for usage of IoSpy and IoAttack is from https://msdn.microsoft.com/en-us/library/windows/hardware/ff547271
[Test machine setup:]
- Windows Server 2012 R2 Standard Build 9600 (x64)
[Software setup:]
- WDK 8.1 installed on Windows 7 Professional (x64)
Im trying to install AX 2012 Async server on a machine with
OS: Windows Server 2012 R2
IIS:8.5
One of the prerequisites gives me the following error as shown in the screenshot
I have installed the script with the command Import-Module C:\"Path to Module" -Verbose (as mentioned in the above image), however still the prerequisite persists I have tried restarting the server. But to no avail.
This is the screenshot of running the command:
I think the command is not being run successfully , The alternative version of the command AddPSSnapin throws an error. What seems to be the issue here?
EDIT: This is the log file prerequisite check:
2016-02-15 16:17:25Z Performing a check for pre-requisite 'Web Server (IIS) Administration module'.
2016-02-15 16:17:29Z Check if WebAdministration module is available
2016-02-15 16:17:29Z No
2016-02-15 16:17:29Z Trying to add snapin for older version of Windows.
2016-02-15 16:17:29Z Unable to import web administration module or snapin. Please install the IIS web administration module or snapin for PowerShell
AS shown here it seems to be trying to add snapin and then failing the prerequisite.
For some reason the PSModulePath system environment variable doesn't seem to be set on your server. Because of that you can load the module when you specify its full path, but not when you specify just the name (Import-Module WebAdministration). The prerequisites check of the installer most likely checks the presence of the module by name as well, since $env:PSModulePath usually contains more than one location, and it shouldn't matter which of them actually contains the module.
Set the system environment variable PSModulePath to %SystemRoot%\system32\WindowsPowerShell\v1.0\Modules and the problem should disappear.
I have built a Windows service app that's installed and running. During debugging while the service is running, I have found that when I import the properties.settings.default and modify it, it is not saved to the app.config file in my project folder. I could not find this app.config file in [user]/%appdata%/Local/ either..
Where does properties.settings.default.save() save to?
I'm running Windows 7 if that helps.
You will find the APPDATA folder for system accounts at:
C:\windows\system32\config\systemprofile
Or (for x86 apps on Win7 64):
C:\Windows\SysWOW64\config\systemprofile
I'm getting this error in Windows 7 64 bits:
An error occurred creating the configuration section handler for '': That assembly does not allow partially trusted callers.
This happens when I try to read a config section, the section is mapped to a class that is in a DLL in the GAC, I'm using Visual Studio 2010 targeting the framework 3.5, I'm in a domain and the exe is running from a network share, the exe is signed.
This is failing only on Windows 7, an XP Machine can run the app just fine from the same network share, I'm using my domain account on both machines.
Does anyone know why this is failing on Windows 7?, thanks a lot for your time.
Having bumped into similar trouble when our IT department did a stealth upgrade of users' machines to Windows 7, I suspect you may need to update the trust level with caspol.exe
For XP we would normally run:
%windir%\Microsoft.NET\Framework\v2.0.50727\CasPol.exe -q -m -ag 1.2 -url file:\\s:\* FullTrust
but now with Win7 it has changed to:
%windir%\Microsoft.NET\Framework64\v2.0.50727\CasPol.exe -q -m -ag 1.2 -url file:\\s:\* FullTrust
I Fixed using this command:
caspol -cg 1.2 FullTrust
The Intranet Zone had the LocalIntranet permissions set, (don't know why it was LocalIntranet, it should be FullTrust).
Thanks to dreynold.