I have a requirement in which I am required to have a ready to use image of the SharePoint 2013 development environment with all the necessary installations like SQL server, language pack, etc and configurations already done- App configuration, service application configuration, search configuration etc, which the developers can directly use by either mounting it or by running it and right away start the development.
The environment can be considered here is single server environment with all the tiers in the same server. However any suggestions for the multi-server environment will also be helpful.
Thanks
Related
Is it possible to deploy installers (for example Chrome browser .exe file) to install on Windows client computers across all office buildings using OpenLDAP? The OpenLDAP is installed on CentOS 8. If it is not possible can Active Directory Help Me?
Why would you use a directory service to store binary files? This might be possible but it's a terrible idea.
Active Directory is a broad suite of tools. AD Domain Services is basically the OpenLDAP equivalent https://social.technet.microsoft.com/wiki/contents/articles/699.active-directory-domain-services-ad-ds-overview.aspx and doesn't do what you want
AD GP (Group Policy) allows you to push software https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/use-group-policy-to-install-software but if you're only using it to push a Chrome installer, it's overkill to set it all up. It does work though!
You can also use SCCM (oh I guess it's called MECM now, haven't touched it in a hot minute).
I am building a SharePoint 2013 provider-hosted app using the high-trust model. This allows a customer to deploy the .app to their App Catalog and make it available to all SharePoint Sites. The provider-hosted portion of the app runs in an IIS box (cluster) which the customer also deploys (on-premise) with setup instructions and automated tools.
The .app file structure includes the application manifest - which specifies the precise endpoint where the provider-hosted portion resides, and also specifies whitelisted endpoints which the add-in can call. These are all specified by entering in URLs, hostnames, and port numbers into edit fields in Visual Studio in the 'Deploy App' form just before the .app file is built and digitally signed.
This seems to work just fine for a single app built by IT folks internally, if the org is small enough... but I really want to be able to distribute this solution to more than one customer. In order to do so, I would have to ask the customer for their respective endpoints, enter them into my build tools, and rebuild the .app for them. This just doesn't seem right... no customer wants to talk to the developer first and have a custom-built app. And why should they? No code is changing...
Upon investigation into the .app file format, it turns out it is really just a simple .zip file - and inside (voila!) there is the app manifest! Unfortunately, if you edit the app manifest and re-zip the file, the digital signature is broken, and the .app no longer works. (grrrr...)
What I want to do is simply reconfigure the app manifest to match the environment where it is deployed. This can happen programmatically during setup/installation time, or perhaps even just prior to download, but cannot be a process that involves developers typing into visual studio and pressing Rebuild. That simply won't scale.
Is there a tool that exists that can help with this problem? If not, does anyone have experience with the signing of .app files programmatically? I'm open to skinning this cat in any way possible.
This is a wild idea and not maybe even possible.
Create web ui, where clients enter their endpoints.
Have internal process that invokes MSBUILD/TFS to package app with endpoint
change app manifest with pre-build powershell
Then provide app via email or download?
http://www.sharepointconfig.com/2013/10/building-sharepoint-2013-apps-with-tfs-2013/
This is more of a workaround than a true answer - but would work:
For on-premise deployments of high-trust SharePoint 2013 apps - build the application with "known endpoints" - essentially hard-coded endpoints that can be deployed locally. Then instruct the customer to redirect those endpoints using DNS records or hosts file entries. In addition, the client would need to generate a local wildcard certificate signed by their own trusted root in order to satisfy the SharePoint 2013 app model requirements for appdomain and server-to-server communication.
This is by no means ideal, but for certain environments it might be the most practical approach. This also allows scaling for the IIS WebApp to occur at the customer-site, where it realistically belongs for a high-trust app.
This approach avoids the need to automate build tools and also avoids building a separate instance for every customer - both of which are somewhat undesirable. It might, for those reasons, be slightly less costly - but it also pushes some responsibility to the customer. Namely - hard-coding a DNS entry locally for machines in the topology.
I am in a situation where the current web server is a production environment and there is no development environment. It is running Joomla on an IIS Web Server and is an Intranet site with all of the security, IP restrictions, Certificates, and whatever else required to run an enterprise level Intranet site.
I am wondering what I can do to set up a development environment to work within (preferably using some type of version control).
I have full reign over the IIS server, and I have had a co-worker set up a VM clone of the current system to work with, however the security is making it difficult to work with and set up.
I would like to not use Visual Studio as I don't believe I have a license for it; however I can get it if need be. I would like to stick with Notepad++ if at all possible.
Thank you.
If you're wanting to literally take the site content out and be able to edit and work without any of the security restrictions of the production environment, there's a couple of ways you could do it. However, it's going to depend on what DB the system is running with.
Joomla, regardless of what web platform it is running on, is coded in PHP, so you don't have to worry about getting visual studio. You can use Notepad++ as normal.
Option 1 - IIS Clone
If you can take a SQL backup of the database, you build a from-scratch box with IIS. You'd need to add the PHP drivers to IIS to do this. Go to Microsoft's site for more info:
PHP for IIS
Option 2 - Apache Port
You can make an Apache box using WAMP to run, if you're using a Windows machine. PHP is PHP, on any platform, so it should work without modification.
The tricky bit will be the database, depending on your situation. If the database is MySQL, you can import your database backup and be good to go, after changing the config files for the Joomla site.
If the site used MSSQL, it's a little trickier. You'll need to install an MSSQL PHP plugin to get this medthod to work. There's plenty of instructions online on how to do this, it's a case of finding the right one for your implementation.
Live to Development Migration
We are currently migrating some sharepoint sites from external live environments to development environments hosted on vm's. The sites are a mixture of websites and intranets. We have not had access to the live environments so can not specify structure of the sites.
The sites do have some customisations applied. Some are customisations are packaged via wsp packages for which we have the source code (somewhere previous developers have left it need to find it)
The sites setup we have no knowledge so the objective is to restore live back to a development vm so we can bug fix and make enhancements moving forward.
What steps should be go through for this.
We have outlined the following steps:
Take a copy of the content databases/s
Take a copy of the wsp packages straight from the live environment (using powershell)
Create site collections from live on dev
Restore the content databases from live on to these.
Deploy the wsps from live on to dev.
Activate the features from live on our development vm's.
What other steps are missing as I am sure they are.
What I would add here are:
Make sure your notifications don't go to the users of live environment
Make sure your BDC and custom connectivity components don't modify or otherwise load production external data sources
Document and verify (using PowerShell) that all assets are deployed accurately, because sometimes you'll face issues such as event receiver registration, etc.
Make sure your InfoPath forms are reconfigured to use the updated data sources
Make sure your Alternate Access Mappings and Incoming/Outgoing Email settings are adequate
on Sharepoint development purpose. on installing sharepoint2o1o whether standalone option or server farm better suited for developememt
Standalone will install SQL Express on your machine and use it for your Sharepoint instance.
Server Farm will install Sharepoint on existing SQL Server instance if you already have one on either your machine or somewhere else on the network.
So it depends whether you already have SQL Server installed on your machine or not. A standalone installation is actually what it says. It will install as a standalone product without any other product requirement.
I prefer server farm installation because I rather have full SQL Server installed and used by other apps as well. I find SQL Express installation a waste of resources when I already have a full fledged server.
SQL Express is limited to 4GB. If you think your development environment may exceed that, then go for the Server Farm. As for me, we already have a full farm for staging and production, so I get no additional benefit from running a server farm installation in dev. #Robert-Koritnik has a good point that, if you're already running a full SQL instance on your box, you might consider Server Farm just to avoid having another instance of SQL Server on the box. I tend to do my development within a VM, so Standalone works just peachy for me.
Just as a matter of interest. Dont use Standalone for ANY production environment as it limits you in that you cannot add any more WFEs or scale out at all.
If you have a SQL Server license (Not express) , then always choose Farm.