I am using an Azure Function to create a new SharePoint site with PnP.
The Azure Function reads from a list in SharePoint that supplies all the Information needed to create a site.
This works Perfectly fine in Visual Studio Code, but not in the Azure Funktion.
The strange part is, that the after some time it just tells me the Funktion finished, eventhough some parts that syntactically cannot be skipped, got skipped.
Connect-PnPOnline -Url $siteUrl -Credentials $cred
Set-PnPListItem -List list -Identity $listitem.ID -Values #{"something" = "creating..."}
New-PnPSite -Type TeamSite -Title $listItem.Title -Alias $Listitem.Alias -Description $listItem.Description
Set-PnPListItem -List list -Identity $listitem.ID -Values #{"something" = "The URL"
This part of the Code works fine in in Visual Studio, but when it's run via Azure Functions, the list-field "something" first changes to "creating…", but then the Azure Function stops:
[Info] Function completed (Success, Id=x, Duration=6663ms)
I don't really get what is Happening, and why it stops, normally i would get an error message or something.
Do you guys know whats going on?
So, I just reinstalled all my modules to Azure Function + some new ones. After that my function worked as intended.
Related
I'm having an issue with the timing around creating a new Azure AD security group and using that group for SharePoint Online folder access.
Using New-PnPAzureADGroup i'm creating the security group, then using Set-PnPListPermission and Set-PnPFolderPermission i'm setting the security group with the required permission for that List or Folder.
It seems that Set-PnPListPermission & Set-PnPFolderPermission are running too quickly after the creation of the group as it reports
Set-PnPListPermission : The specified user XXXX123_SP could not be found.
The strange thing is, once the group has been created I can immediately run Get-PnPAzureADGroup and retrieve the group. I can also manually run the same command a little later and it completes successfully.
I assume the groups take time before they're available in SharePoint, what's the best practice approach to check and wait for these groups before applying them in SharePoint?
Thanks in Advance
You could try to use following PnP PowerShell commands:
Set-PnPListPermission -Identity '$LibraryName' -User 'c:0t.c|tenant|$AdGroupID' -AddRole 'Read'
I replaced -Group with -User in the PnP PowerShell command. Then executed successfully with on error message.
I've encountered this issue, except with external users rather than AD Groups but I think the root is the same. The object can be immediately queried from AD but takes times to become resolvable in SharePoint.
I doubt you'll find a documented best practice as this is a bit of an advanced use case. In my case I seem to recall it taking between 5 and 30 seconds to resolve. What I did was loop 10 times with a Thread.Sleep and break out when it succeeds. Event then you'd get occasional failures - you just log them and move on and let support staff deal with it.
Not my proudest coding moment but it (mostly) got the job done.
$condition = $false
do{
try {
Set-PnPListPermission [-ErrorAction Stop]
Set-PnpFolderPermission [-ErrorAction Stop]
$condition = $true
}
catch {}
}
until{$condition}
Context:
I'm creating a Electron React Application. I'm building it for my colleagues.
This app will give you a simple to use UI. You can do different things for which you normally would need powershell.
Example: Gui asks you for a user you want to access and another user that it should grant access too.
I'm then passing everything we need to powershell-node (a package that handles powershell with node) and it will (in this example) grant Full Access Permissions to the user specified.
The Problem
We are using a different account to fire exchange and powershell commands since we don't have rights with our personal logon. So normally I would create a pssession to our ex server like this:
$Connection = #{
ConfigurationName = 'Microsoft.Exchange'
ConnectionUri = 'http://ourserver/powershell'
Authentication = 'Kerberos'
Credential = Get-Credential}
$Ex2010Session = New-PSSession #Connection
Import-PSSession $Ex2010Session -AllowClobber | Out-Null
Normally this would work and give me the commandlet add-mailboxpermission.
Also the command itself works on a normal powershell because I open it with my Admin account (run as). And that's the point:
In my script I do exactly this but then afterwards I run the Add-Mailboxpermission command with all required parameters.
Of course it won't work because I opened my electron app with my normal account. Also there is not -Credential parameter on the Add-MailboxPermission command.
A possible solution;
The first idea that comes into my mind is, to just open the app with the adm account. While possible I'm aspire for a better solution.
What have I tried
The next idea I got is "Why don't I just send the command to the server via invoke-command like this:
Invoke-Command -Session $Ex2010Session -ScriptBlock {
Add-MailboxPermission -Identity $Identity -AccessRights 'FullAccess' -user
$User -automapping $Automapping
}
Unfortunately when I try to run this I get this error message:
variable that cannot be referenced in restricted language mode or a Data section is being referenced. Variables that
can be referenced include the following: $PSCulture, $PSUICulture, $true, $false, and $null.
I don't have any access to our ex infrastructure and therefore can't try to fix it on these side of problems (language mode).
So there I am, having no idea how to solve this problem. I hope you guys have any ideas how to fix it, that would be very neat.
Little Screenshot of the app:
Problem/Question
I'm test running a script for redgate deployment. At the last step it starts a website:
import-module WebAdministration
$website = get-website | where-object { $_.name -eq $RedGateWebSiteName }
#(re)write HostName#
$binding = Get-WebBinding -Name $RedGateWebSiteName
Set-WebBinding -Name $RedGateWebSiteName -BindingInformation "*:80:*" -PropertyName HostHeader -Value $HostName
if ($website) {
Start-Website "$RedGateWebSiteName"
}
It always worked but now on one of the last days I get this error
At D:\inetpub\Timeblockr-RedGate\Api\PostDeploy.ps1:15 char:15
+ Start-Website <<<< "$RedGateWebSiteName"
+ CategoryInfo : InvalidOperation: (:) [Start-Website], COMException
+ FullyQualifiedErrorId : InvalidOperation,Microsoft.IIs.PowerShell.Provider.StartWebsiteCommand
IIS error
The World Wide Web Publishing Service (WWW Service) did not register the URL prefix http://*:80/ for site 3. The necessary network binding may already be in use. The site has been disabled. The data field contains the error number.
This SO question "Cannot create a file" error when running Start-Website command in Powershell gives a pretty good clue what it can be.
Edit:
After viewing my event log and checking out the answers I found out that when Redgate automaticly tries to install/start the website i'm getting this IIS error:
The World Wide Web Publishing Service (WWW Service) did not register the URL prefix http://*:80/ for site 3. The necessary network binding may already be in use. The site has been disabled. The data field contains the error number.
In this Serverfault : https://serverfault.com/questions/456217/the-world-wide-web-publishing-service-www-service-did-not-register-the-url someone its mentioning that the cause of that is that a IIS website gets created without hostheader. I'm adding the hostheader after I try to start the website. Lets find the solution
Edit 2:
I was adding the hostname after I tried to start the website. This caused that the website has e empty hostname and that conflicts in IIS. (or somewhere else).
I've changed my script to get the website, add the hostname and then start the website.
Also added "$RedgateWebsiteName" instead of $RedGateWebSiteName. Works perfectly now!
Edit 3:
After a run of tests I seem to end up the same error. The one deploy has no problems, the other deploy does has.
Edit 4:
I've updated the script / Error / Post.
I deleted my site from IIS after that I clicked on install. Perfectly installed - No problems, automatic start.
Second run exactly the same, third run I get the error above!
I'm guessing the $RedGateWebSiteName variable had not been assigned a value, assuming the log message replaces the variable with its' value. From googling around, it looks like the IIS "file already exists" message may be erroneous as it happens because of anything from a missing IP address binding to an invalid virtual directory folder.
Why do you need a script to start the website? If you are using Red Gate Deployment Manager, it starts the website after the deploying a web package (any package with a web.config file it).
It could be that the value substitution for $RedGateWebSiteName is not taking place and it probably needs double quotes:
Start-Website "$RedGateWebSiteName"
I say this because your error message says this:
Start-Website <<<< $RedGateWebSiteName
while the error message here displays the substituted value:
start-website <<<< "MyWebsite"
I had the exact same problem, when starting the website with:
Start-Website -Name MyWebSiteName
and it would not start. When I tried to start it manually in IIS Manager, it wouldn't start either and I got this error message:
The World Wide Web Publishing Service (W3SVC) is stopped. Websites cannot be started unless the World Wide Web Publishing Service (W3SVC) is running.
This is pretty clear that the service is not started and it turned out to be true.
Overview
I am observing a really strange behaviour with code which attempts to retrieve the TermStore from the TaxonomySession. The code looks like this:
using (SPSite mySite = new SPSite(url))
{
TaxonomySession session = new TaxonomySession(mySite);
// Get all the TermStores associated with the provided site.
TermStoreCollection stores = session.TermStores;
Console.WriteLine(stores.Count);
Here is the issue:
The above code does not return any TermStores, i.e. the count is zero
If I run the following PowerShell script from the same command prompt, I get 1 TermStore in the count.
$site = new-object Microsoft.SharePoint.SPSite("https://mysite")
$session = new-object Microsoft.SharePoint.Taxonomy.TaxonomySession($site)
$session.TermStores.Count
I have tried the following:
My Managed Metadata Application Proxy is a part of the default proxy group
The administrator for the Managed Metadata Service is configured correctly
The permissions for the Managed Metadata Service are configured correctly
The Managed Metadata application pool is running under the farm account
Modifying the code above to run under elevated privileges
The weird thing is that the first block of code above DOES NOT retrieve any TermStore(s) when compiled as an executable and invoked from a command window, which is running under the farm credentials. IN THE SAME window, I can copy and paste the second block of the equivalent PowerShell scripts and have it run!
Also, this issue is only happening on our Production environment. The same executable ran successfully on our DEV, TEST and Pre Prod environments.
Any help at this stage will be much appreciated.
We encountered exactly the same issue in our test environment. But, our development servers are working as expected. My colleague was able to narrow down the issue and resolve it by updating hotfix available in Microsoft support.
The following are the details of the hotfix and information he could come across while researching on that particular issue.
Support download link
For additional information:
http://chrisforbesblogs.net/2009/12/02/the-managed-metadata-service-or-connection-is-currently-not-available
http://expectedexception.wordpress.com/2011/06/15/the-managed-metadata-service-or-connection-is-currently-not-available-the-application-pool-or-managed-metadata-web-service-may-not-have-been-started-please-contact-your-administrator/
Please consult your system administrator before updating any hotfix to servers. Hope this help you to fix the issue in your production environment.
I have a simple PowerShell script that uses WMI to create a web site on a Vista box. Yes, I know PowerShell has an IIS provider for working with IIS 7, but this script must also support IIS 6.0, so that rules that out.
Anyway, the script was working just fine, but all of the sudden (and I mean that literally, I made zero code changes to the script) it started creating a second, broken site for every call to the CreateNewSite method. Below is the script. Anyone have any ideas?
$path = "C:\My Path\WebSite"
$site = "TestSite"
$hostHeader = "demo.blah.com"
$service = Get-WmiObject -namespace "root\MicrosoftIISv2" -class "IIsWebService"
$bindingClass = [wmiclass]'root\MicrosoftIISv2:ServerBinding'
$bindings = $bindingClass.CreateInstance()
$bindings.IP = ""
$bindings.Port = "80"
$bindings.Hostname = $hostHeader
$result = $service.CreateNewSite($site, $bindings, $path)
The above script was just creating a site named 'TestSite', but now it's also creating a site called 'SITE_1786339847' (the number changes, but it's always similar to that). I have stepped through the script executing one line at a time, and neither site is created until the CreateNewSite method is invoked. Is WMI just buggy?
Whoops, answered my own question. I checked the raw IIS 7.0 configuration file and found an orphaned virtual directory that was associated to a site with the ID 1786339847. When I removed that virtual directory from the configuration file, the script started working correctly again.
In case anyone runs into something similar, grab the site ID for the bad site from IIS Manager before deleting it, then open up C:\Windows\system32\inetsrv\config\applicationHost.config. Scan the file for that ID and look for any orphaned references to it. Be sure you have a backup first.