Persistent error with Newtonsoft.Json.JsonReaderException - json

I have been attempting to run commands from the AzureAD powershell module, but I am consistently getting Json errors.
The issue is so persistent no matter what commands I run, I am wondering if the Newtonsoft.Json package is misconfigured and needs to be reinstalled.
Example:
New-AzureADServiceAppRoleAssignment -Id "any id" -ResourceId "any id" -ObjectId "any id" -PrincipalID "any id"
Output:
Error reading JToken from JsonReader. Path '', line 0, position 0
At line:1 char:1
New-AzureADServiceAppRoleAssignment -Id ....
CategoryInfo : NotSpecified: (:) [New-AzureADServiceAppRoleAssignment], JsonReaderException
FullyQualifiedErrorId: Newtonsoft.Json.JsonReaderException.Microsoft.Open.AzureAD16.Powershell.NewServicePrincipalAppRoleAssignment.

I tried in my environment and got successfully created a new app role service principal assignments:
Commands:
Connect-AzureAD
New-AzureADServiceAppRoleAssignment -ObjectId $servicePrincipal.ObjectId -PrincipalId $servicePrincipal.ObjectId -ResourceId $resourceApp.ObjectId -Id $permission.Id
Console:
Portal:
Make sure you are using latest version of Newtonsoft.json.
if you are using lower version, try to uninstall and reinstall the latest version by below command:
Install-Module -Name newtonsoft.json -RequiredVersion 1.0.1.2
If the error is still persisting uninstall AzureAD module reinstall the AzureAD-Module confirm all the traffic can be passed the network policy (Firewall) .
Verify if you are using the latest version of Azure AD PowerShell module? Also, validate if your local machine's firewall is restricting the command? Or if you're connected to any VPN or organizational laptop.
If AzureAD module is already installed, Install new version(2.0.2.140).
Command:
Install-Module -Name AzureAD --Allowclobber
Reference:
Getting error when running script · Issue #2 · adrecon/AzureADRecon (github.com)

Related

AWS Beanstalk Tools for .NET Core - Ignores self-contained parameter in config file

I'm trying to use the Amazon Elastic Beanstalk Tools for .NET Core applications (4.2.2) to publish a net6.0 app to AWS EB (windows). At the time of writing I need to include the net6.0 runtime since net6.0 is not supported on EB yet.
I can successfully publish my app to AWS using the AWS Toolkit for Visual Studio.
The toolkit calls dotnet publish with the following parameters:
Executing: dotnet publish "[my project path]" --output "[my project path]\bin\Release\net6.0\publish" --configuration "Release" --framework "net6.0" --runtime win-x64 --self-contained true
The toolkit creates this config file (aws-beanstalk-tools-defaults.json) following a successful publish:
{
"additional-options" : "",
"application" : "myApp",
"app-path" : "/",
"configuration" : "Release",
"enable-xray" : false,
"enhanced-health-type" : "enhanced",
"environment" : "myApp-test",
"framework" : "net6.0",
"iis-website" : "Default Web Site",
"region" : "eu-west-1",
"self-contained" : true,
"runtime" : "win-x64"
}
However when I try to use the command line utility with the command:
dotnet eb deploy-environment -cfg myConfFile.json
the self-contained and runtime parameters are not passed to the dotnet deploy call resulting in this call:
dotnet publish "my project path]" --output "my project path]\bin\Release\net6.0\publish" --configuration "Release" --framework "net6.0"
I have tried passing the parameters without using the config file as
dotnet eb deploy-environment --profile XXX -c Release -env myApp-test -po --runtime "win-x64"
only to get trigger this exception:
System.InvalidOperationException: Required argument missing for option: --runtime
Is there anyway to use this utility to publish a net6.0 app using self-contained bundled to a windows based EB instance ?
This is a bug/limitation in version 4.2.2 of AWS Beanstalk Tools for .NET Core.
The utility only reads this parameter for non windows environments.
There is however a workaround.
It is possible to pass the win-x64 parameter using the --publish-options parameter like this:
dotnet eb deploy-environment -c Release -cfg myConfFile --publish-options "--runtime win-x64" "--self-contained true"
This will actually result in a warning:
warning NETSDK1179: One of '--self-contained' or '--no-self-contained' options are required when '--runtime' is used.
But the self contained image will still get published. You can actually skip the --self-contained parameter. The result will be the same.

Error while starting ADFv2 Azure-SSIS Integration Runtime

We are trying to start the Azure-SSIS Integration runtime in ADFv2 using the Start-AzureRmDataFactoryV2IntegrationRuntime PowerShell command. The command runs for 20 minutes and then returns the following error: An error occurred while requesting the status of Integration Runtime, but you can manually execute the following command: Get-AzureRmDataFactoryV2IntegrationRuntime -DataFactoryName MyDataFactory -ResourceGroupName MyResourceGroup -Name MyIR –Status. The IR is getting started, but not sure why the command shows this error. Could you let me know how to resolve this?
There seems to be an IR provisioning error, so could you show the complete error message in PSH? Alternatively, the error message can also be found on the IR monitoring page of ADF web app.
I found Azure powershell version 5.1.1 has this issue, and when I upgrade Azure powershell to version 6.6, there is no such issue. you can upgrade to newest Azure powershell.

Error 0x80131047 loading MySQL Connector DLL

PowerShell has just been opened sourced (v6.0.0-alpha.10), and I'm
trying to get it to connect to a MySQL instance from OS X.
Oracle seems to suggest (if I'm reading it correctly) that they have a
.Net Core connector
here.
I ran the install like this:
Install-Package MySql.ConnectorNET.Entity -Destination /MySQL
and the output looked good:
Name Version Source Summary
---- ------- ------ -------
MySql.ConnectorNET.Data 6.8.3.2 nugget ADO.Net driver for MySQL
MySql.ConnectorNET.Entity 6.8.3.2 nugget MySql Connector/NET for Entity Framework 6
When I try loading the assembly like this:
[System.Reflection.Assembly]::Load(/MySQL/MySql.ConnectorNET.Data.6.8.3.2/lib/net45/MySql.Data.dll)
I get the following error (note that I pass the path in with a
variable $dll):
Exception calling "Load" with "1" argument(s): "Could not load
file or assembly
'/MySQL/MySql.ConnectorNET.Entity.6.8.3.2/lib/net40/MySql.Data.dll,
Culture=neutral, PublicKeyToken=null'. The given assembly name or
codebase was invalid. (Exception from HRESULT: 0x80131047)" At
/development/scripts/test.ps1:28 char:1
+ [System.Reflection.Assembly]::Load("$dll")
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : FileLoadException
Any ideas on a workaround / fix? I realize that PowerShell is still in
alpha.
EDIT
I was able to install the MySQL provider using these two commands:
Register-PackageSource -Name nuget.org -ProviderName NuGet -Location https://www.nuget.org/api/v2/
Install-Package MySql.Data.EntityFrameworkCore -Destination /Volumes/Main/libraries/MySQL/ -AllowPrereleaseVersions
I tried registering all the assemblies I could think of:
Microsoft.EntityFrameworkCore.1.0.1/lib/netstandard1.3/Microsoft.EntityFrameworkCore.dll
Microsoft.Extensions.Configuration.1.0.0/lib/netstandard1.1/Microsoft.Extensions.Configuration.dll
Microsoft.Extensions.Configuration.Json.1.0.0/lib/netstandard1.3/Microsoft.Extensions.Configuration.Json.dll
MySql.Data.EntityFrameworkCore.7.0.5-IR21/lib/netstandard1.6/MySql.Data.EntityFrameworkCore.dll
MySql.Data.7.0.5-IR21/lib/netstandard1.6/MySql.Data.dll
But, when trying to create a new MySql object, it still bombs out with
this:
New-Object : Cannot find type [MySql.Data.MySqlClient]:
verify that the assembly containing this type is loaded.
That is not a .NET Core library - the word "Core" here indicates functionality shared between the EF6 and Web packages, and pre-dates the introduction of .NET Core.
Entity Framework Core has MySql libraries under development at the time of writing.
SOLUTION
So, it turns out I was on the (mostly) right track. All of the DLLs need to be loaded. Make life easier by copying them into their own directory, and then load them by iterating over each one:
copy the DLLs to a new location
Get-ChildItem "/Volumes/Main/libraries/mysql/*/lib/netstandard1.*/*.dll" | Copy-Item -Destination "/Volumes/Main/libraries/NEW_mysql" -Force
load all required DLLs
Get-ChildItem "/Volumes/Main/libraries/NEW_mysql" | ForEach-Object {
$path = "/Volumes/Main/libraries/NEW_mysql/" + $_.Name
Add-Type -Path $path -PassThru | Out-Null
}

Error when trying to add subdomain or add databases with cPanel

cPanel is throwing up an error everytime I try to add or edit an existing subdomain. The same error is showing up when I try to add a new database.
Cpanel::AdminBin::_get_cpwrapd_connection could not connect to /usr/local/cpanel/var/cpwrapd.sock
PHPMyAdmin, FTP and SSH are all working perfectly, so the problem is something to do with cPanel. The server is a VPS with GoDaddy. I was installing a program running on Ruby 1.8.7, and this error started showing up after I installed the program. I have tried /scripts/installruby but that's giving me this error:
The internal error was:
(RegexpError) Stack overflow in regexp matcher: /.*((?>\/\*.*?\*\/\s+))
([\w\.\s]+\s* = \s+)?rb_define_(class|module).*?"(Mongrel)"/mx
ERROR: While generating documentation for mongrel-1.1.5
... MESSAGE: Stack overflow in regexp matcher: /.*((?>\/\*.*?\*\/\s+))
([\w\.\s]+\s* = \s+)?rb_define_(class|module).*?"(Mongrel)"/mx
... RDOC args: --ri --op /usr/local/rvm/gems/ruby-1.8.7-p374/doc/mongrel-1.1.5/ri --line-numbers --title Mongrel --main README lib ext CHANGELOG COPYING lib/mongrel/camping.rb lib/mongrel/cgi.rb lib/mongrel/command.rb lib/mongrel/configurator.rb lib/mongrel/const.rb lib/mongrel/debug.rb lib/mongrel/gems.rb lib/mongrel/handlers.rb lib/mongrel/header_out.rb lib/mongrel/http_request.rb lib/mongrel/http_response.rb lib/mongrel/init.rb lib/mongrel/rails.rb lib/mongrel/stats.rb lib/mongrel/tcphack.rb lib/mongrel/uri_classifier.rb lib/mongrel.rb LICENSE README --title mongrel-1.1.5 Documentation --quiet
die [installruby] Failed command: /usr/bin/gem install mongrel-1.1.5.gem --local
exit level [die] [pid=5273] (Failed command: /usr/bin/gem install mongrel-1.1.5.gem --local)
I solved the problem by rebooting cPanel, using /etc/init.d/cpanel restart

Problems using SQL Server 2008 R2 PowerShell extensions outside of SQLPS

I would like to have the SQL Server PowerShell extensions available to me whenever I start PowerShell by loading the snap-ins in my profile.ps1 script. I found an article here with a script example that shows how to do this, and this works fine on my 32-bit Windows XP box.
Unfortunately, on my 64-bit Windows 7 machine, this blows up. If I try to launch this script with the 64-bit PowerShell, I get:
Add-PSSnapin : No snap-ins have been registered for Windows PowerShell version 2.
At C:\Users\xxxx\Documents\WindowsPowerShell\profile.ps1:84 char:13
+ Add-PSSnapin <<<< SqlServerCmdletSnapin100
+ CategoryInfo : InvalidArgument: (SqlServerCmdletSnapin100:String
[Add-PSSnapin], PSArgumentException
+ FullyQualifiedErrorId : AddPSSnapInRead,Microsoft.PowerShell.Commands.AddPSSnapinCommand
If I run this instead in a 32-bit PowerShell, I get:
Get-ItemProperty : Cannot find path 'HKLM:\SOFTWARE\Microsoft\PowerShell\1\ShellIds \Microsoft.SqlServer.Management.PowerShell.sqlps' because it does not exist.
At C:\Users\xxxx\Documents\WindowsPowerShell\profile.ps1:39 char:29
+ $item = Get-ItemProperty <<<< $sqlpsreg
+ CategoryInfo : ObjectNotFound: (HKLM:\SOFTWARE\...owerShell.sqlps:String) [Get-ItemProperty], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetItemPropertyCommand
I'd like to be able to run this in a 64-bit PowerShell if possible. To this end, I tracked down what I thought was the Powershell extension dlls and in a 64-bit Administrator elevated PowerShell I ran:
cd "C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn"
installutil Microsoft.SqlServer.Management.PSProvider.dll
installutil Microsoft.SqlServer.Management.PSSnapins.dll
No dice. Although installutil seemed to indicate success, I still get the "No snap-ins have been registered for Windows PowerShell version 2" error message when I run the script.
Anyone have any suggestions as to where I go from here?
I've used this script without issue on x64 machines. The problem with the x86 invocation is that the script looks for registry keys which on an x64 instance are only accessible from x64 PowerShell. For the x64 invocation you could try registering the snapins since that is the error message you're receiving. Run as administrator...
Change this:
cd $sqlpsPath
Add-PSSnapin SqlServerCmdletSnapin100
Add-PSSnapin SqlServerProviderSnapin100
to this:
cd $sqlpsPath
$framework=$([System.Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory())
Set-Alias installutil "$($framework)installutil.exe"
installutil Microsoft.SqlServer.Management.PSSnapins.dll
installutil Microsoft.SqlServer.Management.PSProvider.dll
Add-PSSnapin SqlServerCmdletSnapin100
Add-PSSnapin SqlServerProviderSnapin100
An even better solution is not use add-pssnapin instead turn sqlps into a module. I have blog post here:
http://sev17.com/2010/07/10/making-a-sqlps-module
Update for SQL Server 2012 - now ships a sqlps module you can install instead of the above blog: http://www.microsoft.com/en-us/download/details.aspx?id=35580
I realise this is a bit of an older question but with a stock standard Windows and SQL Server 2012 install you can just directly use the command Invoke-Sqlcmd without loading anything beforehand as it will auto import the sqlps module. However letting it do that will often cause issues so import the module yourself with the lines below in the same place in your code as you used to use the add-pssnapin commands
$cur = Get-Location
Import-Module 'sqlps' –DisableNameChecking
Set-Location $cur
Similar to that posted on this MS web forum.
The import-module line above changes the current path to something that makes UNC path strings like "\\server\share\path\filename.ext" not work with lots of cmd-lets. So we store the current path before and change it back after the import-module command.
It's possible the snapin assemblies are compiled for x86 only due to dependencies on native 32bit SMO COM objects. If it was possible to run them in a 64bit shell, I'm pretty sure MS would have shipped both x86 and x64 management shells.