I want to share other peoples Office 365 calendars with me, with different access rights for testing. I have Exchange admin rights so that I can poke around in the Office365 Exchange config.
With https://theitbros.com/add-calendar-permissions-in-office-365-via-powershell/ as inspiration and some help from https://social.technet.microsoft.com/Forums/office/en-US/d59a04ec-3d9d-40c1-8937-fedfba79b888/assigned-reviewer-access-rights-through-powershell-but-can-create-calendar-appointments?forum=Exch2016PS I have done the following
Start Powershell as admin
Log into Office365:$LiveCred = Get-Credential
Create a new session:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import the Office365 session:
Import-PSSession $Session
Query the mailbox folder statistics with Get-MailboxFolderStatistics, but filter on 'identity':
Get-MailboxFolderStatistics b#tdomain.onmicrosoft.com | fl identity
This shows names for these 'Identities' and tells me that the calendar in Dutch is called Agenda.
Update the permissions for those folders:
Add-MailboxFolderPermission -Identity t#tdomain.onmicrosoft.com:\Agenda -user jandoggen#tdomain.onmicrosoft.com -AccessRights PublishingEditor
Add-MailboxFolderPermission -Identity i#tdomain.onmicrosoft.com:\Agenda -user jandoggen#tdomain.onmicrosoft.com -AccessRights Editor
Add-MailboxFolderPermission -Identity b#tdomain.onmicrosoft.com:\Agenda -user jandoggen#tdomain.onmicrosoft.com -AccessRights Reviewer
If I now verify the permissions with
Get-MailboxFolderPermission t#tdomain.onmicrosoft.com:\Agenda
Get-MailboxFolderPermission i#tdomain.onmicrosoft.com:\Agenda
Get-MailboxFolderPermission b#tdomain.onmicrosoft.com:\Agenda
... I see access rights {PublishingEditor}, {Editor} and {Reviewer}:
However, in OWA (Outlook Web Access) I can still create appointments in b's calendar, where it says {Reviewer}.
What am I overlooking?
First: it looks like giving PublishingEditor gives you the rights needed to Create/Remove items. I suggest digging into AccessRights.. More here: https://social.technet.microsoft.com/Forums/en-US/105ccad6-4d36-4c6b-a2e1-8cc890fde9fb/addmailboxpermission-accessrights-definition?forum=exchangesvrgeneral
Specifically, this:
Second: Are you Dutch by any chance? I have never seen the ':\agenda' switch used before. From what I have found, only when using the Dutch language 'pack' should you use ':\agenda'.
Please try those same commands, but use ':\calendar' instead of ':\agenda'. I am not sure if this will have any affect, but it is a good start.
Found here: http://www.vdberge.com/kennisbank/a-quick-way-to-set-calendar-permissions-using-powershell/
Add-MailboxFolderPermission -Identity t#tdomain.onmicrosoft.com:\Calendar -user jandoggen#tdomain.onmicrosoft.com -AccessRights PublishingEditor, Editor, Reviewer
Third: it looks like the permissions you are assigning do not make sense. Please review access rights and the permissions that encompasses them.
Related
I am trying to move bulk users(900+) from SfB On-Premise to SfB-Online using Move-CsUser PowerShell Cmdlet. Below is the code snippet:
$INP = Get-Content -Path <txt file path>
$SESSION = New-CsOnlineSession
Import-PsSession $SESSION -AllowClobber
foreach($USER in $INP)
{
Move-CsUser -Identity $USER -Target 'sipfed.online.lync.com' -ProxyPool 'ProxyPool_FQDN' -UseOAuth -Confirm:$False
}
It works fine for 15-20 users and moves them successfully to SfBOnline however, after that it prompts for Office admin credentials again saying "We couldn't sign you in. Please try again" and doesn't accept the credential anymore. Keeps prompting the same.
NOTE:
I have followed all the possibilities from Technet with no luck.
Disabled MFA from the global admin Office account - No luck.
Tried using -UserList parameter to move bulk users - Same issue.
Any help would be much appreciated.
Having issues with remove-mailboxPermission and Add-MailboxPermission. I receive the following error:
The Command Get-Mailbox works however the rest does not (note: I've edited out our DNS)
#PowerShell script to add access to an email and not map
Set-ExecutionPolicy RemoteSigned
$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session -DisableNameChecking
Get-Mailbox davidb#aaa.com
Remove-MailboxPermission -Identity davidb#aaa.com -User AshleyD#aaa.com -AccessRights FullAccess
Add-MailboxPermission -Identity davidb#aaa.com -User AshleyD#aaa.com -AccessRights FullAccess -AutoMapping:$false
Remove-PSSession $Session
The error "A term _____ is not recognized as the name of a cmdlet..." can be misleading. If your syntax is correct it usually means that you don't have sufficient permission to run that commandlet.
You can use this guide to find out which specific permission you need to run each cmdlet:
https://learn.microsoft.com/en-us/powershell/exchange/exchange-server/find-exchange-cmdlet-permissions?view=exchange-ps
You may be wondering "why doesn't it just tell me that I don't have permission?" It makes a little more sense when you understand why you get this error. Remember that your session can't see(for lack of a better term) parameters or commandlets you don't have permissions for. So depending on what you are trying to do PowerShell may tell you "thats not a valid command" or "thats not a valid parameter", when in fact those are valid commmands and parameters, your session just can't see them if you don't have access to run it. This will also happen if you are connected to a wrong URI in your O365 PowerShell session(e.g. the compliance uri instead of the outlook uri)
EDIT: This site says you need to be a member of the "Organization Management" group in order to run these cmdlets.
I'm trying to license my users in office365 with a powershell script in tassk scheduler.
First : I have a script to create some users in my domain controller. This script add content (userprincipalname) in a txt file. Example :
- Create user : John Smith
- The script add this in the txt file : john.smith#domain.com
Second : Another script try to license this user. This script are connecting to MSOLService with this cmdlets :
$LOGIN = "svc-365#domain.com"
$MDP = Get-Content "C:\Script\SVC-365.txt" | ConvertTo-SecureString
$Cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $LOGIN,$MDP
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Connect-MsolService -Credential $UserCredential
Import-PSSession $Session -AllowClobber
$User = Get-Content "C:\Script\CreationMail.txt"
foreach ($i in $User) {
Set-MsolUser -UserPrincipalName $i -UsageLocation "FR"
Set-MsolUserLicense -UserPrincipalName $i -AddLicenses "tenantudl:STANDARDWOFFPACK_FACULTY"
}
This script is perfectly working when I manually execute in powershell ISE, but not working in the task scheduler...
If somebody can help me, I will be grateful to him ! :)
Thanks for help !
Which user runs the script in your task?
With credentials that you have saved as a hash value in a text file it can only be decrypted by the user that made the file.
So if you made that file with your user, but the user that is setup to run the task is not the same, say a service account, it cannot decrypt the password and the login will fail.
As a note, I would highly recommend Microsofts new feature to assign licenses by group membership instead of doing it by scripts as Microsoft changes things an scripts break.
It is in preview right now and require an AD Basic license on your account or higher, you can activate a free trial of the EMS license pack in Azure and and this will be enough to activate the feature.
For TaskScheduler scripts, you need to set it up correctly.
Set the "Program/Scritp" to Powershell.exe
Set the "Add arguments" to -ExecutionPolicy Bypass C:\Temp\AddLicence.ps1
(Optional) If your script requires any params then you will need to add them and your "Add Arguments" field ends up as -ExecutionPolicy Bypass C:\Temp\AddLicence.ps1 -Users C:\temp\users.csv -LicenceType C:\temp\O365.txt
I find the problem ! :D
In my task, it was domain\administrator who run the task but this account havn't the right to connect to office365 and he havn't the admin right on Exchange-online. I was changed this account with another who have the right on 365 and it's WORK !! :D
Thank's for help guys !
I’m new to Powershell and am struggling to make a script work. I’ve read many articles here on Overflow and elsewhere and don’t see what I’m doing wrong. Any help would be appreciated.
I'm trying to create a script that will unlock an AD user remotely while I'm logged-on to may computer as a local admin. Here's my script:
Import-module Activedirectory
New-PSSession -ComputerName <Remote ComputerName> -Credential
<domain admin credential>
Import-Module Activedirectory
Unlock-ADAccount
Read-host “Press any key”
I try to execute this from my computer logged-on as a local admin, but pass domain admin credentials. The script is run as an administrator in Powershell. After I enter my domain password and indicate which user I want to unlock, the message I get is: “Insufficient access rights to perform the operation”.
If I run this code interactively in Powershell, line by line, it will unlock the account. If I run a script asking only to see if the user is locked, it will give me an answer. If I run the above script from my computer logged-on as the domain admin, it will run and unlock the user.
I don’t understand why it will not run when I’m logged-on as local admin, given that I’m passing domain admin credentials. Any help would be appreciated.
You're creating a PSSession, but not using it. Try something like this (untested):
$computer = "test1"
$cred = Get-Credential
$user = Read-Host User to unlock
$sess = New-PSSession -ComputerName $computer -Credential $cred
Invoke-Command -Scriptblock { param($ADuser) Import-Module Activedirectory; Unlock-ADAccount -Identity $ADuser } -ArgumentList $user -Session $sess
Read-host “Press any key”
Although you could create a PSSession, if you have RSAT installed and have access to the ActiveDirectory module there is no need to do that. Instead, just use the credential parameter on each AD cmdlet. For instance, to unlock a user account using alternate credentials, use the following:
Unlock-ADAccount -Identity username -Credential (get-credential)
I'm having a bit of a wierd problem.
At my company we use seperate admin accounts for all AD modification puposes (for eg. if my normal AD ID is User01 then my admin a/c wud be something like User01_adm -> this has the modification rights over ad users / groups). Now, i can make changes like say change the login script from ARS web console using my adm a/c but if i use the same in powershell script i get "Access denied" [System.UnauthorizedAccessException]. Is there a difference between the way these both are setup (web console & powershell console?)
I'm using below part for connecting to ARS server with my adm credentials:
#Connect to ARS server
$GetCreds = Get-Credential -Credential $null
$ConnectARS = Connect-QADService -service $ArsServer -Proxy-Credential $GetCreds
#make changes
$PopulateData = Set-QADUser -Identity $UserID -Credential $GetCreds -ObjectAttributes #{scriptPath=$LogonScr}
Can any1 pls point wht am i doing wrong?
Any help would be highly appreciated...
I've nowhere to try it, but shouldn't it be:
#Connect to ARS server
$GetCreds = Get-Credential -Credential $null
$ConnectARS = Connect-QADService -service $ArsServer -Credential $GetCreds
#make changes
$PopulateData = Set-QADUser -Identity $UserID -Connection $ConnectARS -ObjectAttributes #{scriptPath=$LogonScr}
Ok, got it figured out, it was too simple:
it was mere -Proxy switch missing in Set-QADUser statement
working fine now, thx all for help :)