After you have installed SharePoint you need to run the configuration wizard which typically asks what your Database server is what DB Name to use, what port to use for Central Admin, etc. Then it goes through its 1-9 install process...
Our problem is on one of our servers, which has a clean database, clean 12 hive, and no answer file is to be found (nor should it), the Configuration Wizard goes straight through to the 1-10 install process. It doesn't ask any questions at all...
Why would this occur?
This behavior is expected if your server is already attached to a farm. Was the machine previously part of a SharePoint farm and removed via the farm's Central Admin? Was a clean SharePoint uninstall/reinstall performed?
Related
Can any one provide me the best practice for turning on/off the windows updates.
Do we need enable windows update by default as best practice in prod environment.
What I have done in my current new prod setup, I have installed all windows update till today in all server and done the necessary restart in the server.
Now I have disabled like below. Please correct me if I am doing any wrong so that I can learn new thing.
You really don't want to block updates all together on a production server as you will leave your system exposed to security issues.
However, as Microsoft is now pushing SharePoint CU's (Cumulative Updates) through this avenue, you don't want them to install automatically either as this could break your production SharePoint instance! You can set up your server to "download only" and then you can manually choose which updates to install.
Here is a really good article I'd recommend so you are more informed about what process you should follow that is the best practice for your organisation.
https://redmondmag.com/articles/2015/02/13/pushing-sharepoint-server-updates.aspx
Our Sharepoint 2013 Application failed to install and is stuck in a odd state. I followed the recommended approach for deleting the application using powershell commands on the hosted Sharepoint server, but it doesn't execute properly.
Visual Studio Deployment/Retract Reports:
Skipping the uninstall step because the app for SharePoint is in an invalid state and cannot be uninstalled.
PowerShell Commands
$instances = Get-SPAppInstance -Web http://mysite/sites/collection
$instance = $instances | where {$_.Title -eq 'Application.Title'}
Uninstall-SPAppInstance -Identity $instance
Executing this PS command throws...
The System Account cannot perform this action.
There is no option from the Sharepoint UI to remove the application, and retrying the install also fails. I've tried other user accounts to execute this powershell command (other than the system account), but no dice. I will have to delete the developer site collection if there is no other solution.
I'm faced this problem before on my Office 365 SharePoint Online when deploy SharePoint Hosted App. Then I submit Microsoft Service request and work with MS Technical Support Team on this issue. This problem seem to be something error in SharePoint backend database by itself (I'm not sure to consider it is SharePoint defect).
Did you check the app details installation error report? If you get the message:
"The content database on the server is temporarily unavailable."
Need help: Error 'Install App for SharePoint': An instance of this App already exists at the specified location., I'm quite not understand the answer but there is one comment from Jeremy Thake which seem to be deleted on this thread, he said that:
"…so I actually just restarted the whole environment and when Windows
came back up and I went to the SharePoint Site…the App was gone ;-)"
So here is my advice before you commit to delete your site collection:
Try to deploy your to the another developer site collection and check whether this problem still occur as the same.
Try to increase your app version or change app name/title/id and deploy to the same site collection and check whether this problem still occur as the same to your new app instance.
For SharePoint Server, try to restart IIS/Window Server if you're able to do that. Also install any latest SharePoint Update/CU.
For Office365 - SharePoint and have you have license account, you should submit the service request, if not you should wait about several day and try to remove this app instance again through UI.
Hope you can remove your app and know the root cause exactly.
I have faced this issue some times in on-premises SharePoint.
But for solving this I gave another account (or you can use 1 that you have) shell admin rights.
Note this account CAN'T be marked as a System account on SharePoint!!
Then with this different shell admin account you execute the same script. That always worked for me (I also got some strange installation behavior and needed do remove the app).
I am working SDL TRIDION 2011 SP1 version. Suddenly I am unable to see the Trdion site in Internet Information Services(IIS) Manager. Please tell me the procedure how to get it back again.
Remove Tridion Completely (uninstall), then run the installer again.
You won't loose any data (it's all in the database), and you're likely to get your server up and running way faster than trying to fix by hand.
As #bart suggested, your best option to get the web application back (assuming it really has gone), is to run the repair option with the installer. There are a lot of folder specific settings which would be very hard to recreate manually.
I have made my first webpart using WSPBuilder. When I try to deploy it using STSADM, I get an error stating access is denied. I am an admin on the machine (well it's a VM).
Also, with WSPBuilder, do I need to change the config files (I assume no as the point of the tool is to automate this)?
Thanks
There could two reasons for your problem
Even though you are the admin of the system you may not have privilege in central Administration. So login in the system with the user name of sharepoint administrator and try to deploy it.
There may be a problem in the way you created the WSP. if you deploy webpart using WSP then there is no need to edit the config file manually. Recently I have created a blog which explain how to create simple webpart, creating WSP and deployment. If interested check it out http://www.allaboutmoss.com/index.php/2010/03/22/hello-world-sharepoint-webpart-for-beginners/
It sounds like you don't have enough permissions to add the webpart. What OS are you on? If it's Windows Server 2008 R2 etc you will have to run the command prompt as an administrator or turn off UAC for administrators. As for the config WSP builder will create you a file called solution.txt which contains the Id for your solution. For more control over what it is doing you can add a WSP Builder config file to your project called "WSPBuilder.exe.config". An example one can be found in "C:\Program Files\WSPTools\WSPBuilderExtensions".
Go to --> RUN--> SERVICES.MSC--> check the following service is started or not.
Windows SharePoint Services Administration, if not pls start this service. if the wsp is deployment done. go center admin--> Operations -->Global Configuration -->Solution management . This page has a list of the Solutions in the farm. check ur wsp in this list.
I have a sharepoint MOSS 2007 Install on a server and need to move it to another new server. Can I just ghost the complete server to the new one or do I need to install and configure the complete server again?
Any suggestions appreciated.
As far as I know you will have to reinstall MOSS on the new server as during the configuration process many settings form the acutal server are stored to the MOSS configuration database. So just moving the MOSS software and database won't work. Even just renaming the server on which MOSS is running will probably lead to a MOSS error.
To make it easy to move MOSS to another server in the future you should think about visualization. By this you can move the server to every server you want just by installing the visualization software and moving the virtual machine to the new host server.
This strategy will also help you in case of emergency when the MOSS server crashes due to a hardware error.
Your best bet would be to do a clean install on the new machine. This gives you the freedom to properly configure your machine(s) - name databases, pick ports for the Central Admin, SSP etc.
Resist the temptation to "upgrade" to a newer operating system (2003 to 2008), a new database (2000 - 2005 - 2008) or add service packs or the infrastructure update. If it isn't installed on the current production system - then don't install it on your new machine. Make a mirror of what you have and it will be much smoother.
Once the new server is configured the way you want it - just do a full backup from the Central Admin page on the old machine - and run a restore from the Central Admin on the new machine. This will pick up all the customizations etc that you have on the old site.
Once it's restored - and you've tested it and it's working the way you expect, run a full backup from the Central Admin page on the new server. That becomes your baseline for moving forward.