I am getting the following error when running this command:
Get-dbaDatabase -sqlinstance server01 -NoFullBackup
Error:
Compare-DbaCollationSensitiveObject : Cannot bind argument to parameter 'Value' because it is null.
At C:\Program Files\WindowsPowerShell\Modules\dbatools\1.1.76\allcommands.ps1:22322 char:109
+ ... bject -Property Name -In -Value $lastCopyOnlyBackups.Database -Collat ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (:) [Compare-DbaCollationSensitiveObject], ParameterBindingValidationExcept
ion
+ FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Compare-DbaCollationSensitiveObject
This happens on multiple versions of dbatools, I don't think it is related to dbatools at all. When I run this on another account that has a profile created long ago I get no errors. New account profiles seem to have this error show up. I am thinking it may be related to a setting in PowerShell but I am not sure what it could be.
On an older account profile the command just returns nothing, basically a blank line. The newer accounts all return this error. I have run this command on machines ranging from Windows Server 2012 through Windows Server 2019.
I did try to use an account that worked on an older server on a new server and in that case I do get the error above. It seems to be related to when the profile was created, which makes me think there is some default setting or behavior that is being set at the group policy or machine policy level.
PowerShell version is 5.1.
I am hoping there are some PowerShell experts out there that can point me in the right direction.
Thanks!
This has been acknowledged as a bug in the function by the dbatools team. This is fairly new functionality that was implemented in late 2021. This should get fixed in a future update to dbatools.
Related
I am trying to login in Azure SQL active password authentication using cloudhsell
below is the error I am facing mentioned in the screen shot.I am not able to understand is this the authentication issue or syntax issue in my script.
$cxn.open will open the connection but before that only I am facing issue.
After that I need to exectue the below commands
$cmd = New-Object System.Data.SqlClient.SqlCommand($query, $cxn)
$cmd.CommandTimeout = 120
$cmd.ExecuteNonQuery()
$cxn.Close()
Objective is to login to Azure SQL using active password auth and write some SQL query and close the connection.This thing I need to do in devops inline script task but it is falling in cloudshell itself.
Error - detail mentioned in the below diagram, please let me know how to correct it.
Kindly let me know is there any other script is there.
I'm not sure if this will fix all your issues, but there is a syntax error there.
In your connection string you put authentication="Azure Active Directory""
that is a syntax error because your double quote actually ends the string...
get rid of the "" around the azure active directory. like. authentication=Azure Active Directory";
that would at least get rid of the syntax error.
try to use Microsoft.Data.SqlClient
I've created a package that gets some information from a sql database and inserts them into Dynamics CRM.
When testing the package from Visual Studio everything goes as expected and the task finishes without any errors and the rows get inserte . However , when I publish the package to SSISDB on Sql Server the package fails with this error :
KingswaySoft.IntegrationToolkit.DynamicsCrm.CrmServiceException : CRM service call returned an error : A password is required in order to establish the connection ...
I tried changing the package protection level to EncryptSensitiveWithUserKey but it still gives the same message as above , created the package again from scratch still doesn't work . This package was working before , maybe there's something I did the last time in configuration which made it work but I cannot replicate it anymore .
Also I tried the Integrated Authentication it says this :
KingswaySoft.IntegrationToolkit.DynamicsCrm.CrmServiceException : CRM service call returned an error : The caller was not authenticated by the service .
#Drinv, this is a typical SSIS runtime deployment issue. You need to make sure that you have provided a password for your job configuration for the connection manager. What you provided to the package doesn't count as far as sensitive fields are concerned (password being one) when you are using the EncryptSensitiveWithUserKey option since user key is not transferrable between different systems or different users. An easy workaround is to change your SSIS package/project's ProtectionLevel setting to encrypt using a password instead, although it may not be the best practice. If you still have trouble getting this going, please reach out to us directly, our team can walk you through the issue.
I found out what I was doing wrong .
My SSIS project was on Project Deployment Model and I was trying to deploy only the package. After making my connections available on project level and deploying the whole project everything worked as expected .
I am trying to install HP SSC but during installation when I reach the "seed process template" I get the error shown in the screenshot. I need help on this. Thanks
If your database connection is successful then there can be only one reason of failure this connectivity.
-Database collation is not set properly (Note: in older version it was optional but in new version you have to set it case sensitive (It must be having something like CS rather CI in its name)
If it didn't resolve your issue then please paste your code here.
How do I resolve this issue with requests to msmdpump.dll for connections to SQL Server Analysis Services? I am receiving a 500 Error from the IsapiModule.
On a Windows Server 2012 R2 machine, with IIS 8.5, I have setup the OLAP data pump (msmdpump.dll), using the following instructions: https://msdn.microsoft.com/en-us/library/gg492140.aspx#bkmk_copy
The application pool is configured for .NET CLR v4.0, with Classic Managed pipeline mode. The identity is set to a local service account. (I have also tried a domain account, and I have tried making the local user an Administrator).
I've created an application under the Default Web Site, called OLAP, with an IsapiModule, as per the MSDN article.
As far as I can tell (and I've double and triple checked), everything is configured as laid out in the MSDN article. Also, compared to another server where I have this setup (on a different network), it is essentially the same.
When I request http://localhost/OLAP/msmdpump.dll in a browser on that machine, I receive a 500 Internal Server Error. The error indicates that it is trying to use the OLAP handler that I created. This is not the same error that I would normally expect when doing a GET request to msmdpump.dll. The normal error for a straight GET, when everything is working correctly, is sent back in a SOAP envelope. In my case, the request does not appear to ever be processed by msmdpump.dll.
500 Internal Server Error via browser:
(see below for full screenshot)
Module IsapiModule
Notification ExecuteRequestHandler
Handler OLAP
Error Code 0x8007007e
Requested URL http://localhost:80/OLAP/msmdpump.dll
Physical Path C:\inetpub\wwwroot\OLAP\msmdpump.dll
Logon Method Anonymous
Logon User Anonymous
500 Internal Server Error via SSMS connection:
I also receive an error when trying to connect to the data pump via SQL Server Management Studio:
Screenshot of the 500 error in the browser:
One appreciable difference between the machine I'm setting up, and the server where the data pump already works, is that there are a few more roles setup on the new server.
The problem server includes:
.NET Extensibility 4.5
ASP.NET 4.5
While the other machine (where the data pump works), does not include those roles. Would the presence of ASP.NET 4.5 or .NET Extensibility 4.5 cause an issue with IIS serving requests for this IsapiModule?
Quick answer
In my case installing KB3138367 (https://support.microsoft.com/en-us/help/3138367/update-for-visual-c-2013-and-visual-c-redistributable-package) resolved the issue.
Longer answer
There are a few debugging steps that can be useful.
Configure IIS tracing
For full instructions see: https://learn.microsoft.com/en-us/iis/troubleshoot/using-failed-request-tracing/troubleshooting-failed-requests-using-tracing-in-iis
However, you can ignore the parts where it tells you to delete your existing content - they're going a little overboard there to ensure you get the same results in the tutorial. Just add the failed request tracing to your existing site, catching "500" status codes.
In my case, that led me to the result:
ModuleName IsapiModule
Notification EXECUTE_REQUEST_HANDLER
HttpStatus 500
HttpReason Internal Server Error
HttpSubStatus 0
ErrorCode The specified module could not be found. (0x8007007e)
I confirmed that my handler mappings had the correct path to msmdpump.dll, but still got the error. So time for the next debugging step:
Use Sysinternal Process Monitor to check w3wp.exe
Process monitor is a free tool from Microsoft: https://learn.microsoft.com/en-us/sysinternals/downloads/procmon
Use Process Monitor to log file system access (filter on the "w3wp.exe" process to avoid being overwhelmed)
Look for NAME NOT FOUND and PROCESS NOT FOUND results. There will be a number of these as the system attempts to e.g. locate various dlls, so it is normal to see some NOT FOUND results followed by SUCCESS results for the same filename. You are looking for NOT FOUND results that do not have any corresponding SUCCESS results.
In my case, this highlighted two dlls:
msvcr120.dll
msvcp120.dll
These turn out to be part of the “Microsoft Visual C++ 2013 Redistributable” package (https://superuser.com/questions/1163409/msvcp120-dll-and-msvcr120-dll-are-missing).
However, "Add/Remove Programs" showed that the package was already installed. Running "repair" on the package did not resolve the issue.
Locating the dlls
In my case, the OLAP pump is installed an a web server separate from Analysis Services.
Running these powershell commands:
Get-ChildItem -Path 'C:\' -Recurse -File -Filter 'msvcr120.dll' -ErrorAction SilentlyContinue | select -ExpandProperty DirectoryName
Get-ChildItem -Path 'C:\' -Recurse -File -Filter 'msvcp120.dll' -ErrorAction SilentlyContinue | select -ExpandProperty DirectoryName
yielded some interesting results. On the web server, the dlls only showed in C:\Windows\SysWOW64.
However, on the server where Analysis Services was installed, the dlls were present in both C:\Windows\System32 and C:\Windows\SysWOW64 (as well as a few other sql server paths)
(as an aside, SysWOW64 contains 32 bit dlls, and System32 may contain 64 bit dlls. So simply copying from SysWOW64 to System32 is likely to cause you problems. See https://www.howtogeek.com/326509/whats-the-difference-between-the-system32-and-syswow64-folders-in-windows)
I could see from the Process Monitor logs on the web server that one of the search paths was C:\Windows\System32. A little more searching led to KB3138367 (Installing both Visual Studio 2013 Redistributable packages (x86 & x64) at the same time)
The actual KB text (https://support.microsoft.com/en-us/help/3138367/update-for-visual-c-2013-and-visual-c-redistributable-package) describes the issue:
When you install an updated redistributable package, binaries for
non-target architectures are removed. For example, after you install
an update for an x86-based application, the x64 Visual C++ 2013
runtime libraries are missing. This fix makes sure that both versions
of the Visual C++ redistributable are visible when you add or remove
programs after installation of the update.
You should probably disable Anonymous Authentication on IIS
This is the perfect article, as expected to see on stackoverflow! I even thought that this case is also mine, but thorough checks shown my problem was crushing msmdpump.dll, and that crash was an exception, caught internally by msmdpump.dll. The only visible clue was a message in Windows Application log stating "an internal error happened" (or smth. alike). Googling alot didn't bring any valuable results, but suddenly this article gave me an idea to check for the LATEST MSQL cumulative update from here, and, after installing it and re-coping msmdpump.dll the crash was gone and cubes finally shown up as expected in SSMS interface. Needless to say that all issues with IIS Identity Pool, double-hop and other security-related stuff was rechecked many times with no success... Realizing that exception is inside the dll itself take some time to come...
I have just restored a .bacpac file into a local SQL server instance (64b v12.0.4213), the backup is from an azure sql instance.
It failed a few times with an OOM exception. I switched off everything on my machine and by the end of the restore the SQL server service instance was consuming 13GB of memory from a 700MB file!
The restore luckily finished, but it seems the memory is not being freed up/garbage collected. It's still sitting at 12GB as I write this.
Is it a known issue? Is there any way I can restore a .bacpac and select a table to ignore? You can to do this with a normal data restore, the most offensive table was a dbo.[Logs] table, obvs.
I had the same issue; amending the memory available to the server had no impact.
For me the resolution was to use the command line (PowerShell) to perform the import.
[string]$myBacpac = 'c:\temp\myBacpac123.bacpac'
[string]$connectionString = 'Data Source=.;Initial Catalog=MyNewCatalog; Integrated Security=true;'
[string]$action = 'Import'
[string[]]$commandParameters = #(
"/Action:`"$action`""
"/SourceFile:`"$myBacpac`""
"/TargetConnectionString:`"$connectionString`""
)
[string]$LatestSqlPackage = Get-Item 'C:\*\Microsoft SQL Server\*\DAC\bin\sqlpackage.exe' | %{get-command $_}| sort version -Descending | select -ExpandProperty source -First 1
if ($LatestSqlPackage) {
Write-Verbose "Found: $LatestSqlPackage"
& $LatestSqlPackage $commandParameters
} else {
Write-Error "Could not find SqlPackage.exe"
}
On my first attempt I received an error regarding an unsupported model version:
Importing to database 'MyNewCatalog' on server '.'. Creating deployment plan
Initializing deployment SqlPackage.exe : * Error importing
database:Could not read schema model header information from package.
At line:1 char:1
+ & $sqlPackage /Action:Import /SourceFile:"c:\temp\myBacpac123.bacpac" /T ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (* Error impor...n from package.:String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError The model version '3.5' is not supported.
For that error I followed the guidance here: https://stackoverflow.com/a/40541210/361842; i.e. installed Microsoft SQL Server Data-Tier Application Framework (16.4). On rerunning all was successful.
To configure SQL Server's use of memory, open SQL Server Management Studio, connect to the server, right-click on the server in the Object Explorer window, click properties, and then click on the Memory tab of the Server Properties window.
As for the bacpac, you can't select which tables to restore during an import operation, but you can select which tables are exported. You can use SqlPackage.exe's export command with the /p:TableData parameter to specify which tables should be included in the bacpac. There's unfortunately no way to just specify which tables should be excluded. =^/
SqlPackage.exe documentation is available here: https://msdn.microsoft.com/en-us/hh550080(v=vs.103).aspx
Neither of the other answers worked for me, what did work was closing and restarting SSMS. This sounds like a silly suggestion, but I'd previously been running some large queries which must've caused memory issues.