I want to delete Office 365 users from Active Directory PowerShell in Windows Server 2008 (x64)
There is a treshold so you can't delete more than 500 users.
Microsoft has a documentation to prevent accidetal deletes and it says "just run Disable-ADSyncExportDeletionThreshold" command and it's OK.
But I have a problem. When I try to disable treshold, PowerShell says:
The term 'Disable-ADSyncExportDeletionThreshold' 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 aga
in.
At line:1 char:38
+ Disable-ADSyncExportDeletionThreshold <<<<
+ CategoryInfo : ObjectNotFound: (Disable-ADSyncExportDeletionThreshold:String) [], CommandNotFoundExcept
ion
+ FullyQualifiedErrorId : CommandNotFoundException
Also I tried to import "ADSync" but module couldn't loaded.
Any solution?
Thanks.
Disable-ADSyncExportDeletionThreshold is a commandlet for AAD Connect, you have to have AADConnect module installed and imported for it to work. Try Import-Module “C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync\ADSync.psd1” if its not there, install it.
Also, take a look here.
Above answer is great.
I would suggest that you disable it temporarily and enable it afterwards as it's enabled by default to prevent lots of deletions to be exported to Azure AD. This helps to prevent from deleting accidentally.
Import module first:
If all the deletes are desired, then do the following:
To temporarily disable this protection and let those deletes go through, run the PowerShell cmdlet:
Disable-ADSyncExportDeletionThreshold
.
2. Provide an Azure AD Global Administrator account and password.
3. With the Azure Active Directory Connector still selected, select the action Run and select Export.
4. To re-enable the protection, run the PowerShell cmdlet:
Enable-ADSyncExportDeletionThreshold
.
Related
I am trying to install the PnP online commands for SharePoint onto my PowerShell however the following command doesn't seem to work;
Install-Module -name SharePointPnPPowerShellOnline -scope CurrentUser
The command seems to run through fine with no errors appearing but when I try to run Commands which should have been installed I get an error saying the commands can not be found.
connect-pnponline : The term 'connect-pnponline' 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.
At line:1 char:1
+ connect-pnponline
+ ~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (connect-pnponline:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
I have had a look at all the module folders and the module is not in any of them. I have compared my environment paths with a coworker who has this working and they are the same.
Does anyone know what might be causing this?
This was caused by by modules being stored on OneDrive. By default my module path was set to "%USERPROFILE%\Documents\WindowsPowerShell\Modules" but since i had OneDrive installed my path changed to "%USERPROFILE%\OneDrive\Documents\WindowsPowerShell\Modules".
To resolve this issue I went to Documents>Windows Powershell>Modules and copied the link. Then, via the Start' menu, I went to 'Edit the system environment variables'>advanced>Environment Variables, highlighted PSModulePath and clicked Edit.
Once in this window I clicked New and pasted the link I found above.
This resolved the problem I was experiencing.
The module probably isn't imported. You should be able to executeImport-Module SharePointPnPPowerShellOnline which should either import your module, or give you an error if it can't be imported for some reason.
To tackle the non-autoloading issue, check the following:
Check that you're setting $PSModuleAutoLoadingPreference and that it's not set to None or 0
Cmdlets which make use of a PowerShell provider do not get automatically imported
SharePointPnPPowerShellOnline implements a SharePoint provider so I'd wager this is the case.
I had the same symptom The term '' is not recognized..., but a different fix.
When I checked $ENV:PSModulePath in Windows Powershell (this problem was not present in pwsh powershell core), I saw the expected folder C:\Users\cwalsh\OneDrive\Documents\WindowsPowerShell\Modules was missing:
Instead $ENV:PSModulePath was ;;C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\
The root cause was I had PSModulePath env var defined at both User-level as ; (this is not how my other PC is set up), and at System-level as %SystemRoot%\system32\WindowsPowerShell\v1.0\Modules\. I guess unlike PATH this variable doesn't automatically concatenate both.
I deleted the user-level PSModulePath environment variable and now in a new process the module works as expected.
Onedrive syncing screwed up the files for MgGraph authentication.
one of the subfolders sync was broken he file was removed because "cloud" didnt know about it. Had to reinstall... Need to change the default location out of documents if you have onedrive so silly
When I try to run the command Add-PSSnapin Microsoft.SharePoint.Powershell in SharePoint Online Management Shell
I get the following error:
Add-PSSnapin : The Windows PowerShell snap-in 'Microsoft.SharePoint.Powershell` is not installed on this computer
+ CategoryInfo: InvalidArgument: (Microsoft.SharePoint.Powershell:string) [Add-PSSnapin], PSArgumentException
From what I understand this is supposed to come installed with SharePoint Online Management Shell anyway (this is a fresh download) so why won't it let me install it
I can login to Sharepoint using the $AdminURL, $AdminName & $Password so it's not the end of the world (and proves that this should work), but obviously makes the script less easy to run across sites as it has to be modified everytime to change the url and adminname
EDIT: I read on another post that adding this module (not snapin) would fix my issue of the error Get-SPSite is not recognized as the name of a cmdlet, function, script file, or operable program and Get-SPWebApplication is not recognized as the name of a cmdlet, function, script file, or operable program However, this did not fix my problem...
As mentioned by user #kuzimoto the commands I was using were not compatible with SharePoint Online and were designed to be used in conjunction with SharePoint Server.
The correct way to connect is using the command Connect-SPOService and passing through the credentials through there or just have them hard coded into your script.
I'm trying to follow this article about deploying a service fabric app through powershell, but I have an issue with running the Connect-ServiceFabricCluster cmdlet. I get the following:
Connect-ServiceFabricCluster : The term 'Connect-ServiceFabricCluster' 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.
At line:1 char:2
+ Connect-ServiceFabricCluster
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Connect-ServiceFabricCluster:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
Following other articles on the internet, I've tried importing the following things:
Import-Module "$ENV:ProgramW6432\Microsoft SDKs\Service Fabric\Tools\PSModule\ServiceFabricSDK\ServiceFabricSDK.psm1"
Import-Module "C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ServiceFabric"
I also saw somewhere to try and set execution policy before importing modules, so I tried this:
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force -Scope CurrentUser
In the Modules section of the Powershell ISE I see the ServiceFabricSDK module, but I don't see this cmdlet.
How do I get access to these cmdlets?
Thank you for any help.
Current versions:
Running $PSVersionTable.PSVersion, I get
Major Minor Build Revision
----- ----- ----- --------
4 0 -1 -1
Service Fabric SDK is version 2.5.216
You should make sure you are running the Windows Powershell as opposed to just Powershell. This made a difference for me.
Are you running x86 version of Powershell ISE? I got this error as well but when I switched to the other ISE the cmdlet was available again.
First, I would set your policy to bypass. This can't be done from the script itself, because, well, that's what needs to run with this policy. You could look into setting your powershell ise profile to do this for you.
Set-ExecutionPolicy Bypass
To your question. Not all modules can use the Import-Module feature. For instance, modules from the technet.microsoft.com site must sometimes be manually installed and unzipped. I'm including a script I use below to do this automatically.
#https://www.petri.com/manage-windows-updates-with-powershell-module\
$url = "https://gallery.technet.microsoft.com/scriptcenter/2d191bcd-3308-4edd-9de2-88dff796b0bc/file/41459/47/PSWindowsUpdate.zip"
$module = "PSWindowsUpdate"
$zipped = "$($PSScriptRoot)\$($module).zip"
$unzipped = "C:\Windows\System32\WindowsPowerShell\v1.0\Modules"
#$unzipped = "$PSScriptRoot\$($module)"
if (Get-Module -Name $($module)) {
Write-Host "Module exists $($module)"
} else {
Write-Host "Getting Module $($module)"
if(!(Test-Path $zipped)){
(New-Object System.Net.WebClient).DownloadFile($url, $zipped)
if($?){Write-Output "Downloaded zip $($zipped)"}
}else{
Write-Output "Zip found $($zipped)"
}
if(!(test-path "$($unzipped)\$($module)")){
Add-Type -assembly “system.io.compression.filesystem”
[io.compression.zipfile]::ExtractToDirectory($zipped, $unzipped)
if($?){Write-Output "Unzipped to $($unzipped)"}
}
Unblock-File -Path "$($unzipped)\$($module)" -Confirm
if($?){Write-Output "Unblocked file $($unzipped)"}
Import-Module $unzipped\*\$($module).psd1 -Verbose
if($?){Write-Output "Imported module $($unzipped)"}
}
I was too hasty in my first answer. (which is weird, cuz it took awhile to type...) anyhow. It looks like the install process actually unpacks the psm1 for you.
Be sure you are running as admin, use this to check.
([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole(`
[Security.Principal.WindowsBuiltInRole] “Administrator”)
Make sure the file name you made in step 3 matches the path in step 6.
When you run the import module command, follow that up with $?. This will tell you if it imported correctly. You can also use these commands to see if it worked.
get-command -name "Cluster"; get-module
I have just experienced the same problem on my Win10 box,
when cmdlets were not recognized as valid and downloading/installing relevant modules that contained those cmdlets didn't work.
The only solution that worked for me was as follows:
Go to the Control Panel -> "Programs and Features"
Uninstall Service Fabric SDK
click "Turn Windows features on or off" link and uninstall PowerShell
Next, reboot the Windows
Go back to the Control Panel -> "Programs and Features" -> "Turn Windows features on or off"
And install PowerShell
After which download/install Service Fabric SDK
Once again, restart your PC, start the Service Fabric Cluster Manager (if it doesn't auto-start), then right-click its icon on the task-bar and try creating 1-node or 5-node cluster again. In my case, it took less than a minute.
I installed the Azure Powershell Command lets (from here https://www.windowsazure.com/en-us/manage/downloads)
I also ran the
Set-ExecutionPolicy RemoteSigned
I then run the Windows Azure PowerShell under administrator credentials
However I get the following error
Get-AzurePublishSettingsFile : Class not registered
At line:1 char:1
+ Get-AzurePublishSettingsFile
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : CloseError: (:) [Get-AzurePublishSettingsFile], Win32Exception
+ FullyQualifiedErrorId : Microsoft.WindowsAzure.Management.Cmdlets.GetAzurePublishSettingsCommand
I had exactly the same problem on Windows 8 while using Chrome as my default browser.
The solution is to have Internet Explorer be the default program for opening browser related files like *.html.
Internet Explorer > Internet Settings > Programs > Set associations = Select all
This does the trick. Maybe a single entry would suffice but I didn't check that.
Check to see what the value is in $pshome
If you see %windir%\System32\WindowsPowerShell\v1.0 you are running powershell in 32bit mode. This is the version of PowerShell you will want to use for the Windows Azure PowerShell Cmdlets.
If you see %windir%\SysWOW64\WindowsPowerShell\v1.0 you are running in x64 mode, which may cause issues.
Also, ensure you are NOT running powershell 'As Administrator'
You need the private key of (or on) the certificate in order for this to work correctly. I found this out after a lot of trail and error.
But in short if your certificate manager does not have a little key icon over the certificate (the second certificate in the screen shot), it means you don't have a private key, and that means that Powershell will not be able to connect to Azure.
I noted down the things that I learned over here:
Management certificates and powershell deployment to windows azure
I use a non-administrator account to open powershell then it worked.
Notice launching the command would open up a web page at this url to download the publish settings file for your Azure account.
So effectively, you may open the link above without using the command.
Hope this helps.
Trying to retrieve help from a script gives the following error:
Get-Help : Cannot find Help for topic ".\Process-Test.ps1".
At line:1 char:9
+ get-help <<<< .\Process-Test.ps1
+ CategoryInfo : ResourceUnavailable: (:) [Get-Help], HelpNotFoundException
+ FullyQualifiedErrorId : HelpNotFound,Microsoft.PowerShell.Commands.GetHelpCommand
I've encountered the same error when attempting to retrieve help information from any custom PowerShell script. This does not happen when viewing help information from built-in cmdlets.
A test script is below:
<#
.SYNOPSIS
Adds a file name extension to a supplied name.
.DESCRIPTION
Adds a file name extension to a supplied name.
Takes any strings for the file name or extension.
.EXAMPLE
C:\PS> extension -name "File"
File.txt
#>
Write-Host "Test script"
Troubleshooting steps I've taken:
I've copied this script (or similar scripts) to other machines with PowerShell installed and used it to view help successfully.
I've also been able to view the help using a different account (User2) on my computer successfully, but only when logged in as the other user (versus running the PowerShell console as User2 when logged in as User1).
I've tried viewing the help with and without my PowerShell profile loaded, with the same result (I only have one profile loaded, my personal profile versus machine profiles).
I took this to be a sign that there was a problem with my Windows user profile, so I deleted my profile and re-created it with the same result. I've also tried running System Restore, with no change.
This happens in the PowerShell console along with the ISE.
Occurs when using both Get-Help as well as help.
I noticed, however, that my PowerShell console settings stayed consistent throughout deleting and re-creating my Windows user profile (height, width, colors, etc), which I wouldn't have expected since I deleted my user profile.
Since I'm using Windows 7, I'm not able to uninstall PowerShell and re-install as it's baked into the OS.
Google wasn't helpful for me in this case, but my google skills could be lacking. Any ideas as to further troubleshooting steps, or anyone who's seen this error before?
Edit: this only happens with the 64-bit version of the console and ISE, not with the 32-bit version, and persists through profile deletion
Have you tried to set execution policy?
Set-ExecutionPolicy -ExecutionPolicy remotesigned -Scope process
Then do Get-Help .\script.ps1.
I had the same problem. That was because my script was located on a networkshare in a DFS folder. So I am pointing to network file. When I copied the file locally, directly on the root of my C drive, and called the help option for my script with the normal get-help myscript.ps1 parameter, it worked!