My primary use case was patching.
My primary use case was patching.
Earlier, we had Windows Server Update Services in place. With that, we were only using internal patches. But with BMC, we even configured applications, like IE or things that were Java-related. When we scheduled the jobs, it worked fine. It saved us time and there was no need for resources to monitor them. The jobs worked at the times we scheduled. And, if a job failed we monitored for that.
Also, BMC did not have impact in terms of network-related issues. For example, previously, if we staged patches in the daytime, they would use more network bandwidth.
In addition, that one BladeLogic was used for almost in 1,000 servers. If we had to do that manually it would be a very big headache.
In terms of improving collaboration between IT operations and security teams, there was a security team and they were using Nexpose scanning to analyze the servers. But it was not up to date. We were informed that the patches were not installed and we worked on pushing the packages to the servers which had not been updated.
Overall, it saved me time.
We didn't use most of the advanced features. We just used it to implement patching where we needed to run scheduling and do automation jobs.
Jobs were supposed to run automatically and, if there was a failure, it was supposed to fix it. But that was not happening. When we added 20 servers to one job, and one server failed, the job was showing as completely failed. The next job was supposed to integrate with some applications. For example, there was a BIG-IP load-balancer. If we wanted to run it as a BMC job, first it was supposed to take out from the load-balancer and then the job was supposed to run. If there were particular services there, like SQL services, they were supposed to be stopped and then the job was supposed to re-start triggering. But that was not happening.
The dashboard has many features but we couldn't use it because, somewhere, the communication was lost. When we tried to open it, it would not open. We mostly operated the solution manually. We did not have a lot of resources for this particular project so we were unable to put in a call to BMC to try to get this fixed.
When trying to get accounts for BMC BladeLogic we were asked to raise a ticket. But we should first be asked if we've had some minimal training on the BMC BladeLogic. Only then should they go ahead and provide accounts. Without any knowledge of the product, we used the KB articles to start working. As a result, we definitely did not have full knowledge of BMC BladeLogic. We ended up asking simple and silly questions, which is not good. They need to provide a minimum of knowledge with training on YouTube or somewhere else. Currently, there is no video training available on YouTube. And outside of their organization, there are also there no training centers.
Another area for improvement is group scheduling if I'm trying to do all the servers. For example, if I want to do all the 2012 Servers - since the patches are the same for all of them - I can't do so. Maybe that feature exists but I'm unaware of it. That kind of filtering would be helpful.
I would also like to see scripting integrated with BMC and integration with PowerShell as well. But if we are trying to invoke a simple command to stop services, it would be good to have that. Currently, we need to depend on PowerShell only. If we're trying to do some of the servers, the first thing we need is for the services to be stopped, before going to the patching. We need to write a script for that and add it to the BMC tool and then we can start triggering the jobs. Otherwise, we will be in trouble when a service is running and the server is being patched. Something like radio buttons to stop the services would be good.
There is no option to see all the servers we patch and we cannot find what the server status is. Of course, we can what has been completed and what is pending and which servers have failed, but we cannot find server status from the BMC tool. For example, is the RDP up or not. We are using separate scripts for that.
We are doing that 150 or 200 servers at a time. If some of the servers fail, we don't know exactly. It shows, out of 200 servers, that ten or 15 servers have a "failed" status. So we need to log in to the servers, if we don't know scripting. That's why we are using the scripting, to know what the RDP status. We check manually or we use the scripting to find the status on them.
In addition, we are always getting complaints from the security team. They say, "You guys did patching on these servers, but there are still some packages are missing." If BMC is not integrated with the security tools, we will definitely continue getting complaints like that. BladeLogic needs to be integrated with security tools, like Nexpose and Cisco. Then we can see which servers are patched successfully and there will be no complaints from security.
I worked with it for almost two-and-a-half years.
BMC was very helpful in those areas where we submitted tickets. Overall their technical support was very good. It helped a lot.
The setup is not too complex compared to SCCM.
I came to the project without any knowledge of BMC BladeLogic. We started going through the documents from the BMC BladeLogic KB articles and then we started working on the BMC tools. That was it. We didn't have any training on BMC BladeLogic.