I am trying to bring back a list representative of an IIS website's structure using the Web Administration cmdlets. What I am after is what you see in the inetmgr (Internet Information Services Manager) treeview. I see that there are cmdlets to Get-WebApplication and Get-WebVirtualDirectory, but how do I get plain old folders which may have been created under the root of the site?
Is there some cmdlet that I am missing missing? Is there a single cmdlet which will just retrieve all of these items as a collection and allow me to interrogate the type?
If you just want to interrogate the IIS listing of sites and go from there, you can always do:
cd IIS:\sites
dir
Then you can iterate each object for the physical path.
Related
I created a workflow that provisions O365 groups via an azure function app which runs powershell (based off this code on github). I noticed that the default site collection administrators are the owners of the created group. Most of the time i just want users to be able to invite more people to group but not create subsites etc..
For now I always have to change administrators manually. Is there any way to change the site collection administrators via powershell (or any other language) in an azure function?
I already tried to just execute Connect-SPOService and Set-SPOUser in the function but there is no such cmdlet in the context of the function.
Goal would be a to have some code/function to change site collection administrators via the microsoft graph api or some other means. Maybe it is possible to add the missing cmdlets where the function can access it?
To use PowerShell modules within an Azure Function, you'll need to upload your modules to your function app, either by bundling them with your deployment or using Kudu. The answers to this question from Francisco and myself could be helpful to you.
Working with an mvc4 application that runs in IIS 7.5, the site though exist once on disk, has over a 100 url's pointing to it. This is because the site displays content based on the country that needs to access it.
Due to this, the site can have over a 100 bindings, which is very hard to manage.
I am looking to automate the creating of the site in IIS using powershell. I would run this during each deployment to ensure each of my environments are identical (dev, qa, production).
The powershell script would delete the site and recreate it, applying bindings, configuring it etc. I am a newbie to powershell so I would appreciate any help with this.
You should be able to use the PowerShell IIS Administrative Cmdlets. I show how to automate creating and deleting web applications using them on my blog that should get you started.
I have a script I use when creating a website and AppPool in IIS 7+ (under .net4, Integrated pipeline, etc) and thought you might find it useful as its a bit simpler than some of the other answers. It will delete the site and replace it if it already exists making it good in continuous integration scenarios.
Use it as so:
CreateSite.ps1 [WebsiteName] [AppPoolName] [Port] [Path]
If you are reinstalling the site, you will need to stop it first. That is done as so:
StopSite.ps1 [WebsiteName] [AppPoolName]
you gan grab the scripts from my gist
There is an IIS provider for PowerShell which you can use to manage IIS from PowerShell.
Take a look at the available cmdlets.
I need to disable access to a SharePoint application between 6 PM and 7 AM. SharePoint 2007 doesn't seem to have an out-of-the-box "maintenance mode," so I'm looking for a solution. Presently someone moves users out of a security group to limit access to the application, so in the very least, automating that process would work.
Is there a PowerShell script or SharePoint feature or something I can add to my server to enable a maintenance mode for an application? Perhaps sample code for an SPJobDefinition?
you could automate the removal of users in a bat file with the
stsadm -o userrole -url <url> -userlogin <DOMAIN\name> -role <role name> [-add] [-delete]
Check out this link for a way to enumerate sharepoint with Powershell:
link
An IIS method is to restrict access by IP address. I've used that before successfully and it should be quite easy to write a PowerShell script to do it or use the IIS admin scripts.
I'm not aware of SharePoint methods that do this. There is the quiescefarm stsadm command but that applies to InfoPath forms only.
If you want to make the site completely inaccessible, you could write a script to add an app_offline.htm file to the SharePoint site's root directory.
This would prevent anybody from accessing the site, so it might not be ideal if you need to allow admins to login. But it might be a solution if you have a backdoor.
what is the best way to find which are the default crawling accounts used for crawling for all the shared service providers in a Farm in MOSS
i would prefer if any one can tell me using Shared Service Provider Database
Well getting the value for one SSP is easy:
ServerContext serverCtx = ServerContext.Default;
SearchContext searchCtx = SearchContext.GetContext(serverCtx);
Content content = new Content(searchCtx);
Console.WriteLine(content.DefaultGatheringAccount);
The trick is getting it for all SSPs. As far as I can tell there isn't a public API to list all the SSPs for a Farm. There clearly is a private one since:
stsadm -o enumssp -all
returns a list of all SSPs. So your choices are:
Parse the results of the stsadm command to get the SSP Names
Walk through all the SPWebApplication objects in the system and use that to find what SSPs they belong to
Use reflection to call into the sealed, private API of MOSS to find out the names of the SSPs in the Farm.
Since you should only have a few SSPs in a Farm, the easiest way is to just check the SSP web admin screen for each one.
Checking via the database is problematic because SharePoint SSP databases could be stored all over the place on different machines.
Is it possible to create a user with permissions of both a local administrator and NETWORK SERVICE?
I've got a Sharepoint timer job which runs stsadm for which it needs local administrator permissions. On the other hand temer jobs are also used by other services which need NETWORK SERVICE permissions and those to sets of permissions only overlap, so I need a user with the "sum" of the permissions to run OWSTIMER under.
(I know that most of the operations you can perform with stsadm sharepoint administration API can be used, by in my case it is the operation which moves a site collection between content databases for which there seems to be no API equivalent).
I recommend always using domain accounts - SharePoint works best on servers connected to an Active Directory server. For production environments a best practice is using a least privilege account. I always create the following domain account dedicated to SharePoint services:
DOM\spservice
You do not need to grant any special privileges to this account as SharePoint will automatically do this for you when you specify the account during setup.
I can't help you with the user permissions (Lars hit the important points), but I wanted to share some information that may be of use.
You mentioned that you're trying to move site collections between content databases and haven't found an API the can be leveraged. Have you looked into SharePoint's Content Deployment API (also know as the PRIME API) to see if it can assist? The types of which I'm speaking are located in the Microsoft.SharePoint.Deployment namespace, and they provide you with mechanisms to export (via SPExport) site collections as CAB files and then import them (via SPImport).
SharePoint leverages types in this namespace for its own content deployment paths and jobs (in MOSS); it's also the API that is leveraged by the STSADM.EXE executable for export (STSADM.EXE -o export) and complementary import operations. For that matter, it's also used by SharePoint Designer for it's site "backup" and "restore" operations.
For an example of how this API can be leveraged, check out the SharePoint Content Deployment Wizard tool on CodePlex (http://www.codeplex.com/SPDeploymentWizard).
I hope this gives you a potential alternative to shelling out to a command line in your timer job!