is it possible to take a backup of all the users created in openam, so that I could use the backup to configure a new instance of openam. I am using the embedded datasource for the storage.
Please refer to:
OpenDJ Administration Guide - Chapter 4. Importing and Exporting
LDIF
Data
OpenDJ Administration Guide - Chapter 9. Backing Up and Restoring
Data
By default, OpenAM creates user data under ou=people,dc=openam,dc=forgerock,dc=org in OpenDJ if using embedded OpenDJ as user data store.
Related
My Requirement is
Capture the user information e.g. name, id, email id, etc. which currently Im capturing through the excel sheet by sending the sheet to everyone. I want to automate this in Azure by creating a simple web application.
Store the information in a DB or storage.
Create Graphs and dashboards. Update the dashboards automatically as and when the informrtaion gets added/updated.
Provide users access to the Web application(Front-end) forms only.
Allow users to update the information they provided as and when needed.
Allow application access using Azure AD
What are the possible simple solutions available in Azure with minimal cost.
Thanks,
Yogesh
Have a look at https://learn.microsoft.com/en-us/azure/app-service/tutorial-dotnetcore-sqldb-app?pivots=platform-windows which is a quick start tutorial that uses https://github.com/azure-samples/dotnetcore-sqldb-tutorial. It outlines creating an application and storing in an Azure SQL DB. By using .NET Core, you can leverage either Windows or Linux app service plan which opens your options as far as pricing goes. In the repo, you can modify Todo.cs to match your user information requirements.
For allowing application access using Azure AD, have a look at https://learn.microsoft.com/en-us/azure/app-service/tutorial-auth-aad?pivots=platform-windows.
You can get started easily by using a Free tier app service plan and either basic or general DTU or v-Core Azure SQL Database pricing.
So the user seems to have overriden a file on a sharepoint list with no versioning. I don't know what SharePoint version it is, but it's definitely on prem (not online). A back-up was made yesterday, prior to the user overriding the file.
Is it possible to restore the file & restore everything back to normal from user admin/back-up? If yes, how?
As the first step enable versioning to the current library.
If there is a SQL backup create a separate site or web application and over write the database of the newly created web application with the existing backup.
The you can access the site using the newly created webapp , download the file and upload it to the original site.
Do the restoring of the database in a test environment as its not recommended to create so many web applications (More than 6).
References
https://technet.microsoft.com/en-us/library/ee748604.aspx
https://technet.microsoft.com/en-us/library/gg266384.aspx
We are developing a solution based on SharePoint 2013 Foundation. There is a new Distributed Cache service available in SharePoint 2013. When we checked the web.config for a new sample SharePoint web application, we found it was configured to use "In-proc" mode for storing session-state. Can we leverage this distributed cache service to store session state?
Also I saw powershell cmdlets for configuring session state in database in the following msdn article : http://technet.microsoft.com/en-us/library/ee890113.aspx. Is database a preferred way to store session state rather than Distributed Cache for SharePoint 2013?
Are there any other alternatives also available to store session state in SharePoint 2013?
Usually you will have to use the SharePoint Session State Service by using the Enable-SPSessionStateService PowerShell cmdlet from the article you linked to.
The SharePoint Distributed Cache Service is meant for Cacheable items, especially the Feed, Login Tokens and App Tokens. I did not see an implementation for a Session State Provider. There is a nice explanation about the distributed cache service here:
Distributed Cache Service in SharePoint 2013
The service depends on Azure or more specifically on the AppFabric caching infrastructure. You can implement your own stuff to access this Caching framework as explained here:
Caching In WCF Services: Part 2 - AppFabric Distributed Cache
As said previously, SharePoint uses the Session State Service, which in turns uses standard ASP.NET session state:
Using Session State in SharePoint 2010
As you said correctly the default mode for the state service is set to In-Proc (in memory). What you would normally do is set it to SQLServer so the Session state is saved to some database and can be retrieved by multiple servers. The PowerShell cmdlets you linked in your post do that automatically for you.
So in short: By implementing your own ASP.NET Session State Handler you could circumvent the normal SharePoint State service and leverage the Distributed Cache, however that won't be easy and maybe it is easier to just use a State database.
Somebody knows how to change the user account and authentication method sharepoint uses to connect to its content database?
It is now setup to connect using Windows Integrated Authentication but I want to change that to a local user account.
Is it even possible to do this?
Thanks in advance
SharePoint supports both types of authentication in SQL Server:
Windows authentication (the default and preferred choice) - windows credentials are used to authenticate against the SQL server. SharePoint uses IIS which runs sites in an application pool worker process. You can change the credentials for a Web application pool here:
Central Administration > Operations > Service Accounts
SQL authentication - a username/password combination is created and stored in SQL server. When you create a content database you can choose SQL authentication and then provide the username/password (which you have already created in SQL). If you want to change the auth type of an existing database, you can detach it by checking the remove option on the database settings page (it removes the database from SharePoint but does not delete the actual data). Then you can re-attach the existing database and choose a different auth type. You can manage content databases here:
Central Administration > Application Management > Content Databases
you can do it by extending webapplication
The below links will helps you
http://weblog.vb-tech.com/nick/archive/2006/06/14/1617.aspx
http://www.codeproject.com/KB/sharepoint/moss_enableforms.aspx
Whats the best way to deploy a webpart in WSS3 or MOSS2007 which has a database dependency? Should the .wsp include code to create the database, should I encapsulate the .wsp in another installer which handles the database creation, or should I supply two different packages to allow the admin to handle the backend creation?
Well, I prefer the SharePoint way where you create the databases from a SharePoint admin page in Central Administration. Just take a look at how SharePoint handles the creation of new Web Applications where you are asked to name the database server and the name for the SharePoint content database.
In other words, I would opt for a WSP only deployment. The WSP should include a database configuration page (an ASPX page) plus a farm level feature for installing a custom action link to the page inside Central Administration. The beauty of doing it from Central Admin is that it runs in a context with privileges to create new databases on the SQL server. Hence, you do not need to ask the user for login and password to the database server.
The configuration page should upon successful creation of the database persist the connection info in the SharePoint configuration page, using a custom derivative of the SPPersistedObject class. Web Parts can in turn read these settings to connect to the database.
MSI installers should in my opinion be avoided when designing SharePoint apps.
What sort of client is your webpart aimed at?
I imagine it might be worth being slightly flexible in your approach and considering multiple methods of installing your webpart.
So for someone without a dedicated DBA it might be best to have one .wsp.
(Although this should be robust enough to handle superuser's installing it.)
Alternatively go for a .wsp and a msi (or even scripts), which will give the installer
more control over exactly how it is installed.
(I'd prefer this approach, over the .wsp only approach.)