This is a bit of an aide-memoire, based on https://blogs.msdn.microsoft.com/benjaminperkins/2017/11/15/how-to-create-a-self-signed-san-certificate-wildcard-certificate-vs-san/
The short form is, you can do this in PowerShell:
- Open Powershell, running as administrator.
New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -DnsName "example.local" -FriendlyName "example.local" -NotAfter $([datetime]::now.AddYears(5))
- Go to “Manager Computer Certificate” or run CERTMGR. You should see your certificate
Next, we want to trust this certificate. We’ll need to export it.
- To export the certificate file you just created as a .PFX file, right click on the certificate, All Tasks -> Export…
- When the Export menu item is selected, an export wizard is run. On the first window read through the information and click the next button.
- In the next window, select the radio button “Yes, export the private key” and then click the next button.
- Select Export Extended Properties, and click next
- Set a password for the .PFX file you want to create#
- Choose a path and export the .pfx file
Now import it into the “Trusted Root Certification Authorities” that you can see in Certificate Manager
- Expand Trusted Root Certification Authorities –> right-click Certificates –> All Tasks –> Import.
- Select the file you just exported. Note that you may need to change the file type to Personal Information Exchange.
- Click Next, Fill in your file’s password, and complete the import.
That should be it completed.
An alternative to export the cert:
Copy the Thumbprint of the cert in your Powershell window.
$pwd = ConvertTo-SecureString -String "" -Face -AsPlainText
Export-PfxCertificate -cert cert:\localMachine\my\#Thumbprint# -FilePath #FilePath# -Password $pwd
When you’re developing apps sometimes you’ll have errors occur. How do you get any kind of log entry about that?
Well, it turns out help is at hand – there is a PowerShell command Get-SPOAppErrors. This gets you the app errors for a particular App ID. For example:
Connect-SPOService -Url https://example-admin.sharepoint.com
Get-SPOAppErrors -ProductId DEADBEEF-CAFE-BABE-FACE-BEADEDFACADE | Select-Object -first 5 | fl
This will get the first 5 entries for the app with the given GUID and output their details on the PowerShell command window.
Edit: It seems Chris O’Brien has been thinking about the same problem, and has a good post about it.
Microsoft claim that Office 365 has PowerShell support. I had assumed that this meant that most, or at least many, of the PowerShell commands I can use in a normal farm would also be available in Office 365.
I was wildly, spectacularly wrong. Continue reading “Powershell in Office 365 … and why you need CSOM”
As much as anything, this is a reminder for me. We had a customer who were trying to run a PowerShell script that, ultimately, relied on an assembly that was contained in a WSP we’d written. The script wouldn’t work, however, and it transpired that the WSP had not been deployed to the server that they were running the script on. Continue reading “WSP Not Deployed to a SharePoint App Server”
So, related to my previous post, we had problems initially deleting the Search Service Application. The Search Content Application’s Database had become ‘Suspect’. I’ve had this happen a few times before (I’m not sure why – I ain’t a DB Admin) and I have a little script that I run that seems to fix this, mostly.
EXEC sp_resetstatus 'PROBLEM_DB_NAME'
ALTER DATABASE PROBLEM_DB_NAME SET EMERGENCY
ALTER DATABASE PROBLEM_DB_NAME SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB ('PROBLEM_DB_NAME', REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE PROBLEM_DB_NAME SET MULTI_USER
No, I’m not entirely sure of the logic of how it works, and I’m pretty sure I can here DB Admins across the world screaming, but for my dev systems that I can afford to trash, it seems adequate.
Anyway, on this occasion it didn’t work, so I decided to simply delete the Search Service Application. I tried this through the UI – but it just seemed to hang. I tried again – and it seemed to hang. It wasn’t going away. I tried PowerShell – which took me a while as I’m still a fan of STSADM – and that didn’t work.
In the end I found the solution – on Donal Conlon’s blog – use STSADM -o deleteconfigurationobject
Yes, there’s a certain irony in that.