From my RAD, I start up the websphere portal and remove a portlet ear(the portlet ear has several portlets) that was previously deployed on server. I restart the server.
But when I go on the portal home page and go Administration -->Portlet Management --> Portlets, I still see the old portlets.
How do I remove the old portlets from the portal server configuration?
Go the the Administration --> Portlet Management --> Web Modules.
Check if the application that contains the portlet is still registered. Delete the application the is containing the portlets.
If you don't want to delete the whole application you can click the trash bin in the view you mentioned behind the portlet. I'd however suggest to delete the application.
Related
I encountered a weird scenario. I have created an MVC2 Application and deployed it to IIS7, to 2 web sites (Default Web Site and another manually created "Test Web Site" ... they are using different application pools targeting v2.0). I am using SQL 2008 R2 Filestream feature to store files.
The problem I have is that I have a feature where the user browsing the site can download a document. The document is created in the server and the server then streams that to the client. The problem is, Default Web Site asks for authentication when user tries to download.
This doesn't happen for Test Web Site and it downloads fine.
Now, I do not have a clue what setting I need to change? The only different things I recall is that I manually created Test Web Site compared to just reusing the Default Web Site and also that I allowed inbound connections to Test Web Site (it was on port 8080).
What are the configurations needed to change so that user can download files from Default Web Site without going through authentication?
Try changing authentication settings in IIS Site->Authentication->Anonymous Authentication set to Enable
Turns out it was conflicting with the SQL Server Reports Manager.
Found this out from here: source
Is it possible to disable a DNN portal, or an entire DNN installation to everyone except administrator / host users?
I need to update a DNN website and apply new themes to differant sections of the website, however this will take some time on the live website.
I'd like to achieve similar to this "Wordpress Maintenance Mode" module plugin.
I'm aware of using the APP_OFFLINE.html file to disable the entire website, however we need a couple of admins to go in and make changes whilst keeping everyone else off the website.
There isn't a maintenance mode in DNN. What I would do is the following.
Setup a new website in IIS, beta.mywebsite.com. Have that website point to your Existing DNN folder.
Point your current website to a new folder with the App_Offline.htm file/message in place. Then have your admins go to the beta.mywebsite.com URL instead of going to the www version of the URL.
That would probably be the most straightforward way to do this for DNN without writing a custom maintenance mode module for DNN.
I started working on an existing website that uses DNN. I am having difficulty understanding and accessing DNN in their staging/test environment. In IIS there are a few different websites. How can I figure out how to get to the main Admin DNN screen by looking at the information in IIS and exploring to files. Once there I need to apply new licenses for DNN.
Thanks in advance for any assistance.
In IIS, right click on the website and choose the Manage Bindings option, that will show you the various Host Names (URLS) that are configured.
Try those URLs, and then put ?CTL=login on the end of the URL to get DNN to load the login control. From there you can login with a HOST or ADMIN account, HOST/SuperUser account would be best, as you can then go to the Host/Portals (Site Management?) page and see how many different "sites" are configured within the DNN installation.
While doing some R&D I messed up my IBM WebSphere portal Login page. I appended a custom portlet on Login page along with original Login portlet. Now the Login page is not showing up and I am unable to access Administrative tools. I cannot even revert back these changes now. I have tried writing username and password in URL but no success. Is there any other way/workaround to revert back these changes or reset portal server to original form? because last thing I want to do is a re installation. Any help is appreciated.
Edit: I am using IBM WebSphere Portal Server v7
You can export the whole portal with the ExportRelease.xml using the xmlAccess interface.
http://www-10.lotus.com/ldd/portalwiki.nsf/dx/P61t4d
After doing the export you have got the whole page_structure.
You have to search for the login page. I think the parameter was named active. Its likely false.
Try active="true". The login page is named wps.Loginor something like that.
After modifying the page structure you can run it as a script with xmlAccess as well.
WebSphere Portal 7.0 doesn't provide with a way to "reset" the Portal Server instance to its original, out-of-the-box state. Unlike WebSphere Application Server, where you can simply delete a profile & recreate a new one, this isn't possible with WebSphere Portal.
Having said that, WebSphere Portal 7.0 has the ability to support multiple profiles: http://www-10.lotus.com/ldd/portalwiki.nsf/xpDocViewer.xsp?lookupName=IBM+WebSphere+Portal+7+Product+Documentation#action=openDocument&res_title=Supporting_multiple_profiles_wp7&content=pdcontent
So, what you can do is this:
Reinstall WebSphere Portal 7.0.
Take a backup of the WebSphere Portal 7.0 instance, as per the documentation.
When there comes the time to revert to the original, restore from the backup.
That is the only definitive way to reset a WebSphere Portal 7.0 instance... unfortunately.
Get the XML of the page from other portal environment and import it.
Our farm consist of 2 web servers(We use DNN 6.0.2). If admin changes rights on a banner, module or picture, those changes are visible only on server on which that changes were done. On other server changes are not visible until cache cleaning from "Host" menu is invoked .
Is that correct behavior? Did we miss something in web farm configuration?
This is a result of individual caching on each web server. DotNetNuke Professional edition has a web request caching provider which handles this.