I'm working with IBM's WebSphere Application Server 6.1 and 7, and the more I work with it, the more I find myself spending a lot of time drilling down to components. I understand that with WebSphere 7, they introduced tasks that allow high level pages to be bookmarked; but what about certain components that are deeply buried?
A good example of this would be for Application Server JVM properties. To view or change these, the following links/drop-downs must be navigated (this is for WAS 7):
Servers > Server Types > WebSphere Application Servers > [server name] > Java and Process Management > Process definition > Java Virtual Machine
Drilling can become quite tedious. Is anyone aware of the capability for shortcuts, or bookmarks to these component pages?
If you're frequently making the same changes to your servers, I would suggest scripting those updates with the wsadmin tool that ships with WAS. It might take a little time to learn and get the scripts just right but once they're setup, common configuration tasks take no brain power and very little time.
http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.base.doc%2Finfo%2Faes%2Fae%2Ftxml_scriptingep.html
Related
I wanted to run the same application for different environments in single app websphere server . Can anyone have steps please.
If the server is part of a network deployment installation of WebSphere you can set an edition name when you install the application through the admin console or wsadmin. Then it will be managed by the editions manager. So you install the same app multiple times with the same name but different editions and each edition can have a different ear, can have different resources and shared libraries and so on.
This page in the documentation discusses the editions feature so you can see if it's what you're looking for.
I think you can also override the context root of the application at deploy time, using either wsadmin scripting or the admin console, so you could have /appfortest /appforload /appforprod, etc. Even if it's the same ear deployed multiple times, Websphere will treat them as different apps at different context roots.
I want to automate applications/roles/features deployment (unattended) on Windows 2012 R2 Infrastructure, this project needs many hours of programming, this is why i'm asking here.
I want to deploy the following applications and roles : Active Directory, DNS, Sql Server 2012, Citrix XenApp Server, Citrix XenDesktop server, Citrix Datacollector, Citrix Licence server, Citrix Storefront server.
So the basic deployment will be on 8 servers (already installed on ESXi, with ip configuration only).
I imagined this scenario :
I will fill a CSV file that contains all of information, and execute Powershell scripts to deploy everything, we can imagine 1 script that will call different scripts for each components (sql, ad, dns, citrix etc..)
I don't want to depend of any tool (sccm, puppet or whatever..), this is the reasons why i want to create it from scratch -> But maybe i'm wrong.
I also read that there is a new feature called Powershell DSC, to simplify application deployment http://blogs.technet.com/b/privatecloud/archive/2013/08/30/introducing-powershell-desired-state-configuration-dsc.aspx
There is a simple example : if you need 4 iis webserver then, execute this code :
Configuration DeployWebServers
{
Node ("test1.domain.com","test2.domain.com","test3.domain.com","test4.domain.com")
{
Windows-Feature IIS
{
Name = "Web-Server"
Ensure = "Present"
}
}
}
DeployWebServers -OutputPath "C:\scripts"
Start-DscConfiguration -path "C:\scripts" -Verbose -Wait -Force
But in my case i'll have only 1 server per application/roles or feature, if i understand well, this feature is interesting only if you need to deploy the same configuration on (x) servers
What's your advice? Should i choose to write powershell script from scratch? Or choose a solution like puppet or chef (much easier), but in this case i'll be dependant of a tool.
The best solution would be to use a sql database -> The final goal of my project is a web application with a database who will execute my powershell scripts to deploy my infrastructure
Of course from this web application, I will populate my database through forms, and my powershell scripts will query this database to get informations (ip address, client name, domain name, password, users...)**
Thank you for your advice.
Chef or Puppet will be the easiest way forward and both tools have been around for long enough for you not to worry about them disappearing off the internents. Both work, pretty much, out of the box and will get you up and running in a considerably lesser time than if you were to design your own system.
Having said that, a benefit of going with a PS solution is it doesn't require any agents installed on destination boxes(connectivity thanks to WinRM). Ultimately you can wrap it up as a Powershell module, hand it out to your sysadmins and retain full control of what's going on under the hood.
A PS solution will give you full control, better understanding of underlying process - but that will at cost of time and other design headaches.
To sum up: if you have the time, the will or a specific use case then go with PS. Otherwise do what the big boys do and save yourself reinventing the wheel - or seventeen.
Disclaimer: I did the PS thing for a previous employer.
If you're looking for a repeatable deployment solution, and you don't might using some light, free, infrastructure, I propose you use Windows ADK 8.1 and MDT 2013 (if you're using Windows Server 2012 R2). You can develop a front end to chose a deployment type. Rather than using a csv file, all the information can be contained within the Task Sequence, and can be configured to trigger tasks on different conditions.
Johan Arwidmark from deploymentresearch.com has developed a great example of this called Hydration Kit, with full Step-by-Step Guide that sets up a Configuration Manager 2012 R2 infrastructure, running on Windows Server 2012 R2 and SQL Server 2012 SP1, in either Hyper-V or VMware. If you ask him nicely, he might allow you to use his work as a base for your project.
What are the fine tuning configuration for Apache Cassandra for windows machine,I have seen "Unable to create new native thread" due to less number of "max user processes" in linux and the one of the solution is [1]
[1]http://vanjikumaran.blogspot.com/2014/01/unable-to-create-new-native-thread-and.html
Therefore, what are the best practices for Apache Cassandra configuration and OS settings for windows?
The best practice for "Cassandra on Windows" right now is "don't". There are a bunch of edge case issues that crop up on Windows because things like file handles behave slightly differently and do not have the same guarantees they do on Linux.
It works well enough to run a dev/test instance on your Windows box for development purposes. But for anything other than that you should really use Linux, as that is what everyone else uses, and it has the most testing.
Here is a blog post with the current status of Cassandra on Windows:
http://www.datastax.com/dev/blog/cassandra-and-windows-past-present-and-future
I need a background application to support my client application, which should always run on the client machine regardless of the main client application is running or not.
Windows Service was my first choice but problems I faced with Windows Service were: ease of control over windows service through main client application, release and installation of patches to the windows service and troubleshooting if windows service fails to run.
So, I started thinking for alternatives to the Windows Service and found that a Windows Forms application with NO visible forms can do it for me. This invisible app should start with system startup and keep running all the time, doing all the work that a Windows Service would do. But before I go deeper into the development, I want to explore the pros and cons of this approach.
Any suggestions/comments on this approach?
Your requirements are more suited for windows service. Main advantage with windows service is that it will start as soon as system comes up, irrespective of anybody is logged into system or not.
To sort out deployment issues, you build your business logic into separate assembly and call the necessary function withing windows service. This way you can deploy just the modified assembly.
Winform application with invisible form will not serve the purpose. HTH
That's not possible. User-mode applications must be started by a user, and will not continue to run when that user logs off. That's the purpose of the SessionEnding event: to allow you to shut down your app gracefully when the user logs off or the computer is shutting down. You can't just start something at system startup and keep it running all the time.
You need a Windows Service for that. But you should be aware that under Windows Vista and later, a service cannot interact directly with the user. They run in a separate process and are restricted from displaying their own UI. It's not clear from the question exactly what your needs are, but this is an important limitation of a Windows Service that is worth considering. A proper design really shouldn't require this, but there are apparently a lot of people to whom this new, more secure behavior is a real surprise. I explain this in more detail in related answers to this question and this other question.
Does anyone have a good guide to capabilities of Windows Services under XP? In particular, I am trying to find out what happens when a program being run as a service tries to open windows, but hasn't been given permission to interact with the desktop.
Basically, I have a program that is/was a GUI application, that should be able to run as a service for long term background processing. Rewriting the program to not display the GUI elements when doing background processing is a major effort, so I'd like to see if there is just a way to ignore the UI elements. It is sort of working now, as long as too many windows aren't opened. I'm trying to figure out what limits I might be running into. Ideally, there would be an MSDN page that discusses this, but I've had no luck finding one yet.
Generally, services should be designed to not have any visible UI. The entire point of a service is to run in the background, without UI, unattended. (Think SQL Server, IIS, etc.)
In most scenarios, a separate application controls the service's operation, should a GUI be needed. (Continuing the samples I just mentioned, SQL Server Management Studio, IIS Manager, etc.) These separate applications configure and manipulate the service (and occasionally, if needed, bounce said service).
If your service requires occasional UI, and said UI can't be isolated to a control app, then you probably should reconsider the fact that you're using a service to begin with. Perhaps a UI application which resides in the system notification area is the right pattern to use? (E.G., Windows Live Communicator.)
A service in Microsoft Windows is a program that runs whenever the computer is running the operating system. It does not require a user to be logged on. Services are needed to perform user-independent tasks such as directory replication, process monitoring, or services to other machines on a network, such as support for the Internet HTTP protocol
Usually it is implemented as a console application that runs in the background and performs tasks that don't require user interaction.
The installed services can be configured through the Services applet, available from
Control Panel --> Administrative Tools in Windows 2000/XP.
Services can be configured to start automatically when operating system starts, so you dont have to start each of them manually after a system reboot.
Creating a Simple Service - MSDN Article
Writing Windows Services Made easy - Code Project Article
Five Steps to Writing Windows Services in C - DevX Article
If you should be thinking of eventually migrating to a newer OS such as Vista or Server 2008, you will find that you cannot give a service permission to interact with the desktop at all. Therefore, from the point of view of forwards compatibility, you should design your service to not require it.
A service in Windows XP can interact with the Desktop if its "Allow Service to Interact with Desktop" property (MMC -> service properties -> Log On tab) is checked. It is also possible to do so by doing the following:
hWinstation = OpenWindowStation("winsta0", FALSE, MAXIMUM_ALLOWED);
SetProcessWindowStation(hWinstation);
hDesktop = OpenDesktop("default", 0, FALSE, MAXIMUM_ALLOWED);
SetThreadDesktop(hDesk);
But be aware that presenting UI from a service process in Windows XP will almost always lead to a security problem (see Shatter attack). You should try to break out the UI part of your application from the service.
Usually the service won't have permission to write to the window station and desktop, so it will fail; even running applications that load user32.dll can fail simply because user32 has initialization code that wants to talk to the window station and can't get access to it unless the service is running as an administrator.