(imported topic written by ktm_200091)
I did my test rollout of June’s patches and included Office 2007 sp2 in June’s Baseline. The action completed successfully and when I look at the pcs they still state that office 2007 sp2 is relevant yet if I look at the action it shows that it was not releveant when the baseline was applied.
So Do I have to put items like this in a separate action? are there other types of items that cannot go into a baseline?
(imported comment written by BenKus)
We would have to look at it in greater detail to figure out why the SP didn’t run, but the service packs tend to be a little finicky about things like having other updates pending so it might have run but decided not to continue because other updates were pending?
In general, I would recommend deploying SPs independently of other patches.
Ben
(imported comment written by ktm_200091)
I did a second action and had the service pack by iteself and it installed fine and pland on deploying separately.
Ben,
Is the some type of document / manual which describes all the bits of Wisdom about how Big Fix works? I seem to be able to make every concievable error because I am randomly trying things as opposed to following cut and dry proceedures.
(imported comment written by BenKus)
Hey ktm,
In my experiencs, each company seems to act a bit differently and has their own conception of the best way of doing things… Which is why we build our product to accomodate as many people/procedures as possible…
After working with so many customers for many years, we do have a sense of the different approaches pros/cons for configurations, testing, deployment, handling exceptions, and so on… but we don’t consider it our place to make blanket best-practice recommendations for things like patching, security, power management, etc. (outside of BigFix-specific configurations for our product).
In our training classes and docs, we do try to touch on different options available, but we leave it to you to decide…
If you want to work with our services team, they will come analyze your environment, make recommendations, and train you on the best way to approach it…
Ben
(imported comment written by ktm_200091)
Ben,
It seems that there are a TON of undocumented “features”, not much of which is described in the training that you speak about.
(imported comment written by BenKus)
I would say that there are lots of ways to utilize the system, but I wouldn’t call them “undocumented features” (we certainly want people to use them and we aren’t trying to hide anything)… Maybe a couple of examples would help?
Ben
(imported comment written by ktm_200091)
Lets start with
Some fixlets can’t be put int baselines
Big Fix changes fixlet content so you have to constantly re-sync baselines and then reissue baseline actions
If a user shuts down their pc without taking the post action restart - big fix will want the user to restart again.
If a user shuts down their pc without taking an install action, time does not fall off the deadline to accept the patches when the workstation is restarted.
(imported comment written by BenKus)
Hey KTM,
I certainly don’t disagree that there are a lot of nuances in individual behaviors… We do our best to design products and interfaces to make as many things as intuitive as possible… We also try to make the product self-document as much as possible… but some of the things you are mentioning only matter in very specific situations…
Question for you: If we are trying to improve this area, do you suggest we focus on training? or documentation? or something else?
Ben
(imported comment written by ktm_200091)
Ben,
Primarily Documentation, and some product improvement. Training is another story, Essentially the training class I took was a guy reading from a powerpoint slide show and showing very basic operation. The only valuable training I have had has come from this forum.
Here’s where documentation improvements could be made:
State if a patch can/can’t be put into a baseline
I understand that content may need to be changed. If it has been changed, document the change in the fixlet. There shouldn’t be a requirement to look elsewhere.
Product improvement:
A method to resynch content changed without having to re-issue actions - This is a pain with having to put each re-issue action through change control and gets alot of questions from my management . It is more troubling when I cannot explain the reasoning of what was changed and why.
Show fixlets in relation to what baseline they are in
Update the open action count if the fixlet is a member of an open baseline action
In general the product works and works well but the promise by the sales guys that this is a low effort product and it saves effort is completely bogus. I’m spending 2-3x the effort patching with this product as I was with WSUS with not too much improvement to show for it.
The one shining part of Big Fix is the analysis- this tool is great!!! I can get back info on status of services and configureation parameters quickly and accurately. It is significantly easier than writing a .vbs script and creating a way to collect the info. It too suffers for lack of documentation as writing the code requires one to know big fix language and there’s no document describing how to write it. I have to say the forum is a great source of knowledge and an analysis can usually be put together by piecing together parts from what others have done and posted here.
(imported comment written by BenKus)
Thanks for the suggestions KTM… Here are some comments…
Most comments I personally hear about BigFix vs. WSUS are that BigFix offers much more features, more control, and saves time in deployment costs, hardware costs, and day-to-day operations. It sounds like your recent baseline experiences were frustrating, but hopefully going forward, things will be smoother for you.
Ben