Getting Data In

Deployment server connection to License Master

umesh
Path Finder

Hi team,

I have a question related to Deployment server Connection to License master.

My deployment server is connected to License master and we changed the licnese master and we didnt change the master uri for Deployment server and the last time it got connected to license master was 23 months ago. 

As of now i didnot see any impact observed.

What happens if we dont connect our deployment server to license master. Is there is any impact.

Please do let me know .

I also wanted to know if we can change the master URI address using Splunk GUI. it is currently configured with different Master Uri .

Please do let me know on this.

 

Thanks & Regards,

Umesh 

0 Karma
1 Solution

gcusello
SplunkTrust
SplunkTrust

Hi @umesh,

as @PickleRick said, you don't need to connect the DS to the License Master because you don't locally index anything on the DS.

Eventually you can use a Forwarder License for it.

ciao.

Giuseppe

View solution in original post

gcusello
SplunkTrust
SplunkTrust

Hi @umesh,

as @PickleRick said, you don't need to connect the DS to the License Master because you don't locally index anything on the DS.

Eventually you can use a Forwarder License for it.

ciao.

Giuseppe

isoutamo
SplunkTrust
SplunkTrust

Hi

my two cents. In technical point of view you probably not need that connection. But in license compliance point of view you should have a valid license on DS too. And as it's not a HF you need a valid enterprise license for it. As @PickleRick said if you are Splunk Cloud customer you can order 1B license for DS from Splunk Support to use with DS. If you have valid enterprise license then just connect to that LM.

At least all cloud courses it's pointed that you need that license and you should order it from support. I haven't read trough (lately) splunk license agreement and cannot said 100% sure what it's said now about this. But at least earlier it was so that all enterprise instances should connect to LM even those are not indexing. Only exceptions was HF if they are using a local forwarder license.

r. Ismo

PickleRick
SplunkTrust
SplunkTrust

My additional two cents 😉

If you use the same forwarder license on several HFs you might run into trouble with duplicated license detected in your environment. I'm not sure if it affects only MC or is it "deeper" than that but it's worth noting that it can happen.

0 Karma

PickleRick
SplunkTrust
SplunkTrust

From the technical point of view you could get away with almost any kind of license on your DS as long as it does not index data locally. But it's more a case of formal validity of such license. As you are a customer and already have a contract with Splunk and have a working license what other license would you want to have on your DS? An NFR one? Not applicable. A Splunk Free license? Won't work.

EDIT: With Splunk Cloud you can need to have "disconnected" components on premise - like HF or DS but that's a cloud-specific use case and you can get "non-indexing" licenses for that from support.

You can't deploy the same license on your license master and on the DS. And if you did, your MC would complain about duplicate license in the environment.

I can think of a single reason to not connect DS to LM - if you have a separate "disconnected" site with own DS and you're only pushing events from that site and have no connectivity to DS from your main site. But that's a highly unlikely scenario.

So why would you want to have such a disconnected DS anyway?

Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In December, the Splunk Threat Research Team had 1 release of new security content via the Enterprise Security ...

Why am I not seeing the finding in Splunk Enterprise Security Analyst Queue?

(This is the first of a series of 2 blogs). Splunk Enterprise Security is a fantastic tool that offers robust ...

Index This | What are the 12 Days of Splunk-mas?

December 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...