Translate

Friday, May 3, 2019

eDiscovery - Put mailboxes On Litigation Hold using PowerShell Script


O365 administrators can use GUI to put SharePoint sites, ODB, mailbox on litigation hold. Microsoft eDiscovery UI helps admins to create a Case and apply Hold to mailboxes. However, there are PowerShell scripts available to put mailboxes On Litigation Hold and you do not need to create Cases for it. 

Below is how we do that  -

1. Connect to Exchange Online

$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

2. Check Litigation Status of the mailbox

Get-Mailbox -identity rajdeepc@onmicrosoft.com |fl Identity, LitigationHold*

3. Put the mailbox on hold

Set-Mailbox -identity rajdeepc@onmicrosoft.com -LitigationHoldEnabled $true

4. (Optional) Use the content search to get collection for your legal team

5. Release the mailbox if it is not needed to be On Litigation Hold

Set-Mailbox -identity rajdeepc@onmicrosoft.com -LitigationHoldEnabled $false

6. Disconnect the session (Must do to ensure the session is not occupied)

Remove-PSSession $Session



Wednesday, May 1, 2019

Enable SPO Site Collection App Catalog


By now everyone knows how to enable Site Collection App Catalog in SharePoint Online. It is simply to run the commands like below -

Connect-SPOService -Url {SharePointAdminSiteURL} -Credential rajdeep@domain.net
$site = Get-SPOSite {SiteCollectionURL}
Add-SPOSiteCollectionAppCatalog -Site $site

You may encounter an error like "Must have Manage Web Site permissions or be a tenant admin in order to add or remove sites from the site collection app catalog allow list". This is because if the person who's executing the command is not admin in the App Catalog site.

Add rajdeep@domain.net as admin in the site collection app catalog and run it again.

Wednesday, January 30, 2019

Backup and Restore Project Server Sites 2013

The below article outlines how to take backup and restore Project Server sites from one tier to another. The steps are tested successful in SharePoint/Project Server 2013 farm. The process assumes that you already have the Project Server database and content database backup files available from the backup/restore team.
First we will start by dismounting the existing running instances. Please have communication out for the downtime your application/site will have during the process.

  • Dismount-SPProjectWebInstance -SiteCollection  <URL of PWA site that we want to refresh>
  • The Project Server service application in CA the project site should have been removed
  • Next we will dismount the content database - Dismount-SPContentDatabase “<Content Database name here>”
  • Launch SQL server and restore the SQL database backups you have received from the B/R team.
  • Mount the restored content database in the web application - Mount-SPContentDatabase “<restored content database in previous step>” -DatabaseServer “<SQL Server>” –WebApplication <web application URL>
  • Mount the restored project server database - Mount-SPProjectDatabase -Name “Name of the restored Project database” –WebApplication “Web Application URL that the Project Web App database will mount to” –DatabaseServer “SQL Server where the database was restored”
  • Provision the Project Web App site collection - Mount-SPProjectWebInstance –DatabaseName “Restored Project Web App database” –SiteCollection “site collection URL including the PWA path” –DatabaseServer “SQL Server where the database was restored”
  • We can check the provisioning status using - Get-SPProjectWebInstance -URL "https://...." | Select ProvisioningStatus
If your farm is managed by different administrative accounts, you may have to consider adding the correct account permission in the newly provisioned project site. For that navigate to - CA > Manage Service Apps > Project Server Service App and choose to Edit the Project Server Instance, modify the Administrator account to be the correct account.

If Excel service reports are in use, will need to update to use the ODC files from correct environment. 

Thursday, July 19, 2018

START or STOP App Fabric Caching service using PowerShell

START or STOP App Fabric Caching service using Power Shell

App Fabric or Distributed Caching service can be started using services console or from the central admin UI. However, I find it easy to start it using power shell. Copy and paste the below code in a notepad and save it as .ps1 file. The script file can be executed from the distributed cache server/s.

START App Fabric Caching Service
$instanceName =”SPDistributedCacheService Name=AppFabricCachingService”
$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
$serviceInstance.Provision()

STOP App Fabric Caching Service
Stop-SPDistributedCacheServiceInstance –Graceful

After the service is started, from the DC server, type the below two commands to ensure that your service is UP.

Use-CacheCluster
Get-CacheHost

Now about the verification. First verification should be in the services.
1. Click on Start > Run > type services.msc > Enter
2. Ensure the App Fabric Caching service is running.

The next verification is from the Central Administration.
1. Navigate to Central Administration > Click on services on server
2. Select the server from the dropdown where your DC is configured
3. Ensure the Distributed Cache status is Started.

Hope this helps !

Remove access to the third party app store for SharePoint on prem farms


Remove access to the third party app store for SharePoint on prem farms

If you don't want your users to access the SharePoint App store in your on prem farm and try to add or request apps for your farm, use the below command from any of your frond-end/app server to disable the app store.

Set-SPAppStoreConfiguration -Enable $false

Monday, June 4, 2018

SQL account permission sync issue on Always On


SQL account creation process is slightly different for SQL servers which are on always on availability group. The SQL account permissions won't sync properly if the SID of the accounts are not same in primary and secondary SQL server. 

Since the SQL account created in the primary SQL server cannot sync the permission properly in secondary server, after the fail over (when the secondary sever will become primary and vice versa) the account will have permission issue and cannot be used anymore to login. To avoid this issue, either 1) we should create the accounts in primary and secondary server with same SID, or 2) if the accounts are already created, delete/drop the account in the secondary SQL server and have the account recreated using same SID (this is not recommended if the account has many database mappings, it will complicate things).

Create a SQL account in primary and secondary SQL server

- Login to the primary SQL server with admin credential and run the below -


  Use [master]
  GO
  CREATE LOGIN [SQL_Login_Account_Name]  
  WITH PASSWORD = N 'Account_Password',
   DEFAULT_DATABASE=[master]
   GO

- Provide privilege to this account
- The account will not replicate automatically to the secondary SQL server. To have this account available in the secondary SQL server, we will have to re-create it in secondary. Before we do that, we need the SID of the account. Run the below to get the SID.

Select name, sid FROM sys.server_principals WHERE name = 'SQL_Login_Account_Name'

- Login to the secondary SQL server and run the below - 
   
  CREATE LOGIN [SQL_Login_Account_Name]
  WITH PASSWORD=N 'Account_Password',
  SID = SID_OF_THE_ACCOUNT_FROM_PRIMARY_SQL,
  DEFAULT_DATABASE=[master]
  GO

- Provide same privilege as given in primary 
- Go back to the primary SQL server and provide DB access to this account. The new user account will be automatically replicate in secondary SQL server with same permission.

If the accounts are already created in primary and secondary SQL server then the steps will remain same, except - 

1) Drop the account from the secondary sql server
2) Get the SID of the account from the primary sql server
3) Recreate the account in secondary sql server using the same SID

GUI doesn't support creation of accounts using same SID, hence this can be achieved only using TSQL.