MetaData is like Get-Member which shows all properties can be called using Graph API. It includes Property Name, NavigationProperty Name [Related Object].
Open Browser
https://graph.microsoft.com/v1.0/$metadata
Look For :
EntityType name="User"
EntityType name="group"
OData : Open Data is a protocol that is used for a creation of an API’s which is used to expose data over https.
$Var = Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0"
Kind Property
EntitySet
Singleton
DirectoryReadAll : Will provide you User license details
PATCH [Update] : Requires UserReadWriteAll Permission
https://graph.microsoft.com/beta/$metadata
Find :
EntityType Name="user"
Property Name
NavigationProperty Name [Related Object]
https://graph.microsoft.com/beta/users/rohit@rohit.club/manageddevices
When you perform Delta then only the incremental value of all the users will be displayed.
'https://graph.microsoft.com/v1.0/users/delta'
If you want to have specific data which are changed then you have to Copy the @odata.nextLink value and paste it to the GET Box
Copy and keep the “@odata.nextLink” value which is generated this time if you want to see the incremental data changed for the day.
https://docs.microsoft.com/en-us/graph/query-parameters#error-handling-for-query-parameters
https://graph.microsoft.com/v1.0/users?$select=displayName,userPrincipalName&$count=true&$top=3
When the API Server is unable to send all the data at once then the Server follows the paging process where it will send the 1st page with @odata.nextlink which is the link for the next page. This is called Server Side Paging.
Client/Application defines the page size $top=2 which needs to be received by a Server called Client Side Pagination.
Batching is the process of combining multiple Queries into one single Query and sending it to Microsoft Graph API.
Example:
This type of grant is commonly used for server-to-server interactions that must run in the background, without immediate interaction with a user. These types of applications are often referred to as daemons or service accounts.
The Endpoint will be used for this type of flow is Token endpoint.
&Grant_Type=Client_Credentials(check the below image)
1. Restricted
This is the default. PowerShell will not run any script, including PowerShell profiles.
2. RemoteSigned
PowerShell will run any script that you create locally. But any script that has been detected as coming from the Internet, such as via Internet Explorer, Microsoft Outlook, Mozilla Firefox or Google Chrome must be digitally signed with a code signing certificate that is trusted by the computer.
3. AllSigned
PowerShell will not run any script unless it has been digitally signed with a trusted code signing certificate.
4. Unrestricted
PowerShell will make no attempts to hinder script execution and will run any script. If the script comes from an untrusted source, like the Internet, you will be prompted once to execute it. Though it is not preferred.
5. Bypass
There is also a Bypass policy, which I don’t recommend for daily use. This policy will run any script without question or prompting. The assumption is that you have taken steps outside of Nothing is blocked and there are no warnings or prompts.PowerShell to verify the safety and integrity of the script.
6. Undefined
There is no execution policy set in the current scope. If the execution policy in all scopes is Undefined, the effective execution policy is Restricted, which is the default execution policy.
Write-Error should be used if you want to inform the user of a non-critical error. By default all it does is print an error message in red text on the console. It does not stop a pipeline or a loop from continuing.
Throw on the other hand produces what is called a terminating error. If you use throw, the pipeline and/or current loop will be terminated. In fact all execution will be terminated unless you use a trap or a try/catch structure to handle the terminating error.
$UserName = 'Sumant'
$Password = 'Password@123' | ConvertTo-SecureString -AsPlainText -Force
# method 1
[pscredential]::new($Username,$Password)
# method 2
New-Object System.Management.Automation.PSCredential($UserName,$Password)
Accept pipeline input ByValue
Get-Process|Gm
Will return TypeName: System.Diagnostics.Process
Thats why Get-Process -Name notepad|Stop-Process Works.
Get-Process (Retrive Type Process Objects)
Stop-Process (Accepts Type Process Objects)
Its mapped to the below parameter which is ByValue
-InputObject <Process[]>
Required? true
Position? Named
Accept pipeline input? true (ByValue)
Parameter set name InputObjectWithUserName, InputObject
Aliases None
Dynamic? false
Stop-Process [-InputObject] <Process[]> [-PassThru] [-Force] [-WhatIf] [-Confirm] [<CommonParameters>]
By default pipeline uses ByValue and if that is not available then its uses ByPropertyName
Accept pipeline input ByPropertyName
"notepad"|Stop-Process will Fail.
Stop-Process : The input object cannot be bound to any parameters for the command either because the command does not take pipeline input or the input and its properties do not match any of the
parameters that take pipeline input.
"notepad" : Considered as byValue and Stop-Process Accept pipeline input ByPropertyName
-Name <string[]>
Required? true
Position? Named
Accept pipeline input? true (ByPropertyName)
Parameter set name Name
Aliases ProcessName
Dynamic? false
Stop-Process -Name <string[]> [-PassThru] [-Force] [-WhatIf] [-Confirm] [<CommonParameters>]
But we can force it by using the below command
[pscustomobject]@{name="notepad"}|Stop-Process. This time it will Accept pipeline input ByPropertyName
