BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
CharynFaenza
Fluorite | Level 6

@MichelleHomes Thanks for the shout out.

 

@D_e_n_n_i_s  - I understand your pain, I truly do.  In fact, I started writing white papers about security for two reasons:

 

1. While there is a LOT of information out there, I had a hard time finding something that written, in plain and simple terms, for a new administrator and

2. So I could have something in hand to help explain SAS to my non-SAS partners in IT / IS / etc.

 

The road has been long but I would not trade it for the world!  The advice in the thread is excellent, from getting to know other admins at SGF, joining SUGA, to using Metacoda and following blogs.  The SAS community is nothing, if not supportive and helpful!

 

The only thing I can add to your list of recommendations is that the absolute, most important, non-negotiable, thing you need to do is plan.  Even if you are working in an existing environment, plan what the desired target state.  The simple act of sitting down and thinking through your requirements and how you will meet them, followed by careful documentation, will help you frame your decision making for years to come. It helps you find your sense of direction, and will help you target your deep dives into the volume of information that is out there.

 

I am sure everyone who has ever been a SAS admin will agree that you will never stop learning so you best bet is to have a solid forward-looking plan of attack so you are focusing your energies on the things that will benefits you the most.

 

I hope you stay active in the community (I am a long time lurker myself) and let us know how things turn out!

 

Warm regards,

--Charyn

 

CanteenCook
Fluorite | Level 6

I've managed multiple SAS environments for more than 10 years and I've found that the following help manage a SAS environment:

 

  1. Patience
  2. Coffee
  3. Keeping lists of things (Contact lists, HR Details, License distribution, Environment details, logs locations, etc)
  4. Have a proper way to manage # 3
  5. Constantly reading up on solutions and architectural approaches.
  6. Troubleshooting at every opportunity will pay handsome dividends in years to come.

 

Each environment is different but the above will see you through.

Lenvdb
Quartz | Level 8
Thanks for this CanteenCook

No 2 and No3 helps a lot - documenting the platform, as you say for Log locations, scripts, Licenses, etc etc...
Very apt.:-)
D_e_n_n_i_s
Obsidian | Level 7

Hi everyone,

 

I was invited to post an update on this thread that has garnered so many helpful replies so first and foremost thanks to everyone that provided such wonderful feedback !!!  If nothing else, those of us tasked with administering such a broad and deep product know we're not alone in our struggles ...

 

We finally spun up our Dev OA/VA virtual machines and had SAS perform the vanilla installation for us.  It's always nice to have them take on that job, which took most of a week !!  It's especially nice that they take on those tickets to get them escalated and resolved so if you can afford it, it's a really nice way to go.  We had a fresh install of SAS 9.4 M5 and worked through a number of issues.

 

With some delays in SAS being ready to take on the really huge job of duplicating our customized production environment, developed and tweaked over years, onto our new Dev installation, I ended up taking on this task myself.  Never forget the amazing (and did I mention free 🙂 ) help provided by SAS Technical Support.  Those folks really are incredible and walked me through many issues that I faced with such a daunting task.  I'm still in the middle of this now and the dedicated hours would have cost us a fortune (not encouraging any organizations to take a cheap way out ... lol).

 

Still, to be perfectly honest, our team learned a TON even about our production environment as a result of this.  We had some customizations that we didn't fully understand (implemented by two separate teams recommended by SAS when we were very new to SAS) and others that were implemented on one Prod server and not on the other when they should have been on both.  In putting together the list of customizations, originally for SAS to install for us, we learned of several changes we initially missed and in so doing were able to better set up our Dev environment.

 

Thinking ... well, it's just Dev.  Besides being able to start testing releases and figuring out fixes BEFORE moving them to Prod (Best if Dev mirrors Prod as closely as possible), we're also going to have SAS perform a fresh install of SAS 9.4 M5 to bump us up from M4.  With all that we've learned, we should be able to install our own customizations MUCH smoother for Prod than we stumbled through in Dev (make that still stumbling through) and have a stronger implementation by our newly learned lessons.

 

Whew - Didn't mean to write a novel, but it has been awhile.  Please feel free to share your experiences as we all benefit from the shared knowledge !!  Until next time, keep hanging in there and know that you are not alone ...

 

Thanks,

Dennis

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 33 replies
  • 4840 views
  • 46 likes
  • 13 in conversation