I'm starting out on creating PowerShell scripts for my company. I'm new the the platform and I plan on creating scripts for AD tasks
If im creating scripts for AD should I be able to run the script on any machine in the domain or does the script have to be run on a machine that is the active directory server?
I don't mind running the script on the server but for testing and creating I would rather run it on my desktop for development and testing
any incite on this?
Assuming you're using the activedirectory powershell module, then the only requirement is that the machine you're running the script on has this module installed.
This module is a windows feature "Remote Server Administration Tools > Role Administration Tools > AD DS and AD LDS Tool > Active Directory Module for Windows Powershell."
On a server OS, this can be simply added as a feature through Server Manager
On a client OS, you will first need to install the Remote Server Administration Tools (RSAT) from Microsoft download centre. Once that is installed, you then install the feature through "Turn Windows Features on or off"
Additionally, if your script has a dependency on this module, you can also place the following line at the top of your script
#Requires -Module activedirectory
Then if you try to run this script on a machine without the activedirectory module, it'll produce an error saying the module is missing. It'll also cause the activedirectory module to be imported if it's not already been imported which is useful on powershell. Refer to about_Requires for more information on the #Requires statement
Related
I've been trying to deploy a database via a pipeline from Azure DevOps to an Azure resource group.
I have an ARM template for my database server in my Repo along with my DACPAC file.
In my release pipeline I first deploy the database server with an admin user defined in the ARM template to my resource group.
Then I use the "Azure SQL DacpacTask" to deploy the database schema. Here I give the admin credentials and it works flawlessly.
The issue is that the customer doesn't want it deployed as a DACPAC but rather an SQL script. They've given me a "CREATE TO..."-script from their database, created inside MS SQL Studio, which is also in my Repo.
The "Azure SQL DacpacTask" inside my release pipeline has an option for using an SQL file instead of DACPAC, but it doesn't work for me.
But no matter how I do it, my pipeline fails when running the "Azure SQL DacpacTask" and all I get, even in debug-mode is "Login failed for user '***'".
I can connect to the SQL Server through MSSQL Studio on my local machine using the admin credentials defined in my ARM template.
I've tried by adding the agent's IP before running the SQL script, but with no success.
Can anyone point me in the right direction or maybe tell me what I'm doing wrong? Why is it that it keeps failing to log in?
They want it deployed with little to no human interaction. Is it doable only through the ADO pipeline?
EDIT
Additional info:
I have tried with hardcoded password and user with no luck.
If I manually create a database and then try to deploy one via script and pipeline, it fails because a database already exists, and not because of a failed login.
I've setup Audit in Azure which generates 2 files with little to no info. I'm not sure what I'm looking at.
I have a following PowerShell script, this scripts connects to my Azure Analysis services. As I execute following script, it opens a popup like image below.
param(
[String]
$envName1
)
$loadInfo1 = [Reflection.Assembly]::LoadWithPartialName("Microsoft.AnalysisServices")
$server1 = New-Object Microsoft.AnalysisServices.Server
$server1.Connect($envName1)
return $server1
Problem is that I want to execute this PowerShell from my WPF application. I don't understand, how can I access this Popup in my WPF application.
I'm not too sure what you mean by that. However, you need an account to connect to Azure, maybe you signed out or never actually signed in to Visual Studio.
Edit: I finally understand what you mean (slightly). So there are basically two solutions. First one is Azure AD. To connect to Office 355 with PowerShell using the AzureAD module, you’ll first need to install it. You can do so by running Install-Module AzureAD from an administrative PowerShell session. Once you have the module installed, run the Connect-AzureAD cmdlet. Once you do, PowerShell will prompt for your Microsoft ID and password (Work or school account). Once authenticated, you’ll be able to use all of the commands in the module.
Connecting to Office 365 with the MSOnline Module:
Connecting to Office 365 with PowerShell using the MSOnline module requires a little bit more effort. Assuming you have the Microsoft Online Services Sign-In Assistant for IT Professionals RTW software package installed:
Install the MSOnline module from the PowerShell Gallery by running from an administrative PowerShell console:
Install-Module MSOnline (Function)
Once the module is installed, run Get-Module to ensure PowerShell can find the module.
Finally, run the Connect-MsolService cmdlet to authenticate to Azure AD. This will prompt you for your Office 365 credential.
We recently created a windows login (domain\etluser) with read-only access to different SQL Server databases. Is there anyway developers can use that generic account to develop SSIS packages using Visual Studio?
It require us to create OLEDB connections using that new account, but couldn't find an option for that
I heard that it is possible to run packages as another user or proxy from SQL Server integration services, once the development and testing is over: How to schedule SSIS package to run as something other than SQL Agent Service Account
In windows, I am aware of two mechanisms to start a process as another user. From the command line, you can use RunAs
As a consultant, I often bring my own device to clients and then use Runas to impersonate my client-domain account without having to get my laptop's domain trusted by their corporate domain. I have a folder filled with batch files that launch a program with their credentials. For example, this is my script to start Visual Studio 2017 Enterprise Edition as my "other" self.
runas /netonly /user:domain.com\billinkc "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE /nosplash"
I've not done SSRS development in a long while, but 2014?ish at least this approach would allow me to develop reports but I could not preview the reports within VS as the preview process would get launched as a "new" process which inherits my current credentials instead of the ones I was started the parent process under. SSIS dev though, worked just fine with this approach.
The biggest complain I have with either approach is that I have to type the password every time. You can't redirect the input from elsewhere and you don't see the typing so you can't tell how many characters you've typed if you screwed up the password. Couple that with an aggressive lockout policy and I spent a lot of time at one client twiddling my thumbs waiting for my account to unlock.
The other approach is a GUI approach. In Windows Explorer, shift right-click on the executable and you should be presented with a context menu like the following.
Pick "Run as different user" and you'll be prompted with a more friendly window to enter credentials
With Runas, you could at least prepopulate the user to save a few keystrokes but with the GUI approach, you have to enter everything every time.
If you run your SSIS jobs through the SQL Server Agent, you can use Proxies: https://learn.microsoft.com/en-us/sql/ssms/agent/create-a-sql-server-agent-proxy?view=sql-server-ver15
There's a couple steps involved:
Create a user for your dom\etluser on the SQL Server, in Security \ Credentials
Create a proxy in the SQL Agent using those credentials, and authorize it to run SSIS jobs
Create a job (or edit an existing job), with the SSIS package as a step and on that step set 'Execute As' to the proxy.
I am attempting to automate the installation of SQL Server 2016 Express.
I have a chef cookbook to install SQL Server Express using the chocolatey package.
The same command as a chef resource
chocolatey_package 'sql-server-express' do
action :install
options '--cachelocation c:\temp\choco'
end
Equivalent PowerShell command
choco install sql-server-express --cachelocation c:\temp\choco
If I install SQL Server Express normally with the install wizard, I can authenticate and create / modify databases no problem.
If I install SQL Server Express with chocolatey / chef, I am not able to create or modify databases.
The error when trying to create a new database
CREATE DATABASE permission denied in database 'master'
The error when trying to modify an existing database
The server principal "Foo\Bar" is not able to access the database "foobar" under the current security context
I've tried logging in as the 'sa' user. mixed authentication is not enabled, and I can't enable it.
How can I get chocolatey installations of SQL Server Express users the same as a normal installation?
After many days I discovered the problem. Run chocolatey as a local administrative user, not SYSTEM.
Why:
The chocolatey package will not install if the command is executed over WinRM due to limitations of the WinRM protocol.
The common work around is to run chef/chocolatey in a scheduled task.
Unfortunately, scheduled tasks run as the SYSTEM user. The result is that MSSQL will only allow the SYSTEM user to run administrative commands.
The solution is to run chocolatey inside a scheduled task as a local system account (not SYSTEM). Or use RDP to log into the system and run the chocolatey command directly (not over winrm).
An example of how to run chef test kitchen as a (non SYSTEM) elevated user
transport:
name: winrm
elevated: true
elevated_username: vagrant
elevated_password: vagrant
I'm trying to run a SQL Agent Job with a step that is a SSIS File, and I need this step to be run as administrator.
My Package uses a Script task to download a file, as a Browser i Use WATIN.
I'm using a thread to start this browser because this browser control requires the thread to be set as Single-Threaded Apartment.
This browser control is requiring to be run as administrator.
I've already created a Credential for a user that is Windows Admin, a Proxy SSIS account. (SQL Agent user is not windows admin).
But the SSIS package is not run as administrator yet.
I'm suspecting this is related to UAC.
Some details:
SQL Agent Account is not Windows Administrator
Using Windows Server 2008 R2
My Package is run from the File System.
The Package only works on BIDS if I run it as an Administrator (if not admin doesn't work)
The Proxy account the job step is configured to run is windows admin.
Any help is appreciated!
Take a look at SSIS runs in BIDS but not with SQL Agent for some ideas
I've solved this in another way, The problem wasn't related to running the package as administrator, but creating a windows and setting focus to it, however I had the option to see the result file on the web page and I managed to use it, without downloading it, thus not needing to set focus on the download windows.
Thanks for all the help.
Try to add the user account in SSIS administrator group which can solve your problem.