Pertino - Is Anyone Successfully Using Any Version Above 510 with DNS/AD Connect?
-
@scottalanmiller Synology NAS
-
@wrx7m said:
I was referring to Pertino in terms of how easy it is supposed to be so I am deploying it in the manner in which it is designed to be deployed. It just doesn't work.
Design was on every device. Anything else is a post-Pertino sales tactic and not as designed. I worked with the engineers early on and certainly anything other than "every device" is not be design or intent and does not follow our recommendations of the platform or match what anyone meant when they said that it worked well or was easy.
-
@scottalanmiller said:
@wrx7m said:
@scottalanmiller I wouldn't necessarily struggle with deploying traditional solutions. I didn't think I would struggle with Pertino LOL. It is SOOOO easy everyone said. My main concern is that I can't deploy it on certain devices like printers or items I want to access that also don't have the ability to run the client.
It is SOOO easy, when you deploy it as designed
Printers are an "issue" but outside of what we want to be location agnostic and if you need to get around that we have this new thing around the late 1980s called a printer server. So that's not a real issue today.
What other devices are causing problems?
Actually, that's not entirely true.
Scenerio - home user, needs to print from a RDS a Linux box in the DC.
I have a remote AS/400 user who had a check printing printer at home. They needed to be able to print checks to the home printer. Luckily I was able to open a print queue session on the PC, which worked because the PC was on the VPN.
I guess the same could be done here. The printer is setup to a PC, that PC shares it over the Pertino network, ta da - printing works... but management of the printer doesn't.
-
@wrx7m said:
@scottalanmiller I don't want any home user to access that but I, as the admin, do want access to them from a remote location.
But not on the ZT, access in ohter ways, through a jump system, right? ZT wouldn't be a limitation there.
-
-
@wrx7m said:
@scottalanmiller said:
@wrx7m said:
@scottalanmiller I wouldn't necessarily struggle with deploying traditional solutions. I didn't think I would struggle with Pertino LOL. It is SOOOO easy everyone said. My main concern is that I can't deploy it on certain devices like printers or items I want to access that also don't have the ability to run the client.
It is SOOO easy, when you deploy it as designed
Printers are an "issue" but outside of what we want to be location agnostic and if you need to get around that we have this new thing around the late 1980s called a printer server. So that's not a real issue today.
What other devices are causing problems?
I was referring to Pertino in terms of how easy it is supposed to be so I am deploying it in the manner in which it is designed to be deployed. It just doesn't work.
What manner was that?
*nevermind - scott already asked.
-
@scottalanmiller I can use a jump system. I just hate doing it that way.
-
@Dashrender said:
@scottalanmiller said:
@wrx7m said:
@scottalanmiller I wouldn't necessarily struggle with deploying traditional solutions. I didn't think I would struggle with Pertino LOL. It is SOOOO easy everyone said. My main concern is that I can't deploy it on certain devices like printers or items I want to access that also don't have the ability to run the client.
It is SOOO easy, when you deploy it as designed
Printers are an "issue" but outside of what we want to be location agnostic and if you need to get around that we have this new thing around the late 1980s called a printer server. So that's not a real issue today.
What other devices are causing problems?
Actually, that's not entirely true.
Scenerio - home user, needs to print from a RDS a Linux box in the DC.
I have a remote AS/400 user who had a check printing printer at home. They needed to be able to print checks to the home printer. Luckily I was able to open a print queue session on the PC, which worked because the PC was on the VPN.
I guess the same could be done here. The printer is setup to a PC, that PC shares it over the Pertino network, ta da - printing works... but management of the printer doesn't.
Doesn't it? I'm probably missing something. But if the printer is on a PC, and the PC has ZT, isn't the problem solved?
-
@Dashrender Using their gateway feature and installing the client on remote users' laptops
-
@wrx7m said:
@scottalanmiller I can use a jump system. I just hate doing it that way.
But isn't that the better way and keep it away from the end users? This just seems like a lot of "problem" introduced for the purpose of putting things like switches on the network extended to the users' homes.
-
@wrx7m said:
@Dashrender Using their gateway feature and installing the client on remote users' laptops
I've definitely spoken to the main designers about that feature and they were very clear that while it could theoretically be done, it could never work easily and was not part of the design because of the known issues that that would cause. Anything involving the gateway cannot involve "as designed."
-
@scottalanmiller Ideally, they wouldn't have access to any of that. One point of the gateway access was to limit what the remote/home users have access to.
-
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
@wrx7m said:
@scottalanmiller I wouldn't necessarily struggle with deploying traditional solutions. I didn't think I would struggle with Pertino LOL. It is SOOOO easy everyone said. My main concern is that I can't deploy it on certain devices like printers or items I want to access that also don't have the ability to run the client.
It is SOOO easy, when you deploy it as designed
Printers are an "issue" but outside of what we want to be location agnostic and if you need to get around that we have this new thing around the late 1980s called a printer server. So that's not a real issue today.
What other devices are causing problems?
Actually, that's not entirely true.
Scenerio - home user, needs to print from a RDS a Linux box in the DC.
I have a remote AS/400 user who had a check printing printer at home. They needed to be able to print checks to the home printer. Luckily I was able to open a print queue session on the PC, which worked because the PC was on the VPN.
I guess the same could be done here. The printer is setup to a PC, that PC shares it over the Pertino network, ta da - printing works... but management of the printer doesn't.
Doesn't it? I'm probably missing something. But if the printer is on a PC, and the PC has ZT, isn't the problem solved?
Managing the printer (connecting to it's web or SSH interface) couldn't be done via the ZT network - you'd have to connect to the PC in question, then mange it from there. Not a huge deal - but @wrx7m has already said he doesn't want to deal with a jump box - which I agree with you, is the right way to deal with those.
-
@wrx7m said:
@scottalanmiller Ideally, they wouldn't have access to any of that. One point of the gateway access was to limit what the remote/home users have access to.
But you are extending it "to that network" one way or another. So you expose it, then add a firewall to limit access. Seems like more and more complication to do things in an odd way, then to mitigate the problems introduced by doing so, etc. What makes a jump device so bad?
-
@scottalanmiller LOL - Semantics. The gateway product was "developed/engineered" for the purpose of allowing access to devices that did not have the actual client installed on them.
-
@wrx7m said:
@scottalanmiller Ideally, they wouldn't have access to any of that. One point of the gateway access was to limit what the remote/home users have access to.
How did that work? Unless you had multiple Pertino networks? i.e. the home users are on P1, and the gateway/swtiches are on P2.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
@wrx7m said:
@scottalanmiller I wouldn't necessarily struggle with deploying traditional solutions. I didn't think I would struggle with Pertino LOL. It is SOOOO easy everyone said. My main concern is that I can't deploy it on certain devices like printers or items I want to access that also don't have the ability to run the client.
It is SOOO easy, when you deploy it as designed
Printers are an "issue" but outside of what we want to be location agnostic and if you need to get around that we have this new thing around the late 1980s called a printer server. So that's not a real issue today.
What other devices are causing problems?
Actually, that's not entirely true.
Scenerio - home user, needs to print from a RDS a Linux box in the DC.
I have a remote AS/400 user who had a check printing printer at home. They needed to be able to print checks to the home printer. Luckily I was able to open a print queue session on the PC, which worked because the PC was on the VPN.
I guess the same could be done here. The printer is setup to a PC, that PC shares it over the Pertino network, ta da - printing works... but management of the printer doesn't.
Doesn't it? I'm probably missing something. But if the printer is on a PC, and the PC has ZT, isn't the problem solved?
Managing the printer (connecting to it's web or SSH interface) couldn't be done via the ZT network - you'd have to connect to the PC in question, then mange it from there. Not a huge deal - but @wrx7m has already said he doesn't want to deal with a jump box - which I agree with you, is the right way to deal with those.
Ah, so was still a network printer. That's what I missed. Of course if you are running an AS/400 the wheels are about to come off the wagon and ZT isn't an option anyway.
-
@Dashrender said:
@wrx7m said:
@scottalanmiller Ideally, they wouldn't have access to any of that. One point of the gateway access was to limit what the remote/home users have access to.
How did that work? Unless you had multiple Pertino networks? i.e. the home users are on P1, and the gateway/swtiches are on P2.
Extra firewall.
-
@scottalanmiller Well, with ssh it would not be so bad but in the world of gui, it is a pain because you are resizing windows and scrolling and waiting for screen refreshing, etc.
-
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
@wrx7m said:
@scottalanmiller I wouldn't necessarily struggle with deploying traditional solutions. I didn't think I would struggle with Pertino LOL. It is SOOOO easy everyone said. My main concern is that I can't deploy it on certain devices like printers or items I want to access that also don't have the ability to run the client.
It is SOOO easy, when you deploy it as designed
Printers are an "issue" but outside of what we want to be location agnostic and if you need to get around that we have this new thing around the late 1980s called a printer server. So that's not a real issue today.
What other devices are causing problems?
Actually, that's not entirely true.
Scenerio - home user, needs to print from a RDS a Linux box in the DC.
I have a remote AS/400 user who had a check printing printer at home. They needed to be able to print checks to the home printer. Luckily I was able to open a print queue session on the PC, which worked because the PC was on the VPN.
I guess the same could be done here. The printer is setup to a PC, that PC shares it over the Pertino network, ta da - printing works... but management of the printer doesn't.
Doesn't it? I'm probably missing something. But if the printer is on a PC, and the PC has ZT, isn't the problem solved?
Managing the printer (connecting to it's web or SSH interface) couldn't be done via the ZT network - you'd have to connect to the PC in question, then mange it from there. Not a huge deal - but @wrx7m has already said he doesn't want to deal with a jump box - which I agree with you, is the right way to deal with those.
Ah, so was still a network printer. That's what I missed. Of course if you are running an AS/400 the wheels are about to come off the wagon and ZT isn't an option anyway.
I was simply talking about a single example.. you would replace AS/400 with Linux box - now how would you solve it? I'm guessing there is a way to make a print server on Windows that linux could talk to over the ZT network, yes?
